Skip to content

SLIM Messaging Layer

The SLIM Messaging Layer implements an efficient message routing and delivery system between applications.

Client and Channel Naming

In SLIM, all endpoints are identified by a routable name. To send a message to a specific client, an application sends the message to its unique name. Client names follow this pattern:

org/namespace/service/client
  • Organization: The first component identifies the organization that deploys the application.
  • Namespace: This can be used to segment client deployments. For example, in a multi-region deployment, the namespace might indicate the application's location. It can be adapted to fit other user requirements as well.
  • Service: This component specifies the service exposed by the client. When multiple instances of the same client are deployed (such as several pods in a Kubernetes cluster), the organization, namespace, and service components remain the same for all instances.
  • Client: The final component is generated by SLIM and is a hash of the client's identity (e.g., a hash of the public key). This uniquely identifies each specific client instance.

This naming structure supports both Anycast and Unicast message delivery:

  • Anycast: By specifying only the first three components, a message can be sent to any one of the running clients sharing that name.
  • Unicast: By including the fourth component, the message is delivered directly to the specified client instance.

This approach enables efficient client discovery in fact the message will be delivered by the SLIM network to a client that is able to process it, even if the real name of the client is unknown. The anycast forwarding is mostly used in this discovery phase.

In addition to client endpoints, SLIM allows messages to be sent to Channels. A Channel acts as a message group, allowing multiple clients to connect and receive all messages exchanged on that channel. The channel name follows the same structure as client names, but the last component is left empty, as it is shared among all connected clients.

For further details, please refer to the SLIM Specification

SLIM Sessions Layer

The SLIM platform includes a session layer that connects application frameworks to the underlying SLIM messaging infrastructure. This layer provides a simple interface that abstracts the complexity of secure messaging and message distribution from the application.

The session layer offers several functionalities:

  • Security: All messages in SLIM are encrypted by default using the MLS protocol, which guarantees end-to-end encryption even when messages traverse intermediate nodes where TLS connections are terminated. The session layer is responsible for MLS group creation and updates, as well as message encryption and decryption.
  • Channel Management: The session layer enables clients to be invited to or removed from a channel as needed.
  • Message Delivery: The session layer abstracts message passing between applications and the SLIM message distribution network. It handles message formatting, routing, and delivery confirmation, while providing simple send and receive primitives to applications.

The session layer provides two main APIs: a 1:1 session, where two clients communicate directly, and a group session, where multiple clients exchange messages on a shared channel.

One-to-one Session

A one-to-one (1:1) session is used when an application needs to communicate with a single endpoint. It supports several modes:

  • Reliable or Unreliable: Applications can choose whether the session layer implements retransmission mechanisms for reliable communication or disables them for lower overhead.
  • Fire-and-Forget or Request/Reply: In fire-and-forget mode, the application sends a message to the other endpoint without waiting for a reply. For reliable sessions, retransmissions are handled transparently by the session layer. In request/reply mode, a timeout is setup at application level, which is cancelled when the other endpoint replies.
  • Anycast or Sticky: In anycast mode, each message can be forwarded to a different client exposing the same service name, which is useful for stateless applications. In sticky mode, the first message is sent using anycast to discover an available client; subsequent messages are sent to the same endpoint.

By default, all sessions are secured using MLS. In a 1:1 session, the group consists of only two clients, which must maintain some state for the MLS protocol. When MLS is enabled, the session is automatically forced to use the sticky mode, so that all the messages will be sent to the same client.

Group Session

In an N:N (group) session, multiple clients can exchange messages on the same channel. There are two types of clients in this session: a standard participant that can only be invited to the channel and participate in messaging, and a moderator. The moderator is a special client that has the following functionalities:

  • Invite/Remove clients: The moderator is the only client that can create a channel and can modify the list of clients participating in the group communication.
  • MLS state management: A channel has also an associated MLS group to guarantee security. The moderator performs the functionalities of the MLS delivery service, that routes MLS messages among the group participants in order to keep the state always updated.

As for the naming, for more information on the session layer, see the SLIM Specifications

A comprehensive tutorial on how to set up a secure group communication system using SLIM can be found in the Group Communication Tutorial.