Relationship Management

How following and connection relationships are established and managed across federated instances.

Following

Following is one-way and needs no approval. When Alice follows Bob, her instance creates a FLLW action (audience = Bob), signs it with her ES384 key, records it locally, and delivers it to Bob’s inbox. On receipt, Bob’s instance marks Alice’s profile as following=true. Bob can ignore the follow if he does not accept followers.

Connection Establishment

A connection is a mutual relationship and uses a request/accept handshake with CONN subtypes:

Alice creates CONN (audience = Bob)
  ↓  delivered to Bob's inbox
Bob's side records Alice as connected = RequestPending
  ↓  Bob accepts
Bob creates CONN:ACC (audience = Alice)
  ↓  delivered to Alice's inbox
Both profiles move to connected = Connected

The plain CONN token opens the request (state RequestPending); the CONN:ACC token confirms it (state Connected). Until the CONN:ACC round-trip completes, the connection is pending rather than established.

Connection vs Following

Aspect Following Connection
Direction One-way Bidirectional
Consent None required Mutual agreement
Trust level Low High (auto-approval)
Use case Content subscription Direct messaging, trusted sharing

Unfollowing and Disconnecting

Removal is expressed with a :DEL subtype of the same action, not a flag on the original token:

  • Unfollow: Alice creates a FLLW:DEL action (audience = Bob) and delivers it. On receipt, Bob’s instance clears Alice’s following state.
  • Disconnect: Alice creates a CONN:DEL action (audience = Bob). On receipt, the connection is removed (connected cleared) on the target side.

Each :DEL action is signed and delivered through the inbox exactly like the original FLLW/CONN, and it supersedes the prior relationship state.

See Also