Bureaucrats, Check users, Interface administrators, Push subscription managers, Suppressors, Administrators
478
edits
No edit summary |
(add flag opcode) |
||
(5 intermediate revisions by the same user not shown) | |||
The server will respond with a [[#Client Renamed|Client Renamed]] event, however with one key difference: The status will always be <code>0</code> (success), even if the requested username was not available for whatever reason. In this case, a guest username is assigned.
=== Client Capabilities ===
The client may at this point negociate capabilities with the server. This is a recent addition and so far only one exists, <code>bin</code>, enabling the [[#Binary Protocol|Binary Protocol]].
==== Request ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>cap</code></td></tr>
<tr><td>Parameters</td><td>Each parameter is a client capability the client supports and wants the server to use.</td></tr>
</table>
==== Response ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>cap</code></td></tr>
<tr><td>Parameters</td><td>The server lists each opcode it supports, out of the list the client sent, that will be used for this connection.</td></tr>
</table>
=== Connect to a VM ===
<tr><td>Parameter 1</td><td>The username of the added user.</td></tr>
<tr><td>Parameter 2</td><td>The [[#Rank|Rank]] of the added user as an integer.</td></tr>
</table>
=== Flag ===
Sent to provide the ISO country code for one or more users, if the server supports geolocation. The intended use is to display a country code beside each name in the list.
Parameters 1 and 2 are repeated for each user added.
<table class="wikitable">
<tr><td>Opcode</td><td><code>flag</code></td></tr>
<tr><td>Parameter 1</td><td>The username whose country code is being sent</td></tr>
<tr><td>Parameter 2</td><td>The two-character, upper-cased ISO country code of the user in question.</td></tr>
</table>
=== Framebuffer Update ===
Sent to update the VM screen. The server will send one initial message containing the entire screen on connection, and after that will send a dirty rect for each update.
If the binary protocol is enabled, you will instead receive [[#Framebuffer Update (Binary)|Framebuffer Update (Binary)]] messages.
<table class="wikitable">
==== Response ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>0</code></td></tr>
<tr><td>Parameter 2</td><td>Status of the login. See below for possible values.</td></tr>
<tr><td>Parameter 3</td><td>[[#Permissions|Permissions]] integer defining available moderation actions. Only sent if status is <code>3</code></td></tr>
</table>
Status can be one of the following:
<table class="wikitable">
<tr><th>Value</th><th>Status</th></tr>
<tr><td>0</td><td>Invalid credentials, or access denied for another reason.</td></tr>
<tr><td>1</td><td>Logged in successfully as Admin</td></tr>
<tr><td>3</td><td>Logged in successfully as Moderator</td></tr>
</table>
After successfully logging in, the server will also send a new [[#New User(s)|New User]] event to announce your rank change.
=== QEMU Monitor ===
Used to send a [https://qemu-project.gitlab.io/qemu/system/monitor.html QEMU Monitor] command to the VM. Only Admins may use this opcode.
==== Request ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>5</code></td></tr>
<tr><td>Parameter 2</td><td>Command to send to QEMU</td></tr>
</table>
==== Response ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>2</code></td></tr>
<tr><td>Parameter 2</td><td>Response from QEMU</td></tr>
</table>
=== Restore VM ===
Restore the VM to snapshot without a vote.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>8</code></td></tr>
</table>
=== Reboot VM ===
Reboot the VM.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>10</code></td></tr>
</table>
=== Ban User ===
Ban a user. The actual backend behavior here is dependent on server implementation. Usually this runs a command set in configuration.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>12</code></td></tr>
<tr><td>Parameter 2</td><td>Username to ban</td></tr>
</table>
=== Force vote ===
Forcibly end a vote-for-reset with the specified outcome
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>13</code></td></tr>
<tr><td>Parameter 2</td><td><code>1</code> to pass the vote and reset the VM, <code>0</code> to fail the vote</td></tr>
</table>.
=== Mute ===
Mute a user
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>14</code></td></tr>
<tr><td>Parameter 2</td><td>Username to mute</td></tr>
<tr><td>Parameter 3</td><td><code>0</code> for temporary mute, <code>1</code> for permanent. Temporary mute duration is left up to the server and is usually configurable.</td></tr>
</table>
=== Kick ===
Disconnect a user from the VM.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>15</code></td></tr>
<tr><td>Parameter 2</td><td>Username to kick</td></tr>
</table>
=== End turn ===
End a user's turn, or forfeit their spot in the queue.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>16</code></td></tr>
<tr><td>Parameter 2</td><td>Username to end turn</td></tr>
</table>
=== Clear turn queue ===
Clear the turn queue
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>17</code></td></tr>
<tr><td>Parameter 2</td><td>VM Node ID to clear the turn queue of</td></tr>
</table>
=== Rename user ===
Change another user's name.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>18</code></td></tr>
<tr><td>Parameter 2</td><td>User to rename</td></tr>
<tr><td>Parameter 3</td><td>New username</td></tr>
</table>
=== Grab IP ===
Grab a user's IP Address
==== Request ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>19</code></td></tr>
<tr><td>Parameter 2</td><td>User to IP grab</td></tr>
</table>
==== Response ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>19</code></td></tr>
<tr><td>Parameter 2</td><td>User whose IP was grabbed</td></tr>
<tr><td>Parameter 3</td><td>The requested IP address</td></tr>
</table>
=== Bypass turn queue ===
Jump directly in front of the queue and take the turn.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>20</code></td></tr>
</table>
=== Send raw message ===
Send a raw (XSS) message to the chat, bypassing HTML sanitization and character limits. When a moderator sends a raw message, admins will still receive a sanitized version for security reasons.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>21</code></td></tr>
<tr><td>Parameter 2</td><td>Raw message to send</td></tr>
</table>
=== Toggle turns ===
Prevent or allow non-staff to take turns on the VM
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>22</code></td></tr>
<tr><td>Parameter 2</td><td><code>1</code> to enable turns, <code>0</code> to disable them.</td></tr>
</table>
=== Indefinite turn ===
Jump directly to the front of the turn queue and take a turn that does not end until you disconnect or end it manually.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>23</code></td></tr>
</table>
=== Hide screen ===
Hide or show the VM screen from non-staff.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>24</code></td></tr>
<tr><td>Parameter 2</td><td><code>1</code> to show the screen, <code>0</code> to hide it.</td></tr>
</table>
=== Send system message ===
Send a raw (XSS) message as a system message from the server.
<table class="wikitable">
<tr><td>Opcode</td><td><code>admin</code></td></tr>
<tr><td>Parameter 1</td><td><code>25</code></td></tr>
<tr><td>Parameter 2</td><td>System message to send</td></tr>
</table>
= Binary Protocol =
The binary protocol is a new addition to the CollabVM protocol, that allows certain messages to be sent as binary instead of a base64 encoded guacamole string. So far, only one such message exists.
The protocol may be enabled by [[#Client_Capabilities|Negotiating]] the <code>bin</code> protocol with the server during the [[#Handshake|Handshake]].
== Message format ==
All binary messages are encoded with [https://msgpack.org/ MsgPack] (subject to change) and follow this basic format:
{{code|lang=ts|<nowiki>
{
type: number;
// Message specific data
}
</nowiki>}}
Where <code>type</code> is one of the following:
{{code|lang=ts|<nowiki>
{
// Framebuffer Update (rectangle)
rect = 0,
}
</nowiki>}}
== Server-to-Client Messages ==
=== Framebuffer Update (Binary) ===
Sent to update the VM screen. The server will send one initial message containing the entire screen on connection, and after that will send a dirty rect for each update.
If the binary protocol is enabled, this will be sent INSTEAD of <code>png</code> opcode messages.
{{code|lang=ts|<nowiki>
{
type: 0,
rect: {
// X-coordinate of the rectangle
x: number;
// Y-coordinate of the rectangle
y: number;
// Buffer containing the JPEG data for the rectangle.
data: Uint8Array;
}
}
</nowiki>}}
= Rank =
|