This is the specification for the Lichat chat protocol version 2.
Lichat is a protocol that is intended to be as simple to implement a client for as possible without sacrificing functionality. In basic operation, an end-user uses a Client in order to connect to a server. Each such client receives a corresponding Connection object on the server, which is tied to a User. If the user's name is registered, then it is tied to a Profile that stores information about the user, such as the login password. A User can inhabit multiple Channels at once, through which all communication happens. All communication happens through Update objects, which are uniquely identified.
[Profile]
1:1
[Channel] N:N [User] 1:N [Connection] 1:1 [Client]
│ │
╰─────────────────[Update]───────────────╯The server itself is represented via a User instance named after the server, and Channel instance that is named the same. All connected Users inhabit that Channel. All communication directly from or to the server uses the server User. All other communication happens via a Channel.
As such, in order to directly message another User, the two users must inhabit a common Channel. For this purpose, "anonymous channels" are offered, which do not have a globally registered name, so other Users cannot enter it without being invited by a User already a member of the Channel.
A client can determine whether their Update was correctly received and processed by looking for a response Update with the same id and from fields, or with the id stored in the update-id field in the case of a failure.
Success Failure
[Client] [Server] [Client] [Server]
│ │ │ │
│───[Update]──>│ │────[Update]────>│
│ :from test │ │ :from test │
│ :id 123 │ │ :id 123 │
│ │ │ │
│<──[Update]───│ │<───[Failure]────│
│ :from test │ │ :from server │
│ :id 123 │ │ :id xyz │
│ │ │ :update-id 123 │
│ │ │ │
Note that in the case of a successful send, the server may transform the Update into a different type as well as change field values, add, and remove fields. The Update that is received may thus not be identical to the one sent.
In order to regulate permissions, each Channel holds a map that ties an Update type to a permission rule, which can either be a whitelist or a blacklist. Permission handling for administrative Updates or other Update types that would not target a specific Channel are simply handled by the server Channel's permission map. Further, the base protocol has no concept of roles, special users, or modes, greatly simplifying the permission handling to simply understanding the concept of the permission map.
Lichat is simple enough that you can act as a client yourself through a simple TCP connection via Telnet or similar. Note though that the protocol does not specify a specific carrier, so Lichat could also be embedded into other protocols like WebSockets, or pretty much anything that can carry strings.
While clients are as simple as possible on purpose, servers are much more involved. A lot of the responsibilities usually left to clients are instead shifted to the server, such as ping tracking, clock verification, sanitisation, and so on.
The most complicated exchange flow between a client and server is the initial connection establishment, whose procedure for a new, unauthenticated user looks as follows:
[Client] [Server]
│ │
│< underlying connection >│
│ │── check for connection limit ─╮
│── (connect │<──── ok ──────────────────────╯
│ :id 0 │
│ :clock 1 │
│ :from "test" │
│ :version "2.0" │
│ :extensions ()) ────>│
│ │── check version and fields ─╮
│ │<──── compatible ────────────╯
│ │
│ │── check for "test" user ─╮
│ │<──── not found ──────────╯
│ │
│ │── create "test" user object ─╮
│ │<──── ok ─────────────────────╯
│ (connect ─────│
│ :id 0 │
│ :clock 2 │
│ :from "test" │
│ :version "2.0" │
│<─ :extensions ()) │
│ │
│ (join ──│
│ :id 1 │
│ :clock 3 │
│ :from "test" │
│<─ :channel "Server") │
│ │
│ (message ──│
│ :id 2 │
│ :clock 4 │
│ :from "Server" │
│ :channel "Server" │
│<─ :message "HELLO!") │
│ │
For failures the different checks on the server may fail, in which case the server sends back a corresponding Failure update and closes the underlying conection. For authenticated users, the server will additionally check the provided password against its profile database.
The Lichat protocol defines the following basic data type hierarchy:
t The "top" type.
number All numbers.
integer All integers of arbitrary size.
id A positive integer.
time A positive integer representing time as the number of seconds since 1900.1.1 0:0:0 UTC.
float A floating point number of arbitrary precision.
symbol An object with a name and a package, see §1.1.
keyword A symbol whose package is keyword.
boolean A symbol used to represent "true" and "false" states.
null The symbol NIL from the lichat package, which stands in for "false".
true The symbol T from the lichat package.
list An ordered sequence of objects.
(list type) A list with each element being of type type.
string A string of arbitrary Unicode text.
username See §2.2.1
channelname See §2.4.4
password See §2.3.1
object A structured association between named fields and values. See §1.2
The wire format is based on UTF-8 character streams on which objects are serialised in a secure, simplified s-expression format. The format is as follows:
UPDATE ::= OBJECT NULL
OBJECT ::= '(' WHITE* SYMBOL (WHITE+ SYMBOL WHITE+ EXPR)* WHITE* ')'
EXPR ::= STRING | LIST | SYMBOL | NUMBER
STRING ::= '"' ('\' ANY | !('"' | NULL))* '"'
LIST ::= '(' WHITE* (EXPR (WHITE+ EXPR)*)? WHITE* ')'
SYMBOL ::= KEYWORD | NAME | NAME ':' NAME
KEYWORD ::= ':' NAME
NUMBER ::= '0..9'+ ( '.' '0..9'*)? | '.' '0..9'*
NAME ::= (('\' ANY) | !(TERMINAL | NULL))+
TERMINAL ::= (':' | ' ' | '"' | '.' | '(' | ')')
WHITE ::= U+0009 | U+000A | U+000B | U+000C | U+000D | U+0020
NULL ::= U+0000
ANY ::= !NULLA symbol is an object with a "name" that is home to a "package". A "package" is a simple collection of symbols. Symbols are uniquely identified by their name and package, and no two symbols with the same name may exist in the same package. The package and symbol names are case-insensitive, and two names are considered the same if they match after both have been transformed to lower case.
This protocol specifies two core packages: lichat and keyword. Symbols that come from the lichat package must be printed without the package name prefix. Symbols from the keyword package must be printed by their name only prefixed by a :. Every other symbol must be prefixed by the symbol's package's name followed by a :.
When a symbol is read, it is checked whether it exists in the corresponding package laid out by the previous rules. If it does not exist, it may be substituted for a placeholder symbol. Servers must take special care not to keep symbol objects they don't know around, to avoid letting clients overload the server's memory with inexistent symbols.
Special care must be taken when objects are read from the wire. An error must be generated if the object is malformed by either a non-symbol in the first place of its list, imbalanced key/value pairs in the tail, or non-keywords in the key position. An error must also be generated if the symbol at the first position does not name a class that is a subclass of object. Finally, any field whose value is specified as nil on the wire can be equated with being unset, and vice versa when printing an object if an optional field is unset or nil, it may be omitted from the wire representation.
Null characters (U+0000) must not appear anywhere within a wireable. If a string were to contain null characters, they must be filtered out. If a symbol were to contain null characters, the message may not be put to the wire.
All object types are specified in lichat.sexpr in a machine-readable format based on the above wire format. The same format should also be used by extension providers to define their extensions to the protocol. The definitions can be parsed by parsing the file into a sequence of EXPRs, each being further parsed according to the following DEFINITION rule:
DEFINITION ::= PACKAGE | OBJECT | EXTENSION
PACKAGE ::= (define-package PACKAGE-NAME)
PACKAGE-NAME ::= STRING
OBJECT ::= (define-object CLASS-NAME (SUPERCLASS*) SLOT*)
CLASS-NAME ::= SYMBOL
SUPERCLASS ::= SYMBOL
SLOT ::= (SLOT-NAME TYPE OPTIONAL?)
FIELD-NAME ::= SYMBOL
TYPE ::= number | integer | time | float | id | symbol | keyword
| boolean | null | true | list | (list TYPE) | string
| username | channelname | password | object | t
OPTIONAL ::= :optional
EXTENSION ::= (define-extension EXTENSION-NAME EXTENSION-DEFINITION*)
EXTENSION-NAME ::= STRING
EXTENSION-DEFINITION ::= OBJECT | OBJECT-EXTENSION
OBJECT-EXTENSION ::= (define-object-extension CLASS-NAME (SUPERCLASS*) SLOT*)The meaning of each definition is as follows:
PACKAGE Introduces a new, known package with the PACKAGE-NAME as its name.
OBJECT Introduces a new object type using CLASS-NAME as its name. Each SUPERCLASS must name an object type that was previously introduced, and whose fields and behaviour should be inherited. Each SLOT defines a slot that the object holds in addition to the inherited ones. If the slot definition includes the :optional keyword, the slot may be omitted when serialising to the wire. If :optional is not included, the slot must be serialised. When translating from the wire, an omitted :optional slot should be initialised to an empty value. An omitted non-:optional slot must result in a malformed-update error.
EXTENSION Introduces a protocol extension of the given EXTENSION-NAME. Its body includes new definitions that need to be added if the extension is to be supported.
OBJECT-EXTENSION Changes an existing object type of CLASS-NAME by either introducing additional SUPERCLASSes, or introducing additional SLOT definitions on the object. Note that in order to stay backwards compatible, every slot specified via an OBJECT-EXTENSION must be :optional.
The server must keep track of a number of objects that are related to the current state of the chat system. The client may also keep track of some of these objects for its own convenience.
Each client is connected to the server through a connection object. Each connection in turn is tied to a user object. A user may have up to an implementation-dependant number of connections at the same time.
users represent participants on the chat network. A user has a globally unique name and a number of connections that can act as the user. Each user can be active in a number of channels, the maximal number of which is implementation-dependant. A user must always inhabit the primary channel. A user may have a profile object associated with it. When such a profile exists, the user is considered to be "registered." The server itself must also have an associated user object, the name of which is up to the specific server instance.
A user's name must be between 1 and 32 characters long, where each character must be from the Unicode general categories Letter, Mark, Number, Punctuation, and Symbol, or be a Space (U+0020). The name must not begin or end with Spaces (U+0020), nor may two Spaces be consecutive. Two user names are considered the same if they are the same length and each code point matches case-insensitively.
The profile primarily exists to allow end-users to log in to a user through a password and thus secure the username from being taken by others. A profile has a maximal lifetime. If the user associated with the profile has not been used for longer than the profile's lifetime, the profile is deleted.
A profile's password must be at least 6 characters long. It may contain any kind of character that is not Null (U+0000).
channels represent communication channels for users over which they can send messages to each other. A channel has a set of permission rules that constrain what kind of updates may be performed on the channel by whom. There are three types of channels that only differ in their naming scheme and their permissions.
Exactly one of these must exist on any server, and it must be named the same as the server's user. All users that are currently connected to the server must inhabit this channel. The channel may not be used for sending messages by anyone except for system administrators or the server itself. The primary channel is also used for updates that are "channel-less," to check them for permissions.
Anonymous channels must have a random name that is prefixed with an @. Their permissions must prevent users that are not already part of the channel from sending join, channels, users, or any other kind of update to it, thus essentially making it invisible, except for specially invited users.
Any other channel is considered a "regular channel".
The names of channels are constrained in the same way as user names. See §2.2.1.
A permission rule specifies the restrictions of an update type on who is allowed to perform the update on the channel. Rules are denoted in a sub-format as general Lichat EXPRs with the following structure:
RULESET ::= (RULE*)
RULE ::= (TYPE MASK)
MASK ::= ANYONE | NOONE | EXCLUDE | INCLUDE | REGISTRANT
EXCLUDE ::= (- username*)
INCLUDE ::= (+ username*)
USERNAME ::= STRING --- The name of a user, subject to §2.2.1
TYPE ::= SYMBOL --- The name of an update type
ANYONE ::= t
NOONE ::= nil
REGISTRANT ::= registrant
The INCLUDE mask only allows users whose names are listed to perform the action. The EXCLUDE mask allows anyone except users whose names are listed to perform the action. The mask t is thus equivalent to (-) and the mask nil is equivalent to (+). The registrant symbol is to be replaced with the username of the user that created the channel, and is only used in the descriptions below. It cannot appear in any rules as they appear in a permissions update.
The following sections list default permission sets for channels depending on how the channel is created. Note that these sets are not exhaustive or normative. Extensions may add to the sets or change their rules. Clients may assume these to be default, however.
The default permissions for primary channels (§2.4.1) should look like this, with the registrant being the server user.
((capabilities t)
(channels t)
(connect t)
(create t)
(disconnect t)
(grant (+ registrant))
(join t)
(kick (+ registrant))
(leave nil)
(message (+ registrant))
(permissions (+ registrant))
(ping t)
(pong t)
(pull nil)
(register t)
(search t)
(server-info (+ registrant))
(user-info t)
(users t))
The default permissions for an anonymous channel (§2.4.2) should look like this:
((capabilities t)
(channels nil)
(deny nil)
(grant nil)
(join nil)
(kick (+ registrant))
(leave t)
(message t)
(permissions nil)
(pull t)
(users t))
The default permissions for a regular, non-anonymous channel (§2.4.3) should look like this:
((capabilities t)
(channels t)
(deny (+ registrant))
(grant (+ registrant))
(join t)
(kick (+ registrant))
(leave t)
(message t)
(permissions (+ registrant))
(pull t)
(users t))
The client and the server communicate through update objects over a connection. Each such object that is issued from the client must contain a unique id. This is important as the ID is reused by the server in order to communicate replies. The client can then compare the ID of the incoming updates to find the response to an earlier request, as responses may be reordered or delayed. The server does not check the ID in any way– uniqueness and avoidance of clashing is the responsibility of the client. Each update should also contain a clock slot that specifies the time of sending. This is used to calculate latency and potential connection problems. If no clock is specified, the server must substitute the current time. Finally, each update may contain a from slot to identify the sending user. If the from slot is not given, the server automatically substitutes the known username for the connection the update is coming from.
When an update is sent to a channel, it is distributed to all the users currently in the channel. When an update is sent to a user, it is distributed to all the connections of the user. When an update is sent to a connection, it is serialised to the wire according to the above wire format specification. The actual underlying mechanism that transfers the characters of the wire format to the remote host is implementation-dependant.
At the end of each update there has to be a single null character (U+0000). This character can be used to distinguish individual updates on the wire and may serve as a marker to attempt and stabilise the stream in case of malformed updates or other problems that might occur on the lower level.
If an update cannot be performed for some reason, the server will respond with a failure update. If the client's update was successfully parsed, this failure must be a subclass of update-failure, which will reference the failed update's id in the update-id slot, so that the client can reconstruct which of the requests failed.
In addition to the normal reply of an update – whether successful or failed – the server may also send an update that is a subclass of warning. This update must be from the primary user, and must reference the original update in its update-id slot. The client may use the warning to inform the user or adjust future behaviour in response to the server's notice.
Note that a warning may only be issued if the request is processed otherwise. The server must not only reply with a warning. The server further must reply with the warning before replying with the response to the original update.
After the connection between a client and a server has been established through some implementation-dependant means, the client must send a connect update. The update will attempt to register the user on the server, as follows:
If the server cannot sustain more connections, a too-many-connections update is returned and the connection is closed.
If the update's version denotes a version that is not compatible to the version of the protocol on the server, an incompatible-version update is returned and the connection is closed.
If the update's from field is missing or NIL, the server substitutes a random name that is not currently used by any other user or registered profile.
If the update's from field contains an invalid name, a bad-name update is returned and the connection is closed.
If the update does not contain a password, and the from field denotes a username that is already taken by an active user or a registered user, an username-taken update is returned and the connection is closed.
If the update does contain a password, and the from field denotes a username that is not registered, a no-such-profile update is returned and the connection is closed.
If the update does contain a password, and the from field denotes a username that is registered, but whose password does not match the given one, an invalid-password update is returned and the connection is closed.
If the server cannot sustain more connections for the requested user, a too-many-connections update is returned and the connection is closed.
A user corresponding in name to the from field is created if it does not yet exist.
The connection is tied to its corresponding user object.
The server responds with a connect update of the same id as the one the client sent. The from field must correspond to the user's actual name.
If the user already existed, the server responds with join updates for each of the channels the user is currently inhabiting, with the primary channel always being the first.
If the user did not already exist, it is joined to the primary channel.
The server sends a message update for the primary channel from the primary user. The message contents are up to the server, and should typically be some kind of welcome banner.
Should the user send a connect update after already having completed the connection handshake above, the server must drop the update and respond with an already-connected update.
If the clock of an update diverges too much, the server may respond with a clock-skewed update and correct the timestamp. If the skew varies a lot, the server may drop the connection after replying with a connection-unstable update.
The server must receive an update on a connection within at least a certain implementation-dependant interval that must be larger than 100 seconds. If this does not happen, the server may assume a disconnection and drop the client after replying with a connection-unstable update. If the server does not receive an update from the client within an interval of up to 60 seconds, the server must send a ping update to the client, to which the client must respond with a pong update. This is to ensure the stability of the connection.
If the client sends too many updates in too short a time interval, the server may start dropping updates, as long as it responds with a too-many-updates update when it starts doing so. This throttling may be sustained for an implementation-dependant length of time. The client might send occasional ping requests to figure out if the throttling has been lifted. The server may also close the connection if it deems the flooding too severe.
Instead of a hard-throttle as described in the previous paragraph, the server may also implement a soft throttle by queueing updates and processing them after a delay. Should the client become throttled in this way, the server must send an updates-throttled warning once updates begin to be queued.
A connection may be closed either due to a disconnect update request from the client, or due to problems on the server side. When the connection is closed, the server must act as follows:
The server responds with a disconnect update, if it still can.
The underlying connection between the client and the server is closed.
The connection object is removed from the associated user object.
If the user does not have any remaining connections, the user leaves all channels it inhabited.
The exceptional situation being during connection establishment. If the server decides to close the connection then, it may do so without responding with a disconnect update and may immediately close the underlying connection.
An update is always checked as follows:
If the update is not at all recognisable and cannot be parsed, a malformed-update update is sent back and the request is dropped.
If the update is too long (contains too many characters), a update-too-long update is sent back and the request is dropped.
If the class of the update is not known or not a subclass of update, an invalid-update update is sent back and the request is dropped.
If the from, channel, or target fields contain an invalid name, a bad-name update is sent back and the request is dropped.
If the from field does not match the name known to the server by the user associated to the connection, a username-mismatch update is sent back and the request is dropped.
If the channel field denotes a channel that does not exist, but must, a no-such-channel update is sent back and the request is dropped.
If the target field denotes a user that does not exist, a no-such-user update is sent back and the request is dropped.
If the update is an operation that is not permitted on its target channel, or the primary channel if no target channel is applicable, an insufficient-permissions update is sent back and the request is dropped.
When a user sends a register update, the server must act as follows:
If the server disagrees with the attempted registration, a registration-rejected update is sent back and the request is dropped.
If the profile does not yet exist, it is created.
The password of the profile associated to the user is changed to match the one from the update.
The profile must stay live until at least 30 days after the user associated with the profile has existed on the server.
The server responds by sending back the original register update.
Note that the server does not need to store the password verbatim, and is instead advised to only store and compare a hash of it.
Since a channel has only two bits of information associated with it, the management of channels is rather simple.
Creating a new channel happens with the create update:
The update is checked for permissions by the primary channel.
If a channel of the channel name in the update already exists, the server responds with a channelname-taken update and drops the request.
If the user already inhabits the maximum amount of channels, the server responds with a too-many-channels update and drops the request.
If the channel field is NIL, an anonymous channel is created, otherwise a regular channel is created.
The user is automatically joined to the channel.
The server responds with a join update to the user with the id being the same as the id of the create update.
The channel's permissions can be viewed or changed with the permissions update, if the channel allows you to do so.
The permissions for the channel are updated with the ones specified in the update's permissions field as follows:
1. For each rule in the specified permissions set in the update:
2. If the rule should be malformed or unacceptable, the server responds with a invalid-permissions update and disregards the rule.
3. Otherwise, set the rule with the same type in the channel's rule set to the given rule.
The server responds with a permissions update with the permissions field set to the full permissions set of the channel, and the id being the same as the id of the update the user sent.
See §2.5 for an explanation of the proper syntax of the permissions. Note that the server may reduce the set of rules to a simpler set that is semantically equivalent.
As a shortcut, permissions can also be managed with the grant and deny updates, which change an individual rule. When a server receives a grant update, it must update the corresponding rule as follows:
If the rule is t, nothing is done.
If the rule is nil, it is changed to (+ user).
If the rule is an exclusion mask, user is removed from the mask.
If the rule is an inclusion mask, user is added to the mask if they are not already on it.
When the server receives a deny update, it must update the corresponding rule as follows:
If the rule is t, it is changed to (- user).
If the rule is nil, nothing is done.
If the rule is an exclusion mask, user is added to the mask if they are not already on it.
If the rule is an inclusion mask, user is removed from the mask.
After processing either a grant or deny update successfully, the update is sent back to the user.
A user can interact with a channel in several ways.
Joining a channel happens with the join update, after which the server acts as follows:
If the user is already in the named channel, an already-in-channel update is sent back and the request is dropped.
If the user already inhabits the maximum amount of channels, the server responds with a too-many-channels update and drops the request.
The user is added to the channel's list of users.
The user's join update is distributed to all users in the channel.
Leaving a channel again happens with the leave update, after which the server acts as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
The user's leave update is distributed to all users in the channel.
The user is removed from the channel's list of users.
Another user can be pulled into the channel by the pull update, after which the server acts as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
If the target user is already in the named channel, an already-in-channel update is sent back and the request is dropped.
If the target already inhabits the maximum amount of channels, the server responds with a too-many-channels update and drops the request.
The target user is added to the channel's list of users.
A join update for the target user with the same id as the pull update is distributed to all users in the channel.
Another user can be kicked from a channel by the kick update, after which the server acts as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
If the target user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
The user's kick update is distributed to all users in the channel.
A leave update for the target user is distributed to all users in the channel.
The target user is removed from the channel's list of users.
Finally, a user can send a message to all other users in a channel with the message update, after which the server acts as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
The user's message update is distributed to all users in the channel.
The server can provide a client with several pieces of information about its current state.
Retrieving a list of channels can be done with the channels update, after which the server acts as follows:
For each channel known to the server, the server checks the update against the channel's permissions.
If the permissions allow the update, the channel's name is recorded.
A channels update with the same id as the request is sent back with the channels field set to the list of names of channels that were recorded.
The list of users currently in a channel can be retrieved by the users update, after which the server acts as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
A list of the users in the channel is recorded.
A users update with the same id as the request is sent back with the users field set to the list of names of users that were recorded.
Information about a particular user can be retrieved by the user-info update, after which the server acts as follows:
If the user is not connected and no profile for the user exists, a no-such-user update is sent back and the request is dropped.
A user-info update with the same id as the request is sent back with the connections field set to the number of connections the user object has associated with it and with the registered field set to T if the user has a profile associated with it.
A user can request a list of updates they are allowed to send to a particular channel using the capabilities update. The server must act as follows:
If the user is not in the named channel, a not-in-channel update is sent back and the request is dropped.
For every update type known to the server, the server checks whether the user is permitted according to the channel's permission rule for the update. If permitted, the update type is added to a list.
A capabilities update with the same id as the request is sent back with the permitted field set to the list of updates gathered in step 2.
Servers may store additional information about a user, such as statistics, IP addresses, and so forth. Such information can be requested through the server-info update. After receiving such an update, the server must act as follows:
If the user is not connected and no profile for the user exists, a no-such-user update is sent back and the request is dropped.
A server-info update with the same id as the request is sent back with the attributes field set to an "association list", and the connections field set to a list of "association lists", one such "association list" per connection the user has. An association list is a list where each element has the following structure:
(SYMBOL EXPR), where:
SYMBOL is a symbol naming the attribute that is being returned.
EXPR is the value for the attribute being returned.
The attributes being returned are dependent on the server and the supported protocol extensions. The set of returned attributes may also differ depending on the user being requested, especially if the user is the server's user.
The following attributes are specified:
channels A list of channel names in which the user resides.
registered-on When the user registered their profile. NIL if they did not.
The following connection attributes are specified:
connected-on The time at which the connection was initiated.
While these attributes are specified in their purpose, a server does not have to return them.
A server or client may provide extensions to the protocol in the following manners:
Additional Update Types
If such an update is sent to a client that does not recognise it, it should be ignored. If such an update is sent to a server that does not recognise it, the server will respond with an invalid-update.
Additional Update Fields
A client or server may extend the existing update classes with additional, optional fields to provide further information or other kinds of behaviour. The server or client is not allowed to introduce additional required fields. When an update with unknown fields is received, the unknown fields are to be ignored. An extension may only add existing, well-specified fields in keyword form (:text, :channel, :target, :update-id). Other additional fields must be symbols from an extension-owned package.
Additional Constraints
An extension may introduce additional constraints and restrictions on whether existing updates are considered valid.
Additional User Attributes
An extension may specify additional attributes stored in profiles and returned through server-info.
Additional Server Objects
An extension may specify new server objects and new attributes on existing server objects.
Each extension to the protocol should receive a unique name of the form producer-name where producer is an identifier for who wrote up the extension's protocol, and name should be a name for the extension itself. For each extension that a server and client support, they must include the unique name of it as a string in the connect update's extensions list. Each producer also owns a symbol package with the producer's name, in which they may freely specify new symbols.
shirakumo.mess Describes extensions from the Shirakumo collective.
The following are general conventions for server and client implementors. However, they are not mandatory to follow, as they may only make sense for certain types of implementations.
The default port when served over TCP should be 1111, with 1112 being the default for SSL connections.
When specified in URLs, Lichat takes the lichat protocol and follows this general scheme:
URL ::= 'lichat://' HOST (':' PORT)? '/' (CHANNEL ('#' MESSAGE)?)?
HOST --- The server hostname
PORT --- The server port. If unspecified defaults to 1111
CHANNEL --- An URL-encoded version of the channel name
MESSAGE ::= USER '@' ID
USER --- An URL-encoded version of the message FROM
ID --- An URL-encoded version of the message IDOr in other words, the protocol should be lichat, the path is the channel name, and the fragment encodes the message. It needs to encode both the sender and ID in order to uniquely identify the message, as IDs are only meant to be unique per user. The URL's query parameters are left unspecified and may be used by clients and servers to include additional information.