The messaging extension defines a decentralized, capability-based communication layer for OpenClaiming. It enables wallet-to-endpoint communication, identity-bound messaging, programmable access control, and decentralized discovery without intermediaries.

Overview

Messaging enables:

• address → endpoint binding
• decentralized inboxes
• programmable spam filtering
• capability-based introductions
• federated communication systems

Participants can:

• publish how they can be contacted
• define who is allowed to contact them
• receive messages under custom rules

Design Principle

Messaging is:

communication infrastructure, not transaction facilitation

The protocol SHOULD NOT:

• match buyers and sellers
• structure deals
• execute trades
• act as a broker or intermediary

It only enables:

→ verifiable contact between parties

Structure

"messages": [ claims ]

Each entry is a full OpenClaim.

Claim Shape (Endpoint Claim)

{
  "ocp": 1,
  "iss": "wallet identifier",
  "stm": {
    "endpoint": "https://example.com/ocp-inbox",
    "protocol": "https",
    "capabilities": {
      "type": "threshold",
      "rule": "2-of-5"
    }
  },
  "key": [...],
  "sig": [...]
}

Field Semantics

iss (Owner)

The wallet or identity that owns the endpoint.

"iss": "evm:1:address:0xABC..."

stm.endpoint

The URL or endpoint where messages can be delivered.

"endpoint": "https://example.com/ocp-inbox"
"endpoint": "https://example.com/webhook"

This endpoint is responsible for:

• receiving messages
• verifying claims
• enforcing policy

stm.protocol

Defines how communication occurs.

• "https" — HTTP POST messages
• "webhook" — event-driven delivery
• "p2p" — peer-to-peer messaging

stm.capabilities

Defines access requirements for contacting the endpoint.

"capabilities": {
  "threshold": "2-of-5",
  "gatekeepers": [
    "evm:1:address:0xA...",
    "evm:1:address:0xB..."
  ]
}

Message Composition & Sending

Any website or app that supports OpenClaiming can allow users to:

• compose a message
• sign it with their wallet (EIP-712 or personal_sign)
• send it to an endpoint
• or publish it publicly

Example Message Claim

{
  "ocp": 1,
  "iss": "evm:1:address:0xSender",
  "sub": "evm:1:address:0xRecipient",
  "stm": {
    "type": "message",
    "body": "Hello, I would like to connect.",
    "timestamp": "1710000000"
  },
  "sig": [...]
}

Properties

• message is cryptographically signed
• sender identity is verifiable
• message can be sent directly to endpoint or published publicly (IPFS, web, etc.)

Reply Mechanism

Recipients determine how to reply by:

• resolving sender identity via OpenClaim
• retrieving sender's endpoint

→ bidirectional communication without centralized platforms

Messaging Model

Messaging follows a submit → verify → accept/reject flow:

Step 1 — Endpoint Publication

User publishes endpoint claim:

• signed by wallet
• optionally hosted at /.well-known/ocp.json or DNS

Step 2 — Discovery

Sender:

• identifies recipient wallet
• resolves endpoint via OpenClaim

Step 3 — Message Submission

Sender submits:

• signed message
• optional capability proofs

Step 4 — Verification

Receiver endpoint:

• verifies signatures
• evaluates policy
• accepts or rejects

Spam Control via Capabilities

Spam is controlled through receiver-defined policies, not global filters.

Endpoint Policy

Each endpoint defines rules for accepting messages. Examples:

• require gatekeeper attestations
• require proof-of-work
• require prior relationship
• rate limiting
• stake-based access (future)

Gatekeeper Model

A user can require:

sender must be vouched for by M of N trusted gatekeepers

Gatekeeper Claim

{
  "ocp": 1,
  "iss": "evm:1:address:0xGatekeeper",
  "stm": {
    "attests": "evm:1:address:0xSender",
    "role": "trusted"
  },
  "sig": [...]
}

Threshold Verification

Receiver enforces:

valid_attestations >= threshold

Challenge-Based Messaging

Endpoints may publish requirements such as:

• "Provide 2 of 5 gatekeeper attestations"
• "Solve proof-of-work challenge"
• "Include signed introduction claim"

These instructions can be included in endpoint metadata or dynamically returned by the endpoint.

Example Flow

1. Sender queries endpoint
2. Endpoint responds with requirements
3. Sender gathers proofs
4. Sender submits message + proofs
5. Endpoint verifies and accepts

Delegation

Capabilities may be:

• delegated
• scoped to subtrees
• revoked

Example Tree

root
 ├── gatekeeper A
 ├── gatekeeper B
 └── messaging subtree

Properties

• fine-grained control
• hierarchical trust
• instant revocation

If a gatekeeper misbehaves:

→ revoke subtree → all downstream trust invalidated

Endpoint Verification (Non-Interactive)

Endpoints can be verified via:

Option 1 — /.well-known

https://example.com/.well-known/ocp.json

Option 2 — DNS

_ocp.example.com → TXT record

Result:

• no user interaction required
• no email confirmation
• fully automated verification

Federation Model

Users may:

• host their own endpoint
• receive messages via webhook
• control storage and filtering

→ decentralized inbox per identity

Relation to Other Extensions

Messaging does NOT:

• move funds
• execute logic
• authorize transactions

Legal Positioning

Messaging is:

• identity + communication infrastructure
• neutral and general-purpose

It SHOULD NOT:

• facilitate transactions
• organize markets
• match buyers/sellers

→ separation from broker / intermediary roles

Summary

The messaging extension provides:

• wallet-bound communication endpoints
• signed message transport
• decentralized identity-based messaging
• programmable spam control via capabilities
• delegation and revocation
• federated inbox architecture

secure, permissioned communication between participants without centralized platforms