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 Acceptance

After a token’s signature is verified, the receiver decides whether to accept it based on the relationship with the issuer. The gate is type-agnostic:

  • If the issuer’s local profile is Suspended, Blocked, or Banned, the action is rejected outright.
  • Otherwise the action is accepted if the receiver follows the issuer or has a connection with them.
  • A few subject-anchored exceptions admit strangers on public content, e.g. a REACT or REPOST referencing the receiver’s own public action, or a STAT update for content the receiver already holds.
  • Anything else from an unrelated stranger is rejected.

Proof of Work for Connection Requests

CONN actions arriving at the inbox must include a valid proof-of-work token bound to the sender’s IP. Missing or invalid PoW is rejected with 428 Precondition Required. This raises the cost of bulk, unsolicited connection requests without requiring a prior relationship.

Rate Limiting

Inbound requests pass through a tiered IP rate limiter (per individual address and per network/provider block) shared by the whole HTTP surface, not a separate federation-specific limiter. Token-verification failures also penalize the source IP, so an instance sending many bad signatures is throttled.

Blocking

Blocking is expressed through the issuer’s local profile status. Setting a remote user’s profile to Blocked or Banned causes all of their subsequent actions to be refused during the acceptance check described above. There is no separate instance-wide blocklist; blocking is per-profile.

Signature Verification

Every federated action token must pass signature verification before it is accepted:

  1. Key fetch - the issuer’s public key (selected by the token’s key ID) is retrieved from the issuer’s instance, with caching.
  2. JWT signature - the ES384 signature is checked against that key, proving the token was signed by the claimed issuer.

See Key Verification for the caching strategy and failure handling.

See Also