mesgd-sdk
A messaging client has two separate responsibilities: prove which account it is using, and protect the messages it exchanges. mesgd-sdk separates these into an account client and a PKI library, so an application can use either without taking on the other's state. Logging in does not require loading a key file, and signing a payload does not require storing an account password.
The account clients wrap signup, authenticator confirmation, login, password reset, public-key management, and logout. The PKI libraries generate and load keys, sign and verify messages, and encrypt and decrypt payloads. Account clients exist in eighteen languages, with different levels of built-in HTTPS and cryptographic support; consult Languages before choosing an implementation.
| Application task | SDK component | Reference |
|---|---|---|
| Enroll an account, log in, manage public keys, or log out | Auth client | Authentication |
| Generate keys, sign, verify, encrypt, or decrypt | PKI library | Keys |
| Examine a language's cryptographic message loop | Ping/pong sample | Samples and run commands |
| Coordinate work between application agents | Proposed topic convention | Agents |
The intended application interface is small: send a message to a recipient, or register a callback for messages from a sender. Signing and encryption would sit behind those operations. The current SDK provides the underlying pieces, with experimental samples, rather than a uniform implementation of that interface in every language.
For mesgd integration, start with the account client and the server's JSON WebSocket format. The encrypted registration handshake used by the samples is not implemented by the current server. Publishing keys with PUT /auth/keys is a working account operation; the sample register function is a separate cryptographic operation.
Language guides
Each guide includes setup, HTTPS and WSS support status, account examples, method names, and available cryptographic examples. The guides are ranked by current completeness, starting with Erlang, then Go, C, and Ruby. The support matrix distinguishes built-in HTTPS from application transports and pending WSS integration.
- Erlang — Verified HTTPS, peer-key helpers, and hybrid seal/open with a tested full public-key registration round trip.
- Go — Verified HTTPS, explicit identity instances, JWK import/export, and tested peer encryption and signature verification.
- C — Verified HTTPS through libcurl and tested peer-key cryptography; public PKI header and WSS wrapper remain missing.
- Ruby — Verified HTTPS, JWK storage, and tested peer encryption and signature verification; identity state is module-global.
- Python — Verified HTTPS and tested peer-key operations; identity state is class-global, and full-key registration exceeds its single OAEP block.
- JavaScript — Verified HTTPS and tested peer-key operations; PKI imports Node filesystem code, and no registration helper is provided.
- Rust — Explicit identity instances and tested peer-key cryptography; the account adapter requires an application HTTPS transport.
- PHP — Verified HTTPS and local JWK/PKI tests; no peer-key helper surface matching the shared protocol implementations.
- Java — Local JWK/PKI and cross-language fixture tests; HTTPS transport and account-runner coverage remain pending.
- C# — Local JWK/PKI and cross-language fixture tests; HTTPS transport and account-runner coverage remain pending.
- Kotlin — Local JWK/PKI tests; HTTPS transport, shared protocol coverage, and a WSS sample remain pending.
- OCaml — JWK storage, local PKI tests, and encrypt-to-key support; shared protocol coverage and native HTTPS remain pending.
- C++ — Account contract tests and the C HTTPS bridge; PKI still uses the older implementation and missing WSS headers.
- Swift — Account adapter and Apple-oriented cryptography; native HTTPS adapter, Linux RSA, and shared coverage remain pending.
- Perl — Tested account adapter; native HTTPS and interoperable JWK/PKI support remain pending.
- Lua — Tested account adapter; native HTTPS and interoperable JWK/PKI support remain pending.
- Haskell — Account adapter source; native HTTPS, account-runner coverage, and the PKI rewrite remain pending.
- Forth — Low-level account endpoint words and local cryptography; structured validation, JWK, HTTPS, and WSS remain unimplemented.
Check an implementation
Run these targets from the mesgd-sdk source. A test target's language coverage is listed in Languages; unavailable toolchains may be skipped.
| Target | Coverage |
|---|---|
make test-auth | Offline request contracts for seven account operations, OTP strings, public-key validation, and HTTP errors |
make test-auth-live | Account operations over HTTPS against a temporary mesgd on loopback |
make tests | The default language PKI suites, followed by protocol tests |
make test-mesgd | Client-side protocol tests for Erlang, Python, JavaScript, Go, Ruby, Rust, and C |
The live auth suite uses installed code from ~/.beamer, a temporary database and keys, and a localhost certificate. It requires Erlang, OpenSSL, the relevant language runtimes, and libcurl headers for C. The protocol suite exercises cryptographic message construction; passing it does not establish that the sample registration handshake works with a running mesgd.
Shared cryptographic fixtures are in fixtures/jwks.json, fixtures/sig_*.json, and fixtures/ct_*.json.