Roles, Routing, and Trust Boundaries

Client–relay protocol

Roles

Fundamental Entities

Account A long-lived blockchain address identity in Meshline, controlled by its account key holder. See Account ID for its canonical identifier. Account keys authorize devices and sign account routes; they are not used for everyday message encryption.

Device A client instance authorized by an account. A device holds its own signing and key-exchange keys; device_id is derived from the stable identity fields in its DeviceCertificate.

Client An endpoint application acting for an account and device. Clients use public relays verified against the Registry and RelayDescriptor over HTTPS/WebSocket. Clients do not participate directly in the relay DHT.

Public Relay A server implementing the client–relay protocol and joining the relay overlay network. Each relay uses a Neo account as its protocol identity; relay_id is the canonical text form of that account's script hash. The relay also has an independent, stable libp2p Peer identity.

Calling and Routing Roles

Calling Account and Calling Device The calling account initiates a client method, and the calling device is the device that account actually uses for this call. The relay confirms the account ID and device ID through a valid device session: HTTP requests use X-Meshline-Session, and WebSocket requests use the identity bound after auth.device.verify on that connection. When this protocol requires a request or object to be signed by the calling device, its device signature and accompanying DeviceCertificate MUST correspond to that device. An account session proves only the account key holder and cannot identify the calling device. For permissions, see Session modes; for establishment, validity, and revocation, see Session authentication.

Home Relay The account-state and message relay designated by an account through AccountRoute. The home relay in the currently valid route is the current home relay. It stores the account's current AccountDeviceState, profile, and bounded-retention message timeline, and co-signs and publishes routes with the account.

Source Relay The relay that receives a client request and initiates an inter-relay request. For cross-relay message delivery, the source relay MUST be the sender account's current home relay when it accepts message.send.

Destination Relay The current home relay identified by relay_id in the target account's current route. It verifies inter-relay requests and performs queries or delivery.

Calling and Routing Model

Account device-state and profile operations and message.send are submitted to the account's current home relay. Message timelines are read from the relay storing the corresponding records under message.timeline.sync. Queries for other accounts' profiles or devices may be submitted to the currently connected relay. When another relay must be accessed, the source relay resolves the target account's AccountRoute, then connects directly to the target home relay. Retries of message.send follow the idempotency rules. Query message.delivery.status directly on the relay that accepted that send request. Messages MUST NOT be forwarded hop by hop along a DHT lookup path.

Channel and group clients connect directly to the hosting relay designated by relay_id in the reference, without passing through the account route DHT or account message timelines.

The currently connected relay validates the local session and performs requesting-device authorization checks required by the specific method. The destination home relay MUST independently validate the route, request parameters, and business authorization; it additionally queries the requesting device's current state only when the method explicitly requires it.

Trust Boundaries

Account private keys are used only for account-level objects such as co-signing DeviceCertificate, signing complete AccountDeviceState and account routes, and signing account-key challenges. A device first signs its own time-limited certificate, then the account confirms that device and validity period. Device keys sign profiles, contact grants, group requests, group application ciphertext, and other everyday objects. Account device state determines which certificates are currently valid; historical signatures are still verified using the complete certificates retained by objects or group events. Blockchain consensus state is the authorization root for the public relay membership directory. AccountRoute is authorized by the account and co-signed and published by the relay it designates.

DHT nodes, relays and their stored protocol state, source relays, and the transport network are not trust roots for user identity or message confidentiality. Noise protects the confidentiality and integrity of relay connections; end-to-end encrypted envelopes prevent any relay from reading message bodies.

A malicious relay can deny service and may violate hosting protocol rules, but cannot forge account or device signatures, read end-to-end encrypted bodies, or make other relays accept cross-relay requests that fail their independent validation rules.