organica/SCoT
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
This proposal defines a **SysAdmin Chain of Trust (SCoT)** protocol for ActivityPub, enabling cryptographically signed, transitively propagated moderation decisions between instance administrators. Unlike existing blocklist mechanisms (CARIAD, Gardenfence, Fediseer), SCoT embeds trust relationships directly into the ActivityPub protocol using standard cryptographic primitives, creating a verifiable DAG (Directed Acyclic Graph) of trust that simultaneously produces a **Shadow Map** of the network — a topological intelligence layer showing known-but-defederated domains and the intermediary paths connecting them.
1 commit 1 branch 0 tags 35 KiB
Find a file
Exact
navigator a8387e358e First Commit
2026-04-01 05:12:13 -03:00
README.md First Commit 2026-04-01 05:12:13 -03:00

README.md

FEP-XXXX: SysAdmin Chain of Trust for Federated Moderation

Status: DRAFT

Authors: PopSolutions Cooperative (organica.social)

Date: 2026-03-31

1. Summary

This proposal defines a SysAdmin Chain of Trust (SCoT) protocol for ActivityPub, enabling cryptographically signed, transitively propagated moderation decisions between instance administrators. Unlike existing blocklist mechanisms (CARIAD, Gardenfence, Fediseer), SCoT embeds trust relationships directly into the ActivityPub protocol using standard cryptographic primitives, creating a verifiable DAG (Directed Acyclic Graph) of trust that simultaneously produces a Shadow Map of the network — a topological intelligence layer showing known-but-defederated domains and the intermediary paths connecting them.

2. Problem Statement

Current Fediverse moderation suffers from three fundamental gaps:

Gap 1: Trust is implicit, not verifiable. When organica.social imports a blocklist from CARIAD or Gardenfence, there is no cryptographic proof of who made the decision, when, or why. The blocklist could be tampered with in transit. There is no chain of accountability.

Gap 2: Moderation decisions don't propagate transitively. If sysadmin Alice blocks pedophilia.example and Alice trusts Bob, Bob's instance does NOT automatically learn about this block. Alice must manually tell Bob, or both must independently subscribe to the same external blocklist. The trust relationship between Alice and Bob is wasted.

Gap 3: The blocked network is invisible. When an instance is defederated, it disappears completely. There is no record of WHY it was blocked, no map of what it connects to, no visibility into intermediary instances that might serve as bridges for social engineering, influence operations, or grooming networks. We know WHERE we don't go, but not WHAT connects to those places.

3. Design Principles

  1. Human-first, crypto-verified. Trust originates from human relationships between sysadmins who know each other. Cryptography verifies and propagates those decisions. No blockchain, no consensus algorithm, no proof-of-work. The "chain" is a chain of human attestation, not a ledger.

  2. Transitive with attenuation. If Alice trusts Bob (depth=2), and Bob trusts Carol (depth=1), then Alice transitively trusts Carol's moderation decisions at attenuated weight. Trust decays with distance, like PGP's web of trust.

  3. Block propagation, not content propagation. This protocol federates moderation DECISIONS, not content. It never touches user posts, DMs, or media. It operates exclusively on the administrative plane.

  4. Shadow visibility. Blocked domains are not deleted from the graph — they remain as shadow nodes, creating a map of the adversarial topology. An instance can see: "we don't federate with X, but X federates with Y and Z, and Z is 2 hops from our trusted peer W through intermediary V."

  5. Local autonomy is absolute. Every sysadmin can VETO any propagated block for their own instance. Trust is advisory. The receiving instance always has final say.

  6. Temporal bounds. All trust relationships and all blocks MUST have an expiration date. Nothing is permanent. Renewal is an active, conscious human decision.

4. Protocol Specification

4.1 Trust Establishment (SysAdmin Identity)

Each instance participating in SCoT has a Moderation Actor:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v2",
    "https://organica.social/ns/scot/v1"
  ],
  "type": "Service",
  "id": "https://organica.social/actor/scot",
  "name": "organica.social SCoT Moderator",
  "preferredUsername": "scot",
  "inbox": "https://organica.social/actor/scot/inbox",
  "outbox": "https://organica.social/actor/scot/outbox",
  "publicKey": {
    "id": "https://organica.social/actor/scot#main-key",
    "owner": "https://organica.social/actor/scot",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
  },
  "scot:trustPolicy": {
    "maxDepth": 3,
    "defaultExpiry": "P180D",
    "requireEvidence": true,
    "autoAction": "review",
    "minimumTrustScore": 0.6
  }
}

The scot:trustPolicy declares the instance's posture:

  • maxDepth: how many hops of transitive trust to honor (3 = trust friends-of-friends-of-friends)
  • defaultExpiry: ISO 8601 duration for trust links
  • requireEvidence: whether incoming blocks must include evidence URIs
  • autoAction: what to do with propagated blocks: review (queue for human), limit (auto-silence), suspend (auto-block), ignore
  • minimumTrustScore: threshold below which propagated blocks are discarded

4.2 Trust Link (SysAdmin-to-SysAdmin)

Trust is established via a signed scot:Trust activity:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://organica.social/ns/scot/v1"
  ],
  "type": "scot:Trust",
  "id": "https://organica.social/scot/trust/001",
  "actor": "https://organica.social/actor/scot",
  "object": "https://cooperativa-b.example/actor/scot",
  "scot:trustLevel": "full",
  "scot:trustDepth": 2,
  "scot:trustScope": ["domain-block", "actor-block", "bot-detection"],
  "scot:humanAttestation": {
    "attestedBy": "marcos@organica.social",
    "attestedVia": "in-person-meeting",
    "attestedAt": "2026-03-15T14:00:00Z",
    "fingerprint": "A1B2:C3D4:E5F6:7890:ABCD:EF01:2345:6789"
  },
  "published": "2026-03-31T12:00:00Z",
  "expires": "2026-09-27T12:00:00Z"
}

Key fields:

  • scot:trustLevel: full (weight 1.0), partial (weight 0.5), marginal (weight 0.25) — directly from PGP trust model
  • scot:trustDepth: how many hops this trust extends transitively (depth=2 means my trust of B extends to B's direct trustees)
  • scot:trustScope: which types of moderation decisions to accept
  • scot:humanAttestation: proof that a human sysadmin established this link. The attestedVia field records HOW (in-person, video-call, pgp-signed-email, cooperative-assembly-vote). The fingerprint is the SHA-256 of the remote instance's SCoT public key, verified out-of-band.

Trust is unidirectional. A trusts B does NOT imply B trusts A. Bidirectional trust requires two separate Trust activities.

4.3 Trust Score Calculation

Trust score for a path is calculated as:

score(A → B) = level_weight(A→B)

score(A → B → C) = level_weight(A→B) × level_weight(B→C) × decay(depth)

decay(d) = 1.0 / (1 + 0.5 × d)

Where level_weight maps: full=1.0, partial=0.5, marginal=0.25.

For multiple paths to the same target, scores combine using the max-flow model (from Sequoia's WoT implementation):

effective_score(A → Z) = max(score(path_1), score(path_2), ...)

Note: we use max, not sum. This prevents gaming by creating many weak paths. The strongest single path determines the score.

Example:

  • A trusts B (full, depth=2), B trusts C (partial, depth=1)
  • A trusts D (partial, depth=2), D trusts C (full, depth=1)
  • Path A→B→C: 1.0 × 0.5 × 0.667 = 0.333
  • Path A→D→C: 0.5 × 1.0 × 0.667 = 0.333
  • Effective score for C's decisions: max(0.333, 0.333) = 0.333

If A's minimumTrustScore is 0.3, C's blocks are accepted for review. If 0.4, they are discarded.

4.4 Block Propagation

When a trusted instance issues a block:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://organica.social/ns/scot/v1"
  ],
  "type": "scot:ModerationSignal",
  "id": "https://organica.social/scot/signals/2026-03-31-001",
  "actor": "https://organica.social/actor/scot",
  "object": {
    "type": "scot:DomainBlock",
    "domain": "pedophilia.example",
    "severity": "suspend",
    "category": ["csam", "grooming"],
    "evidence": [
      "https://organica.social/scot/evidence/2026-03-31-001"
    ]
  },
  "scot:propagation": {
    "originChain": [
      {
        "instance": "https://organica.social",
        "decidedAt": "2026-03-31T10:00:00Z",
        "decidedBy": "cooperative-assembly",
        "signatureHash": "sha256:abcdef1234567890..."
      }
    ],
    "hopsRemaining": 2,
    "attenuatedScore": 1.0
  },
  "published": "2026-03-31T12:00:00Z",
  "expires": "2026-09-27T12:00:00Z",
  "to": [
    "https://cooperativa-b.example/actor/scot",
    "https://cooperativa-c.example/actor/scot"
  ]
}

When cooperativa-b receives this and re-propagates:

{
  "type": "scot:ModerationSignal",
  "actor": "https://cooperativa-b.example/actor/scot",
  "object": { ... same DomainBlock ... },
  "scot:propagation": {
    "originChain": [
      {
        "instance": "https://organica.social",
        "decidedAt": "2026-03-31T10:00:00Z",
        "decidedBy": "cooperative-assembly",
        "signatureHash": "sha256:abcdef1234567890..."
      },
      {
        "instance": "https://cooperativa-b.example",
        "relayedAt": "2026-03-31T12:05:00Z",
        "relayedBy": "admin-review",
        "signatureHash": "sha256:fedcba0987654321..."
      }
    ],
    "hopsRemaining": 1,
    "attenuatedScore": 0.667
  }
}

Each relay:

  1. Decrements hopsRemaining
  2. Appends its own entry to originChain with a signature hash
  3. Recalculates attenuatedScore based on the trust link weight
  4. Signs the entire activity with its HTTP Signature

When hopsRemaining reaches 0, propagation stops.

4.5 The Shadow Map

This is the novel contribution. Every instance maintains a Shadow Graph — a local database of ALL domains it has learned about through SCoT, including blocked ones. The graph has three node types:

TRUSTED   — domains in the active trust graph (federated)
SHADOWED  — domains known to exist but blocked (defederated)
OBSERVED  — domains seen in federation metadata but not classified

And three edge types:

TRUSTS        — active SCoT trust link
FEDERATES     — known federation relationship (from metadata)
BRIDGES       — suspected bridging path (computed, not observed)

The Shadow Map is built from:

  1. SCoT signals: every ModerationSignal reveals the originChain, which tells us which instances relay which blocks.
  2. Federation metadata: standard ActivityPub discovery reveals which instances an actor's server federates with (via HTTP Signature verification, shared followers, boosted content).
  3. Known-peers of blocked domains: when domain X is blocked, any instance that previously federated with X and still federates with a TRUSTED node is marked as a potential BRIDGE.

Shadow Map Queries

An admin can query their local Shadow Map:

"What connects us to the blocked domain?"

organica.social → cooperativa-b → intermediary-v → [SHADOWED: pedophilia.example]
                                                  ↘ [SHADOWED: spam-farm.example]

This reveals that intermediary-v federates with both blocked domains. It doesn't mean intermediary-v is malicious — but it means content from those domains COULD reach our network through intermediary-v if intermediary-v federates with cooperativa-b.

"Which intermediaries connect the most shadow nodes?"

intermediary-v.example: bridges to 12 shadowed domains
questionable-relay.example: bridges to 8 shadowed domains
open-federation.example: bridges to 47 shadowed domains

This is intelligence, not a blocklist. The admin decides what to do.

"What's the shortest path from a shadowed domain to our trust ring?"

pedophilia.example → intermediary-v → cooperativa-b → organica.social
                     (2 hops, bridge node = intermediary-v)

4.6 Veto and Override

Any receiving instance can veto a propagated block:

{
  "type": "scot:Veto",
  "actor": "https://cooperativa-c.example/actor/scot",
  "object": "https://organica.social/scot/signals/2026-03-31-001",
  "content": "We have independently verified this domain is legitimate",
  "scot:vetoScope": "local"
}

vetoScope options:

  • local: block not applied on this instance, but propagation continues
  • propagated: block not applied AND downstream instances are notified

4.7 Retraction

{
  "type": "Undo",
  "actor": "https://organica.social/actor/scot",
  "object": "https://organica.social/scot/signals/2026-03-31-001",
  "scot:retraction": {
    "reason": "False positive confirmed",
    "retractedBy": "cooperative-assembly",
    "retractedAt": "2026-04-15T10:00:00Z"
  }
}

Retractions propagate along the same chain, with the same hop logic.

5. Trust Graph vs Blockchain: Why NOT a Blockchain

The "blockchain" analogy is instructive but the implementation diverges:

Property Blockchain SCoT
Consensus All nodes must agree Trust is local, no global consensus
Immutability Append-only ledger Trust links expire and are retractable
Verification Proof-of-work/stake HTTP Signatures + human attestation
Topology Flat (all peers equal) DAG (trust has direction and depth)
Cost Computational Social (human relationship maintenance)
Failure mode 51% attack Social engineering of trust links
Scalability O(n) nodes verify O(depth) hops verify

SCoT is a Directed Acyclic Graph of human attestation, verified cryptographically. Like PGP's Web of Trust, but for instance moderation rather than key authentication.

6. Interaction with Existing Systems

System Relationship
IFTAS CARIAD Can be consumed as a SCoT signal from a synthetic "IFTAS" actor
Fediseer Guarantee = Trust(full, depth=1), Endorsement = Trust(partial, depth=0), Censure = ModerationSignal
FediCheck FediCheck sync → converted to SCoT signals with origin="fedicheck"
Mastodon Admin API SCoT signals map to domain_blocks/domain_allows
HTTP Signatures SCoT relies on existing HTTP Sig for S2S authentication

7. Security Considerations

Trust link compromise: If a trusted instance is compromised, the attacker can issue false ModerationSignals. Mitigation: trust depth limits propagation, autoAction: review requires human confirmation, and any instance can veto.

Sybil attack on trust graph: Creating many fake instances to build trust weight. Mitigation: humanAttestation requires out-of-band verification, max (not sum) prevents weak-path flooding.

Shadow Map privacy: The Shadow Map reveals which instances you know about and your trust topology. It MUST be access-controlled (admin-only). It MUST NOT be exposed via ActivityPub endpoints.

Evidence retention: Evidence URIs in ModerationSignals may contain sensitive content (screenshots of CSAM reports, etc). Evidence objects MUST be access-controlled and SHOULD be deleted after the block expires.

8. Implementation Roadmap

Phase 1: Mastodon Patch (organica.social)

  • SCoT actor and keypair generation
  • Trust link establishment (CLI + admin UI)
  • ModerationSignal send/receive via ActivityPub S2S
  • Shadow Map local database and admin query UI

Phase 2: Fediseer Bridge

  • Import Fediseer guarantees/censures as SCoT trust links/signals
  • Export SCoT trust graph to Fediseer API

Phase 3: FEP Submission

  • Submit to codeberg.org/fediverse/fep
  • Present at SWICG T&S Taskforce
  • Reference implementation as reusable Ruby gem

Phase 4: Multi-software Support

  • GoToSocial adapter
  • Bonfire adapter (co-design with IFTAS)
  • Misskey/Firefish adapter

9. References