SeD: Decentralized Service Discovery & Evidence-Based Web of Trust
Hi everyone,
I’d like to share a protocol proposal that I (with contributions from other brilliant minds, Tobechi, Tim, and Okjodom) have called the Service Discovery (SeD) protocol, an open peer-discovery and reputation framework built on Nostr. Designed for cross-border payment providers, liquidity desks, and Bitcoin fintechs, all categorized as “Services.”
SeD enables automated capability signaling (e.g., local mobile money rails, fiat on/off-ramps) and local counterparty vetting. It strictly decouples discovery from transactional logic, utilizing NIP-05 for identity verification, NIP-09 for revocations, and local client-side Web of Trust (WoT) calculations to prevent reputation gaming.
The formal specification proposal can be found in this PR to SeD GitHub repository."
The Problem
B2B financial expansion into fragmented markets (e.g., a service like Mavapay expanding from Nigeria to Tanzania) relies on manual, opaque workflows to find and vet local liquidity desks. High-quality local desks lack a standardized, programmatic way to signal capabilities.
Protocol Architecture
[ Local Client ] ──► (Subjective Anchor) ──► [ Trusted Peer ] ──► (Graph Distance `N`) ──► [ Target IPK ]
▲
(NIP-05 DNS Verification)
│
[ Hot Operational Key (OPK) ]
1. Identity Verification (SeD-01)
To isolate hot-server risk, services maintain two standard Nostr public keys:
-
Identity Public Key (IPK): A highly secured keypair representing the permanent public identity of the service. Long-term attestations hook into this key.
-
Operational Public Key (OPK): A live, unified hot key managed by the production server to sign daily network broadcasts.
Connection is handled via NIP-05. Services host a static JSON file at https://<domain.com>/.well-known/nostr.json mapping the domain to the valid keys:
{
"names": {
"_": "hex_encoded_master_ipk_pubkey",
"api": "hex_encoded_hot_unified_opk_pubkey"
}
}
2. Capability Signaling (SeD-02)
Hot OPKs advertise infrastructure configurations via Parameterized Replaceable Events (kind:30078). Relays overwrite stale data using a uniform identifier tag (["d", "capability-signal"]).
{
"kind": 30078,
"pubkey": "<Unified_API_OPK_Hex_Pubkey>",
"tags": [
["protocol", "sed"],
["d", "capability-signal"],
["nip05", "api@service.com"],
["region", "NG"], ["region", "TZ"],
["currency", "NGN"], ["currency", "TZS"],
["rail", "bank"], ["rail", "m-pesa"],
["capacity_tier", "tier_3"],
["expiration", "1783313600"],
["endpoint", "api.service.com", "443"]
],
"content": "Unified API Gateway for West and East African corridors."
}
3. Evidence-Based Attestations (SeD-03 & SeD-05)
SeD rejects subjective scores. When a transaction concludes off-chain, the counterparty publishes immutable cryptographic facts using Regular Event Range (Kind 1, 4-44, 1000-9999) for permanent relay storage anchored to the target’s Master IPK.
Volume figures and SLAs are obfuscated into broad categories to preserve privacy:
-
Volume Tiers:
–tier_1: (<$500),
–tier_2: ($500–$5k),
–tier_3: ($5k–$50k),
–tier_4: (>$50k). -
Performance:
–sla_compliance: target_metorsla_compliance: target_missed.
Evaluation (SeD-05): Querying clients calculate the trust graph locally based on proximity to their own subjective, trusted seed nodes. Collusive sybil rings have an infinite graph distance from trusted seeds, filtering them out automatically.
4. Edge-Client Implementation (SDK)
SeD shifts risk computation entirely to the edge. Participating nodes integrate a lightweight backend SDK/library to automate network interaction:
-
For Searchers: Connects to relays, enforces automated NIP-05 website handshakes, and maps local Web of Trust graphs.
-
For Providers: Automates periodic
kind:30078signal heartbeats and signs outgoing transaction attestations off-chain.
5. Revocations & Mitigation (SeD-04)
If an active hot production server is breached and its OPK private key is compromised:
-
DNS Disavowal: The admin removes the compromised OPK from the domain’s
nostr.jsonfile. Downstream clients run NIP-05 checks on query and immediately reject the key. -
Relay Scrubbing: The admin broadcasts a standard NIP-09
kind:5“Deletion Request” to clear the old capability advertisements from relay databases.
Open Design Questions
-
Relay Data Pruning: Since attestations are cumulative and regular, how should we approach long-term storage scaling without losing historical data?
-
Encryption: For private B2B corridors, the proposal is to encrypt the payload body using NIP-44. Does leaving the target
ptags unencrypted for graph routing introduce unacceptable metadata leakage?
The complete protocol specification proposal (SeD-01 through SeD-06) is here
Architectural critiques are welcome directly on the repository or in the comments below.