Client–Relay Protocol
Meshline clients use this protocol through HTTPS or WSS endpoints verified against the Registry and RelayDescriptor. Every public relay provides the base module. Channel and group hosting are optional modules sharing the same transport, sessions, errors, and method namespace.
WebSocket follows RFC 6455; WSS methods and notifications use JSON-RPC 2.0 envelopes. For shared encoding and signing inputs, see the General protocol rules.
An account is a long-lived blockchain identity controlled by its account key holder. A device is a client instance with independent signing and encryption keys. The calling device is the account device actually used by the client for this call, whose identity the relay confirms through a valid device session. The account's selected current home relay stores its authoritative device state, profile, and bounded-retention message timeline, and accepts its message.send calls. A client may query other accounts' profiles and devices through its currently connected relay. For cross-relay messaging, the sender account's home relay resolves the target account's route, then delivers directly to the target home relay over relay RPC.
Clients do not participate in the relay DHT. Channel and group operations connect directly to the hosting relay specified by the reference and do not use account routes or account message timelines. A relay providing a hosting service MUST implement its entire module and publish the corresponding capability declaration in a valid RelayDescriptor. See Roles, routing, and trust boundaries for details.
Protocol Contents
Concepts and Core Objects
| Section | Contents |
|---|---|
| Roles, routing, and trust boundaries | Fundamental entities, calling and routing roles, request routing model, and trust boundaries |
| Discovery and sessions | Relay discovery, session modes, and session trust boundaries |
| Account and device lifecycle | Account setup, device changes and recovery, local route validation, and home relay migration |
| Contacts and authorization | Contact bootstrapping, relationship state, authorization objects, and synchronization within an account |
| Message delivery | Delivery process, results, idempotency, retention, and retries |
| Account message timeline | Timeline model, device visibility, retention and history gaps, record structure, and processing flow |
| Core objects | Relay identity, account identity, device state, profiles, message envelopes, plaintext messages, and content references shared across methods |
Methods and Notifications
| Section | Contents |
|---|---|
| Common method conventions | HTTP/WSS request mapping, common responses, and errors |
| Relay discovery and information methods | Descriptor retrieval, service information, and limit queries |
| Session authentication and lifecycle | Device and account authentication, session credentials, validity, and renewal |
| Device state methods | Publication and pre-storage, own-state reads, public queries, and signed queries |
| Account profile methods | Profile publication, queries, and signature verification |
| Account route methods | Route co-signing, publication, and queries |
| Message methods | Message sending, delivery status queries, and timeline synchronization calls |
| Notifications | WebSocket Notification envelopes and catch-up after disconnection |
Optional Modules
| Protocol component | Required relay declaration |
|---|---|
| Channel hosting protocol | channel.host.v1 |
| Group hosting protocol | group.host.v1 |
Unrecognized capability declarations MUST be ignored.
Client Calls
Match a method name as a complete, case-sensitive string against its module's method index. Base-module methods are listed here; channel.* and group.* methods are listed in the respective module's Method Index.
The HTTP column lists GET, POST, PUT, PATCH, or DELETE for each method. N/A means that transport is unavailable. JSON-RPC in the WebSocket column means a client may call the method as a JSON-RPC Request on a WSS endpoint. The Session mode column specifies only the relay session mode required before calling the method; None means no relay session is required. A relay without a WSS endpoint provides only the forms defined in the HTTP column and sends no server notifications.
| Method | HTTP | WebSocket | Session mode |
|---|---|---|---|
relay.descriptor |
GET | JSON-RPC | None |
relay.info |
GET | JSON-RPC | None |
auth.challenge |
POST | JSON-RPC | None |
auth.device.verify |
POST | JSON-RPC | None |
auth.account.verify |
POST | JSON-RPC | None |
device.state.publish |
PUT | JSON-RPC | Device or account session |
device.state.resolve |
GET, POST | JSON-RPC | Device or account session |
profile.publish |
PUT | JSON-RPC | Device session |
profile.resolve |
GET | JSON-RPC | Device session |
account.route.publish |
PUT | JSON-RPC | Account session |
account.route.resolve |
GET | JSON-RPC | None |
message.send |
POST | JSON-RPC | Device session |
message.delivery.status |
GET | JSON-RPC | Device session |
message.timeline.sync |
GET | JSON-RPC | Device session |
Mapping request parameters to the HTTP body, HTTP query, or WebSocket params, and handling responses and errors, follow the Common method conventions.
Server Notifications
Server notifications are sent only over WebSocket as JSON-RPC Notifications without id; HTTP has no equivalent. Base-module notifications are listed here, while channel and group notifications appear in their respective Notification Indexes.
| Notification | Sending precondition |
|---|---|
device.state.changed |
The account's current home relay has accepted new authoritative device state, and the current connection remains valid |
message.timeline.changed |
The device has authenticated on a WebSocket connection to the account's current home relay, and the account message timeline head may have changed |
For JSON-RPC envelopes and connection lifecycle, see Client–relay notifications.
Conformance Requirements
Conforming implementations MUST follow the Conformance testing boundaries and verify the behavior specified in the text under these topics:
- Fundamental objects: verify encoding, types, network and identity binding, nested signatures, message AAD, and authenticated and safe handling of bodies and attachments under the General protocol rules and Core objects.
- Discovery and sessions: verify Relay discovery, Descriptors and endpoints, and Authentication and renewal, including candidate rejection, relay_id and origin binding, both session modes, challenge consumption and expiry, device invalidation, and connection switching.
- Devices and profiles: verify pre-stored and authoritative state, revision rollback prevention and conflicts, duplicate submissions, cache isolation, account recovery, and cross-relay response validation under Device state methods and Account profile methods. Public profile reads do not relax device-query or message-delivery permissions.
- Contacts: verify public or invitation bootstrapping, relationship establishment and deletion, grant selection and endorsement merging, grant maintenance after device changes, and synchronization of account-internal snapshots, record revisions, and deletion records under Contacts and authorization.
- Routing and migration: verify Route publication and resolution and Home relay changes, including an unreachable previous relay, device-state pre-storage, existing delivery responsibilities and result queries, catching up on old timelines, and continuing sequence numbers after migrating back.
- Message delivery: verify self, local, and cross-relay delivery, recipient authorization, partial or total device invalidity, both key-box sets, complete parameter comparison, result states and retention periods, and recovery after lost responses or restarts under Delivery, idempotency, and retries.
- Timelines and notifications: verify device visibility, page ordering and end indicators, history gaps, persistence of timeline heads, synchronization cursor advancement, and notification coalescing, loss, and new hints during reads under Account message timeline, Message methods, and Notification rules. Device-state change notifications that carry no state MUST also follow Device state change notifications.
- Transports and errors: verify equivalent HTTP/WSS parameters and results, parameterless calls, JSON envelopes, session permissions, pagination, time and resource boundaries, integer exhaustion, error mapping, and rate-limit backoff under Common method conventions.