Security Considerations

Security model, spam prevention, and protection mechanisms for federated communication.

Trust Model

DNS-Based Trust

  • Domain ownership proves identity
  • TLS certificates prove server authenticity
  • Action signatures prove content authenticity

Progressive Trust

  • Initial federation is cautious
  • Trust builds through successful interactions
  • Users can block instances/users

Spam Prevention

Relationship-Based Action Acceptance

Algorithm: Should Accept Action

Input: action_type, issuer, local_user
Output: bool (accept or reject)

Decision logic by action_type:

1. "POST" → Only from followed or connected users
   - Check relationship between issuer and local_user
   - Accept if: relationship.following OR relationship.connected
   - Reject if: stranger with no relationship

2. "CMNT" / "REACT" → Always accept
   - Verification phase checks ownership of target content
   - Accept all, let verification handle validation

3. "CONN" / "FLLW" → Always accept
   - Relationship requests always received
   - User can block after receiving

4. Other action types → Reject

Federation Rate Limits

Default rate limits (hardcoded):

Limit Value Description
max_actions_per_instance_per_hour 1000 Per federated instance
max_actions_per_user_per_hour 100 Per remote user
max_concurrent_connections 100 Simultaneous federation connections
max_file_requests_per_hour 500 File sync requests

Blocklisting

Users can block instances or specific users:

Algorithm: Block Instance

Input: blocked_instance domain
Output: Result<()>

1. Add instance domain to user's blocklist
2. Store in metadata adapter
3. All future actions from this instance are rejected
4. Return success

User can later unblock by removing from blocklist.

Blocking Users

Individual users can be blocked without blocking the entire instance:

Algorithm: Block User

Input: blocked_user id_tag
Output: Result<()>

1. Add user id_tag to user's blocklist
2. Store in metadata adapter
3. All future actions from this user are rejected
4. Return success

Signature Verification

All federated actions must pass signature verification:

  1. JWT signature - Proves token signed by claimed issuer
  2. Key fetch - Public key retrieved from issuer’s instance
  3. Expiration check - Token not expired
  4. Audience check - Token intended for this instance

See Key Verification for details.

See Also