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 its public key). This uniquely identifies each 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. Anycast forwarding is primarily 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 offers two primary APIs for establishing new sessions:

  • Point-to-Point: Facilitates point-to-point communication with a specific service instance. This session performs a discovery phase to bind the session to a single instance; all subsequent messages in the session are sent to that same endpoint.

  • Group: Supports many-to-many communication over a named channel. Every message sent to the channel is delivered to all current participants.

For more information about each session type, see the SLIM session documentation.