Skip to content

Chapter 7 — Team, Trust & Blocking

Stolo's inbound trust model is default-deny: a message from a sender you haven't trusted never lands silently in an inbox. This chapter covers the Team roster, the trust lifecycle, the Quarantine review queue, strict mode, and blocking.

7.1 The Team screen

The Team tab is the personnel roster. The header shows how many people are currently on the mesh, a Blocked peers button (marked with a red dot when anyone is blocked), and an Add personnel (announce) action that broadcasts a fresh presence announce to speed up discovery.

Your own card appears first, showing your callsign, role, avatar, your device's mesh identity hash, and — if you publish under an organization — "publishing as ‹org›".

Each peer row shows:

  • Display name and presence status (ON SCENE / EN ROUTE / AVAILABLE / IDLE / OFF DUTY).
  • Link summary: Direct, N hops, or no path, plus which connection type carries them and when they were last heard.
  • A vendor badge (see Chapter 8) and a TRUSTED badge when a trust grant exists.
  • An overflow menu: Open Chat, Info, and Block / Unblock.

Peers can be filtered (All / Command / Medical / Tactical) and searched by name or callsign.

Presence states

Presence is driven by mesh announces:

State Condition
Active Announced recently and app in foreground
Idle ~6 minutes without being heard (or app backgrounded)
Offline ~12 minutes without being heard

7.2 The trust lifecycle

  1. Discovered. A peer appears on the roster as soon as its announce is heard. Discovery alone conveys no trust — you can see them; their messages don't reach your inbox yet.
  2. First message → Quarantine. A message from an untrusted sender is held in Quarantine and a badge appears on the Messages screen.
  3. Operator decision. From the Quarantine screen you grant trust (sender or organization), accept once, or deny/block.
  4. Trusted. Once trusted, the sender's messages deliver directly, and the peer wears the TRUSTED badge. Trust grants apply per sender (or per organization — see Chapter 8).

Trust is always revocable: Settings → Security → Trusted peers → Remove trust returns future messages from that sender to quarantine.

Signature enforcement. Trust decisions are backed by cryptography, not sender-claimed names. Every delivered message must carry a valid signature from the sender's identity key. A message that claims a trusted sender's address but fails signature validation is quarantined, never delivered — sender spoofing cannot bypass the trust gate.

7.3 Quarantine

The Quarantine screen is the review inbox for held messages. Each card shows the sender (resolved name when known, otherwise the sender hash), when it arrived, why it was held (UNTRUSTED SOURCE — sender seen via an organization you haven't trusted; UNKNOWN SENDER — never-seen sender), and a text preview.

Five actions are available per message:

Action Effect
Trust sender Delivers the message and whitelists this sender permanently — future messages deliver directly.
Trust org Delivers the message and trusts the sender's entire organization — all verified members deliver directly from now on. Enabled only when the peer has advertised a verified organization.
Accept once Delivers this one message. Grants nothing; the next message from this sender quarantines again.
Deny Discards the message (confirmation required). The sender is not trusted; future messages will quarantine again.
Deny & Block Discards the message and blocks the sender for a duration you pick.

Accepting also warms the network path to the sender, so your reply doesn't stall.

Quarantine housekeeping (automatic)

  • Held messages expire after 7 days and are purged hourly.
  • The quarantine store is strictly bounded against abuse: at most 8 MB per message, 20 held messages per sender (a flooding sender evicts only its own oldest entries), and global caps of 500 messages / 128 MB. Blocking a sender purges all of their pending quarantine entries.

7.4 Strict mode

Settings → Security → Strict mode (default off) raises the floor from quarantine to drop: messages from senders that are neither individually trusted nor members of a trusted organization are dropped silently instead of quarantined. Use it when the device should only ever hear from pre-approved peers — e.g. fielded devices where nobody reviews a quarantine queue. Explicit trust grants still deliver normally.

7.5 Blocking

Block a peer from the Team roster's overflow menu, the connection detail sheet in a chat, or Deny & Block in Quarantine. You choose a duration:

  • 1 hour
  • 24 hours
  • 7 days
  • Permanent

Blocking is enforced at the network layer: the engine blackholes the peer's device identity, so their messages are dropped in the router, existing links are torn down, and routing paths are purged. Blocking also revokes any trust grant and clears the sender's pending quarantine entries.

Notes:

  • Blocking keys on the peer's device identity. Two devices in the same organization are blocked independently — blocking one does not block its colleagues.
  • If a peer's identity isn't yet known (they've never announced within earshot), Stolo reports "Can't block yet — this peer's identity isn't known to the network (wait for an announce)." From Quarantine, the message is still denied even when the block can't yet be applied.
  • The Blocked sheet (Team header) lists every active block with its expiry (Permanent or Until ‹date›) and offers Unblock.