Connect Token

This token represents a bidirectional connection between two users (mutual, unlike the one-way follow).

The token must contain an audience (aud) field pointing to the identity being connected with. It may carry an optional content (c) field (a short connection message, max 500 chars). For other constraints see the Action Tokens.

Subtypes

Connection Flow

1. Alice sends a CONN to Bob. On Bob’s side the request rests at status C (confirmation) so he can accept or reject — unless his profile.connection_mode is set to auto-accept (A) or ignore (I).
2. Bob accepts: his instance creates a CONN:ACC back to Alice. Both profiles become Connected.
3. If both sides independently send a CONN to each other, the second one is detected as mutual and auto-accepted (no manual confirmation).
4. Either side may send CONN:DEL to disconnect.

Proof-of-Work

CONN actions carry a proof-of-work nonce in the _ claim and are PoW-verified before signature verification. This rate-limits unsolicited connection requests from strangers.

Content-Addressing

This token is content-addressed using SHA-256:

• The entire JWT token (header + payload + signature) is hashed
• Action ID format: a1~{base64_hash}
• See Content-Addressing & Merkle Trees for details

Database Key

The deduplication key for a connect token is {type}:{issuer}:{audience} (e.g. CONN:alice.example.com:bob.example.com).

Purpose: ensures only ONE active connection from a given issuer to a given audience. A new CONN with the same key supersedes the previous one (which is marked deleted).

Example

User @alice.cloudillo.net wants to connect with @bob.cloudillo.net: