mosadd-mdm

name	mosadd-mdm
description	Send, list, and respond to direct messages on mosadd. Use when the user wants to message a mosadd contact, check their inbox, or accept/reject a contact request. Multi-thread per contact is the USP — each contact can have multiple named threads (unlike WhatsApp/Telegram).

mosadd Direct Messages (mDM)

This skill operates the mDM OS module of mosadd — direct text messaging between mosadd contacts.

When to invoke

Trigger on these user intents:

• "Send to " — use mDM_send
• "What did say?" / "Show my messages with " — use mDM_list
• "Who are my contacts?" — use mDM_list_contacts
• "Accept the request from " — use mDM_respond_request

How to operate

1. Resolve the recipient. mDM_send.to expects a mosadd identity_id (UUID), not a handle or email. If the user says "send to alice", first call mDM_list_contacts and find the matching display_name or account_id, then use that identity_id.

2. Threads. mosadd's USP is multiple threads per contact. If the user says "tell Alice in the work thread", pass thread_label: "work". If they don't specify, omit thread_label — defaults to the contact's main thread.

3. Encryption. mDM 1:1 messages are end-to-end encrypted by default (X3DH + Double Ratchet, mosadd.e2ee.v2 envelope). The mosadd server/operator cannot read message content. Prekeys auto-publish, so mDM_send encrypts transparently — you don't need to run mDM_publish_keys first in the normal path (it's there for re-keying). The same wire format is used by the mosadd app, so messages sent from the toolkit interoperate end-to-end with app users. Note: E2EE protects content, not metadata — the relay still sees who messaged whom (mosadd does NOT do "sealed sender"). The deprecated mDM_send_unencrypted sends server-readable plaintext; only use it if a peer explicitly cannot do E2EE.

Configuration

The MCP server needs the user's Supabase credentials in env:

MOSADD_SUPABASE_URL=https://<their-project>.supabase.co
MOSADD_SUPABASE_ANON_KEY=<anon key>
MOSADD_USER_JWT=<their session token>

If any are missing, mDM_send fails fast with an actionable error. Direct the user to https://mosadd.com for BYOK setup walkthrough.

Example

User: "Tell Alice I'll be late, in the work thread."

You:

1. mDM_list_contacts({}) → finds { identity_id: "uuid-1", display_name: "Alice", state: "accepted" }
2. mDM_send({ to: "uuid-1", text: "I'll be late.", thread_label: "work" }) → { message_id, delivered_at, thread_id: "dm:<me>:<alice>:work" }
3. Confirm to the user: "Sent to Alice in the work thread."

Don't

• Don't ask the user for the recipient's UUID if mDM_list_contacts can resolve it.
• Don't fabricate thread_labels — only use what the user explicitly said.
• Don't claim "sealed sender" — mDM hides message content end-to-end, but the relay still sees sender and recipient identity.
• Don't tell the user mDM is plaintext — mDM_send is end-to-end encrypted by default.