Federated Chatting System

This is an idea for the specification for the FCS protocol, it has not been accepted by the team. Written by Klara Bohringer.

[ REJECTED ] Comments: poorly thought out federation with no detail on how it should be handled.

Abstract

This protocol is designed to facilitate standardized communications between discrete servers (referred to henceforth as 'instances' to minimize confusion) as part of the Catsup platform. Unlike many similar federation protocols, it has a scope limited to real-time communications and associated metadata; it is not suitable for usage with any other synchronization paradigms. This protocol does not rely on web technologies, instead relying primarily on TLS connections paired with CBOR.

Basic constructs

Objects

User

A user is an object containing a user's identity, separated into the following fields:

• displayname - String, maximum 32 characters

• username - String, maximum 32 characters

• identifier - UUID

• bot - if present, UUID of owner

• biography - Message identifier

• avatar (media link)

• background (media link)

• blocked - List of user identifers which are not permitted to send a friend request to the user

• friends - List of user identifiers which are marked as friends of the user

• dm_group - Identifier of the group containing all direct messages, this is not public and will not federate

Groups

A group is an object designed to organize channels, they are always hierarchical with all groups belonging to the root group, which is the only group by spec permitted to not have a parent, and which must always both prevent invite creation and prevent user joining. The group object contains the following fields:

• name - String, maximum 32 characters

• description - message identifier

• children - arbitrary-length list of sub-group objects

• members - arbitrary-length list of member objects

• avatar - media link

• background - media link

• public - boolean, dictates whether users may see this group

• operators - arbitrary-length list of user identifiers, users in this list may perform any action upon the group

• moderators - arbitrary-length list of user identifiers, users in this list may delete messages from channels in this group and kick and ban members

• colors - arbitrary-length list of color objects, with each color object containing a list of colors to be blended together on the client using a linear gradient

• channel - a channel object, singular

• emojis - arbitrary-length dictionary of name <-> media bindings

Channels

Unlike in other similar systems, channels under FCS are quite literally just message stores. They have no name, they have no data other than an ordered list of messages. Client-side, a group containing a channel should be displayed as a channel with the group's properties.

• messages - An ordered list of message objects

Messages

• author - The global identifier of the user that sent the message

• content - Message content

• mentions - List of user global identifiers mentioned in the message

• media - List of at most 8 of media links attached to the message

• replies - List of at most 8 reply message IDs

Events

An event is a data structure used for synchronization between instances. Any federated action that changes server state is considered an event, with the specification laying out the following:

• User update (modifies a user object)

• Channel update (modifies a channel object)

• Group update (modifies a group object)

Each of these event types has sub events.

User update

User update events are split into the following sub-types:

• friend_request - Adds the origin to the friend queue of the target, unless the target is already in the queue, in which case the user is marked as a friend and a new group and associated channel is created and both users are added.
  • origin - Global identifier of the user making the request
  • target - Global identifier of the user being targetted

• block - Informs the remote server that the origin will not accept a friend request from the target and, if the target is in the origin's friends list, to remove the origin from the target's friends list and destroy the associated group.

• profile_update - Replaces the remote instance's local version of a user with the new data.

  • identifier
  • [new data]

Channel

Channel update events are separated into the following sub-types:

• message - Contains a message object to add to the remote's message cache (and relay to users)
  • channel - Channel in which the message was sent
  • [message object]

• delete - Signals the destination to remove the message identified from the local database.
  • channel
  • message

• edit - Replaces the remote instance's local version of a message with the new data.
  • channel
  • message
  • [message object]

[TBD: TYPING STATUS?]

Group

• update - Replaces the remote instance's local version of a group with the new data
  • identifier
  • [group object]

Actions

Establishing Federation

An instance is considered to be federating with another when it sends regular messages from a given input stream (can be messages, user data updates, etc). Federation may be established in one way, by a user from instance A joining a group hosted on instance B. Once this connection is established, all events originating from that group are relayed to the federated instance via TLS.