archy/docs/adr/006-nostr-marketplace-discovery.md
Dorian f149586559 docs: finalize ADRs with 4 new records (FINALDOC-03)
ADR-006: Nostr relays for decentralized marketplace discovery
ADR-007: DID-based bilateral federation trust
ADR-008: Dual key strategy (Ed25519 + secp256k1)
ADR-009: Manifest-level container security enforcement

Total: 9 ADRs covering all significant architectural decisions.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-11 17:23:40 +00:00

2.3 KiB

ADR-006: Nostr Relays for Marketplace Discovery

Status

Accepted

Context

Archipelago needs a mechanism for users to discover and install third-party applications. The traditional approach is a centralized app store (like Apple App Store, Google Play, or Umbrel's marketplace). However, a centralized store introduces:

  • A single point of failure and censorship
  • A trust dependency on the store operator
  • Barriers to entry for app developers (gatekeeping)
  • Privacy concerns (the store operator knows what every user installs)

As a sovereign computing platform, Archipelago should align with decentralized principles.

Decision

Use Nostr relays (NIP-78 application-specific data, kind 30078 events) for decentralized app manifest discovery instead of a centralized marketplace server.

How It Works

  1. App developers publish signed manifests as Nostr events to public relays
  2. Archipelago nodes query multiple relays for available app manifests
  3. Trust scoring uses verification count across relays, developer reputation (DID-linked), and optional community endorsements
  4. Users see a merged, deduplicated list of available apps with trust indicators

Trust Tiers

  • Verified: Published by known developers, seen on 3+ relays, DID-verified
  • Community: Seen on 2+ relays, valid manifest, unsigned or new developer
  • Unverified: Single relay, new developer, use at own risk

Consequences

Positive

  • No single point of failure — apps remain discoverable even if relays go offline
  • No gatekeeping — any developer can publish apps
  • Privacy-preserving — no central server tracking installs
  • Censorship-resistant — apps can't be removed by a single entity
  • Aligns with Nostr ecosystem already used for node identity

Negative

  • Discovery can be slower (querying multiple relays)
  • Quality control relies on trust scoring rather than human curation
  • Spam/malicious manifests require robust filtering
  • Users need to understand trust tiers (not a simple "everything is safe" model)

Mitigations

  • Cache relay responses locally for fast subsequent loads
  • Built-in curated app list for essential apps (Bitcoin, LND, etc.)
  • Container security model (readonly_root, capability dropping) limits damage from malicious apps
  • Manifest signature verification before installation