SkateSpots/docs/THREAT_MODEL.md

SkateSpots threat model

This is the short, technical version of what SkateSpots can and cannot guarantee. It exists so product copy, support answers and future code do not accidentally promise consensus, arbitration or delivery verification that the system does not have.

The model in one sentence

SkateSpots verifies signed facts, keeps a local view, and uses social/economic signals at value boundaries. It does not run a consensus protocol.

Nostr relays are not voters. A relay can withhold, censor, reorder or serve a stale event, but it cannot forge a valid signature. Different clients can therefore see different snapshots of the network without either side being "wrong" in a Byzantine-consensus sense.

Assets

• Nostr identity keys and local signer access.
• Local cache, drafts, pending posts and local deletion tombstones.
• Crew membership and Cordn group membership.
• Marketplace listings, offers, trade attestations and reputation.
• Cashu proofs and escrow tokens.
• Device storage and any local backup/export.

Actors and trust boundaries

Actor	Can do	Cannot do
Author	Sign events with their key	Forge another author's signature
Relay	Withhold, censor, reorder, serve stale or conflicting signed events	Forge a valid event; guarantee availability
Cordn coordinator	Route opaque group ciphertext; drop or delay messages	Read plaintext; forge an author proof
Cashu mint	Issue/redeem proofs, enforce locktime, freeze or become insolvent	Spend a correctly locked P2PK proof without a valid witness
Founder/admin	Modify the crew record, moderate crew content	Forge members' signatures; guarantee global agreement
Buyer/seller	Publish attestations and payment/receipt claims	Make a false claim true by signing it
WebView / host	Run the client	Be assumed trustworthy after device compromise

Guarantees

• Authenticity: a valid Schnorr signature proves which key signed an event, not that the content is true.
• Availability: the client can use cached data and multiple relays; there is no guarantee that every relay has every event.
• Local determinism: when two valid versions of an addressable or replaceable event exist, the client chooses the newest created_at, with an event-id tie-breaker. This is deterministic, not globally agreed.
• Deletion: NIP-09 is a request. Local tombstones prevent a deleted item from flashing back on that device; relays may ignore the request.
• Payments: a Lightning preimage proves the invoice was paid. It does not prove goods were delivered.
• Escrow: a time-locked Cashu P2PK token protects the buyer after the lock expires and lets the seller redeem on delivery. It is not arbitration and does not prove delivery.
• Reputation: reciprocal signed attestations, distinct partners and web-of-trust weighting are evidence. Two colluding accounts can still create a fake trade; the app must not present that as proof of goods.

Non-guarantees

• No global ordering or consensus over relays.
• No protection from a compromised identity key, signer or device.
• No guaranteed delivery or carrier verification.
• No neutral dispute resolution.
• No guarantee that every relay honours deletion or moderation.
• No guarantee that a mint remains solvent, online or P2PK-compatible.
• No anonymity guarantee: public events, relays, image hosts and map/weather providers may observe network metadata.
• No guarantee that a Cordn coordinator cannot censor a group. It cannot read or forge messages, but it can drop them.

Cordn specifically

The current Cordn group scheme is NIP-44 group delivery with a signed author proof inside the ciphertext. It is not full MLS yet: it does not provide MLS forward secrecy or post-compromise security. A coordinator cannot read the message or impersonate the author, but it can refuse to relay it.

Marketplace safety rules

• Prefer escrowed or in-person deals for high-value trades.
• Never send a plain, unlocked Cashu token in a public event.
• Treat "confirmed trade" as "both parties signed", not "goods verified".
• Treat "payment verified" as "the money leg is verified".
• A new account with no distinct confirmed partners is a warning, not a ban.
• Cash, barter and off-platform settlement have no on-chain proof; use reputation and judgement.

Privacy boundaries

• Public Nostr events are public forever in practice; deletion is best-effort.
• DMs and Cordn ciphertext are encrypted, but metadata (who, when, which group) may be visible to relays/coordinators depending on the feature.
• Images are public once uploaded; strip metadata before upload and do not put addresses in public listing images.
• Self-hosted infrastructure avoids third-party analytics, but network observers can still see traffic to relays, image hosts, map tiles and weather services.

What would change this model

A real consensus or arbitration layer would need a separate design with explicit participants, quorum, liveness, slashing/appeals and privacy trade-offs. It should not be smuggled in as "trust" copy or a global score. Until then: signed facts, local merge, explicit boundaries, no fake guarantees.