ma_core/
service.rs

1//! Service trait for ma endpoint protocol handlers.
2//!
3//! A `Service` is analogous to an entry in `/etc/services`: a named protocol
4//! on a ma endpoint. Register services on an `MaEndpoint` to handle incoming
5//! connections on their protocol.
6
7/// Trait that all ma services must implement.
8///
9/// Each service declares its protocol identifier and provides a handler for
10/// incoming connections. Built-in services ship with ma-core; applications
11/// add custom services via this trait.
12///
13/// # Examples
14///
15/// ```
16/// use ma_core::Service;
17///
18/// struct MyService;
19///
20/// impl Service for MyService {
21///     fn protocol(&self) -> &[u8] { b"/ma/my-service/0.0.1" }
22/// }
23/// ```
24pub trait Service: Send + Sync {
25    /// The protocol identifier for this service.
26    fn protocol(&self) -> &[u8];
27}
28
29// ─── Well-known protocol constants (ma-core scope) ──────────────────────────
30
31pub const INBOX_PROTOCOL_ID: &str = "/ma/inbox/0.0.1";
32pub const RPC_PROTOCOL_ID: &str = "/ma/rpc/0.0.1";
33pub const IPFS_PROTOCOL_ID: &str = "/ma/ipfs/0.0.1";
34pub const CRUD_PROTOCOL_ID: &str = "/ma/crud/0.0.1";
35
36/// The well-known broadcast topic / protocol string.
37pub const BROADCAST_TOPIC: &str = "/ma/broadcast/0.0.1";
38
39// ─── Message types (routing / dispatch category) ────────────────────────────
40
41pub const MESSAGE_TYPE_BROADCAST: &str = "application/x-ma-broadcast";
42pub const MESSAGE_TYPE_CHAT: &str = "application/x-ma-chat";
43pub const MESSAGE_TYPE_EMOTE: &str = "application/x-ma-emote";
44pub const MESSAGE_TYPE_MESSAGE: &str = "application/x-ma-message";
45pub const MESSAGE_TYPE_IPFS_REQUEST: &str = "application/x-ma-ipfs-request";
46pub const MESSAGE_TYPE_IPFS_STORE: &str = "application/x-ma-ipfs-store";
47pub const MESSAGE_TYPE_DOC: &str = "application/x-ma-doc";
48pub const MESSAGE_TYPE_RPC: &str = "application/x-ma-rpc";
49pub const MESSAGE_TYPE_RPC_REPLY: &str = "application/x-ma-rpc-reply";
50
51// ─── CRUD message types (/ma/crud/0.0.1) ────────────────────────────────────
52//
53// Operation is encoded in the CBOR payload, not the message type:
54//   GET:    [":get",    ":path"]
55//   SET:    [":path",   value]        value = scalar or "/ipfs/…", "/ipns/…", "/ipld/…"
56//   DELETE: [":delete", ":path"]
57
58pub const MESSAGE_TYPE_CRUD: &str = "application/x-ma-crud";
59pub const MESSAGE_TYPE_CRUD_REPLY: &str = "application/x-ma-crud-reply";
60
61// ─── Content types (inner payload format) ───────────────────────────────────
62
63pub const CONTENT_TYPE_CBOR: &str = "application/cbor";
64/// CBOR term — either a bare atom (`:ok`, `:pong`) or a tuple (CBOR array whose first element
65/// is a dispatchable atom, e.g. `[:ok, data]` or `[:error, reason]`).
66/// Used as `contentType` for RPC and CRUD messages.
67pub const CONTENT_TYPE_TERM: &str = "application/x-ma-term";
68/// Raw CBOR data payload — e.g. an `EntityNode` struct or a `Vec<String>` names list.
69/// The `+cbor` suffix follows RFC 6838 §4.2.8 structured-syntax conventions.
70pub const CONTENT_TYPE_TERM_CBOR: &str = "application/x-ma-term+cbor";
71/// CID pointer — the CBOR payload is a text string holding a `CIDv1` that
72/// addresses a DAG-CBOR node in IPFS.  Receivers should fetch and decode it.
73pub const CONTENT_TYPE_TERM_DAG_CBOR: &str = "application/x-ma-term+dag-cbor";
74/// Inline YAML string — the CBOR payload is a text string containing a
75/// UTF-8 YAML document.  Suitable for config values (scalars, sequences,
76/// mappings) that do not need to be stored as separate IPFS objects.
77pub const CONTENT_TYPE_TERM_YAML: &str = "application/x-ma-term+yaml";
ma_core/service.rs

ma_core/
service.rs
