This article builds up on the existing, well-iterated specification of the communication protocol, aiming to detail the new developments and to provide a place for current and relevant discussion going forwards. For the core structure of the protocol though, the linked article remains the reference and although the discussion of that part moves out of necessity here as well, I see no need at the moment to copy its content too. If your question concerns the parts that are not directly described here, simply link precisely the part you are talking about, as needed.
The first further addition to the communication protocol enables chat in Eulora2 and is currently implemented and fully working. Worth making it explicit and right from the start that the chat in Eulora2 is by default encrypted1 whenever in transit and effectively authenticated as well, as it fully benefits from the whole existing infrastructure supporting the game's world2. The WoT layer that is currently in the works will further provide the means to seamlessly keep out any automated noise, spam and the like while simultaneously enabling all users to effectively retain both control and accumulating benefits for everything that they put into participating. To the extent possible, I fully intend to further align the incentives as much as I can to support meaningful conversations that are worth re-reading, too - without any unnecessary restrictions and with fully owned responsibility as well as benefits for each participant, too. It is to my eye the only way in which having a chat capability is even worth it in the first place.
To add the chat capability to Eulora2, there are two new message types added in section 4 (Serpent packets), to request and receive chat lines, respectively, as well as one new action type added to section 7 (Character actions) describing the "Say" action. Using the same specification format, the newly added sections are the following:
4.9 Line Request
- uint8 (type ID, =12), followed by
- uint8 (count of lines), followed by
- n times uint32 (id of chatroom), uint64 (lowest line number requested), uint64 (highest line number requested), followed by
- padding to Serpent-message length
4.10 Line Info
- uint8 (type ID, =13), followed by
- text (line content), followed by
- uint32 (chatroom ID), followed by
- uint32 (speaker ID), followed by
- uint64 (line number), followed by
- uint64 (keccak hash of the line's content and number), followed by
- padding to Serpent-message length
Updated 30 Oct 2024: ratings are now fully integrated and used in-game, being fully handled via the relevant Rating node in the data hierarchy. Consequently there is no need anymore to have dedicated message types for discovery and retrieval, so the "rating request" and "rating info" message types below are removed entirely. See in any case the protocol specification for the full protocol.
4.11 Rating Request
uint8 (type ID, =14), followed byuint8 (count of requests), followed byn times uint32 (source ID), uint32 (target ID), followed byuint16 (message count), followed bypadding to Serpent-message length
4.12 Rating Info
uint8 (type ID, =15), followed bytext(rating comment3), followed byuint32 (source ID), followed byuint32 (target ID), followed byuint8 (rating value4 ), followed byuint16 (message count), followed bypadding to Serpent-message length
7.9 Say5:
- uint8 (type ID, =9), followed by
- text (line content), followed by
- uint32 (room ID), followed by
- uint64 (keccak hash of the line's content)
7.10 Rate
- uint8 (type ID, =10), followed by
- text (rating comment), followed by
- uint32 (target ID)
- uint8 (rating value)
A line of chat in Eulora2 has a maximum length of 1445 characters. This is fixed and unchangeable as it is the maximum that fits in a 4.10 message (which has the least space for the line's content out of all the messages relevant to chat lines and therefore effectively decides the *maximum* allowed line length). This limit is unlikely to be perceived all that often in practice but even if it is, note that it's anyway more generous than most other existing chat protocols, irc included. Any client implementation is however entirely free to take its own approach as to how it handles this - whether it splits some user input into several lines if needed or whether it restricts input to this maximum of 1445 characters to start with, to give some concrete examples.
Beyond the above specific characteristics, for all intents and purposes chat rooms in Eulora2 are otherwise like any other game entities and thus the above additions to the communication protocol itself are both minimal and all that's truly needed for a practical, working implementation. The speakers themselves are also characters (whether player controlled or not) in the game, hence fully described otherwise through the existing messages.
Messages 4.10 (Rating Request), 4.11 (Rating Info) and 7.10 (Rate) provide, respectively, a way to request and obtain from the server any desired ratings between two known entities in the WoT and to register/update one's own rating of another. The comment part of a rating is meant to provide some context for the chosen value but as the value itself, the actual meaning and use is up to each individual and likely to be different from one person to another.
Worth noting that messages 4.10 and 4.11 are provided mainly as a basic and potentially last resort means of requesting and obtaining specific ratings. They are however quite unlikely to be the best choice for exploring or obtaining the full set of existing ratings, especially across a relatively large WoT, since each rating will require its own message and the traffic thus generated is to be paid for by the requesting client. A much cheaper and more convenient way to explore and update a local copy of the WoT will be provided in-game through an abstract object providing the full representation of the WoT in a single file and taking thus advantage of all the existing infrastructure, without requiring any new types of messages or other changes to the existing protocol.
Feel free to ask any relevant questions in the comments section below.
Serpent keys ↩
Obviously, any of the users can otherwise make public the chat logs they have when and as they see fit but if you rely on something outside Eulora2 for that, it's strictly between you and that provider, nothing to do anymore with either Eulora2 or the support and protection it provides. ↩
Limited to at most 1445 characters, matching the maximum length of a chat line. ↩
Valid rating values are integers between -10 and 10. For a given rating value here GR, the corresponding actual rating value RV is therefore calculated as: Min(GR, 20) - 10. ↩
Note that this is an action and as such just a part of a 4.5 message, Client Action, where the overall message structure is specified. ↩
Comments feed: RSS 2.0
Where does the 1472-byte packet size come from (equivalently, the 92 in "92 successive 128 bit chunks")? Largest UDP packet that fits without fragmentation on an all-Ethernet path (without any encapsulation or protocol option fanciness)?
Is there an implicit byte ordering in the protocol? For instance, uint16 is said to be a 2-byte basic type but how those bytes are decoded into a number seems unstated. For another instance, a keccak hash at least in its purest conception is a bit string so there's room for confusion in how that translates to an integer type.
Is there a canonical (or good, or at least available) reference for Serpent and its usage? I'm seeing hints that it's used here with zero overhead, which makes me wonder if there's really no initialization vectors or equivalent, something to exclude statistical attacks based on (same plaintext fragment in + reused key) -> (same ciphertext fragment out).
Yes, 1472 as the programmable payload in an Ethernet frame of 1500. The value was arrived at after some discussion and iteration, starting somewhere in 2017 when we were trying to figure out how to even get some use out of the relatively small payload size of Serpent and got settled almost one year later, in 2018, as the protocol and needs of the game became clearer and it was noted that the correct measurement unit for network traffic is not really the bit nor byte but the Ethernet frame.
Yes, over the network everything is Big-endian (byte AND bit order). As far as I know, this is the usual convention and there wasn't a very good argument to break it (even despite a lot of log talk on how everyone is on little endian nowadays where local machines are considered). Not sure why it didn't become explicitly stated in the protocol's description but at any rate, it was discussed, agreed on and implemented as such, see the To_Wire and From_Wire methods in the Messages package of EuCore.
The one and only relevant reference that I know of is the original paper describing and proposing Serpent for the AES competition, which is anyway the reference followed by all implementation for Eulora2, hence archived and linked from my first article on Serpent implementation. In terms of attacks and the like, the paper itself claims that breaking a Serpent key would require at the very least 2^100 known plaintexts and actually more like at least 2^256 due to their chosen S-boxes. There's also the note that "it would be prudent" to change a key "well before 2^64 blocks have been encrypted" to avoid a potential collision attack. I am not aware of anything more or even simply better than this in terms of documented Serpent usage and/or potential vulnerabilities.
It is indeed used with zero overhead. The sort of thing you seem to be looking for is actually baked in at protocol level through the chosen structure of messages: note that even if you send repeatedly the same chat line for instance (hence presumably "same plaintext" as far as the user is concerned), what gets encrypted and therefore counts as "plaintext fragment" from Serpent's point of view is going to include that padding that is meant to be random (though the user can choose to have it fixed and repeated instead, up to them).
Otherwise and as it is the case with any and all other symmetrical encryption schemes, it is in principle and in theory possible to make the full possible table of input/output and then use that, with the only protection against this being the cost (time esp) of producing it. Arguably the same characteristic of being faster than RSA works in this sense against Serpent but in practice and at least so far, it still seems to be prohibitive. I suppose if/when Eulora2 is worth the trouble for someone to break Serpent, it will be quite something anyway.
Updated with footnote 3 and changes to 4.10 and 7.9.
Updated for the WoT-related messages, 4.11, 4.12 and action 7.10 as well as a brief note on their use and cost.
[...] as an ongoing trend, and in the envisioned future with new possibilities emerging in the nascent Eulora2 environment. [^]Speaking of automation, it looks like I could use a proper script for generating these tables [...]
[...] for the mid to long term is to phase out IRC with its many problems and dead scene, and embrace Eulora2 chat with its perhaps equally many but more interesting problems, active developer and coolness factor. [...]
[...] the point where I even sketched out a new addition to that section 7 of 'character actions' in the communications protocol, since it's really not all that difficult to add or use: have another ID, give some duration in [...]
[...] that 'Character Actions' section 7 that comes into focus but this time the changes go beyond just simple additions and move things forward from where the previous effort towards specification stopped. Consequently, [...]