The contact/community invite is the most likely spam and abuse carrier in the mesh, and nothing currently defends it.
Existing coverage does not reach this
AV-10 (transport flood), AV-13 (body size) and AV-48 (high-N low-T signed envelope flood) are all volume defenses, and AV-48's trust threshold defaults to 0.0 bootstrap-permissive. An invite is low-volume, well-formed, correctly signed, and semantically hostile. That class is not in the threat model.
Shape: request is transport, acceptance is CEG
Grounded in ciris-persist v38.7.0:
consent_state::ALL = [ granted, revoked, expired ]
There is no requested / pending state — the grammar models consent that has been given, never consent being asked for. Adding one would be a CC §4.5.1 Standards Action, and it is the wrong move anyway.
So:
- an invite travels point-to-point over RNS and leaves no federation-visible trace;
- acceptance mints a
granted consent row, which already has a home.
That asymmetry is the defense: spam never reaches the ledger, and refusal costs nothing and publishes nothing — which is what a refusal has to be.
Rate limiting
Per (sender, receiver) pair, enforced at the receiver — a sender-side limit is advice. Small budget, slow refill: a stranger gets one attempt, not a retry loop. Senders a receiver has never accepted decay toward zero.
Applied before the invite is surfaced to the human, so the spam cost is borne by the node and not the person.
Not in scope here
Fetch rate limiting (the enumeration control) rides with #552 — different thing, different target: this protects people, that protects the directory.
Related: #552 · docs/THREAT_MODEL.md (AV-10 / AV-13 / AV-48)
The contact/community invite is the most likely spam and abuse carrier in the mesh, and nothing currently defends it.
Existing coverage does not reach this
AV-10 (transport flood), AV-13 (body size) and AV-48 (high-N low-T signed envelope flood) are all volume defenses, and AV-48's trust threshold defaults to
0.0bootstrap-permissive. An invite is low-volume, well-formed, correctly signed, and semantically hostile. That class is not in the threat model.Shape: request is transport, acceptance is CEG
Grounded in
ciris-persistv38.7.0:There is no
requested/pendingstate — the grammar models consent that has been given, never consent being asked for. Adding one would be a CC §4.5.1 Standards Action, and it is the wrong move anyway.So:
grantedconsent row, which already has a home.That asymmetry is the defense: spam never reaches the ledger, and refusal costs nothing and publishes nothing — which is what a refusal has to be.
Rate limiting
Per
(sender, receiver)pair, enforced at the receiver — a sender-side limit is advice. Small budget, slow refill: a stranger gets one attempt, not a retry loop. Senders a receiver has never accepted decay toward zero.Applied before the invite is surfaced to the human, so the spam cost is borne by the node and not the person.
Not in scope here
Fetch rate limiting (the enumeration control) rides with #552 — different thing, different target: this protects people, that protects the directory.
Related: #552 · docs/THREAT_MODEL.md (AV-10 / AV-13 / AV-48)