Data types

All data types are Big Endian (Network Order, largest bit first).

String (..)

An ASCII string, with the MSB of the last byte set to 1 to denote the end of the string. Minimum length of 1 character and maximum length of 255 character. Since this is ASCII, one character == one byte.

UUID (16)

A UUID encoded most sig bits first and least sig bits last (i.e. Big Endian).

Registered channels

extras:register (C->S)

Name	Type	Description
Channel Name	String	The channel you would like to start receiving extras:messages for.

extras:unregister (C->S)

Name	Type	Description
Channel Name	String	The channel you would like to stop receiving extras:messages from.

extras:message (C->S, S->C)

You don't need to be registered to a channel to send this (but you need to be registered to a channel to receive messages from that channel), and the plugin will not send any extras:message packets with data originating from you back to you. However, if an error occurs, the plugin will send you a message in chat telling you that it failed, with no additional error information.

Name	Type	Description
Channel Name	String	The channel from which this message originates from.
Source UUID	UUID (not sent by client)	The player from which this message originates from.
Message	Channel Detail	The message that the player sent. This can be anything, and is not length prefixed.

Notes

• In order to receive extras:message from the server, you MUST send minecraft:register with the channel name. Please note that the standard for that custom payload packet is actually a list of channel names to register delimited by a null byte (0x00, \0). However, to send any of the aforementioned channels, you don't need to register the channel first - but this may change in future Paper versions.
• Messages are sent to everyone registered to a channel as implementing an ownership and message routing system could be tricky, and would decrease efficiency.
• As the list of channel names is only known to the server and any clients registering to it, multiple clients could create a scheme to agree upon private channel names using an asymmetric encryption algorithm and pre-shared key/key-agreement algorithm. However, no protections are implemented against side-channel attacks aiming to discover registered channel names by collecting the time it takes to process extras:register or extras:message for a specific channel name, so you should not rely upon a secret channel name for confidentiality and should instead look towards implementing encryption.
• I have not implemented any restrictions on the contents, amount of players registered or amount of channels registered because I'm not sure how I could limit that well without decreasing the usefulness of this addition.
• Further improvements could be made to the amount of data available in the message portion of extras:message by directly registering the channel name in the Messenger, entirely removing the channel name field in extras:message (and extras:message itself). However, this might lead to conflicts with other plugins and we would need to register the channel with Bukkit Messenger, likely leading to performance loss. The server is also likely to resend minecraft:register, which could cause issues with lots of channels registered. It should be possible to also make a size improvement by removing extras:register and extras:unregister, and just registering the player for all extras: channels it minecraft:registers too, with the same pitfalls aforementioned.