distributed messaging
claims, keys, and routes

mesgd

Connecting programs should not require making every component know where every other component runs. A program should be able to send a message describing what happened, and the programs interested in that message should receive it. mesgd provides that connection: a distributed messaging service written in Erlang, with content-based routing over WebSocket and an HTTPS API for accounts, public keys, and access management.

The routing model lets you describe a recipient's interests as a path. For example, /kind=chat/room=lobby selects chat messages for the lobby. Several programs can listen on that path, so adding a logger or another agent does not require changing the sender. Permissions collect those paths into roles, and grant tokens let an administrator give a program access to a particular set of routes. mesgd checks those grants against the current assignments, so removing access takes effect on the next authorization check.

Public keys answer a separate question: who can read a message, and who signed it? An account can publish a signing key and an encryption key for other programs to discover. With mesgd-sdk, a sender can sign a payload and encrypt it for a recipient without sharing private keys with the service. Routing still needs visible JSON fields to select the recipients; encrypting the payload does not make those routing fields private.

The SDK includes account clients in eighteen languages, although HTTPS transports and cryptographic support vary by language. Its encrypted ping/pong samples demonstrate a proposed messaging protocol that the current mesgd listener does not implement. The WebSocket documentation explains the working connection format and that compatibility boundary.

mesgd also supports HTTP modules mounted on paths and an Erlang agent that validates, executes, and binds programs to message routes. This makes it possible to extend the service with programs that participate in the same message flow.

Using mesgd