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>
2.3 KiB
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
- App developers publish signed manifests as Nostr events to public relays
- Archipelago nodes query multiple relays for available app manifests
- Trust scoring uses verification count across relays, developer reputation (DID-linked), and optional community endorsements
- 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