How DHT peer discovery works in Pelagora
The problem with centralized marketplaces
Every major marketplace — eBay, Etsy, Amazon — operates the same way: sellers upload listings to the platform's database, and buyers search the platform's index. That means the platform controls discovery, pricing visibility, fees, and ultimately who can participate.
Pelagora takes a different approach: there is no central index. Instead, Beacons find each other the same way BitTorrent nodes do — via a Distributed Hash Table.
What is a DHT?
A Distributed Hash Table is a key-value store spread across thousands of nodes. No single node holds the full picture. When you look something up, the request is routed hop-by-hop until it reaches the node closest to that key.
You → Node A → Node C → Node F (holds the key)
↓
Node D (closer, redirects)
Pelagora uses libp2p's Kademlia DHT under the hood — the same protocol powering IPFS and Ethereum's peer layer.
How Beacons announce themselves
When your Beacon starts, it:
- Generates a stable Peer ID from a local keypair
- Announces itself to the DHT under a well-known Pelagora namespace key
- Begins answering
FIND_NODErequests from other Beacons
# You can inspect your Peer ID
curl http://localhost:3000/api/identity
# → { "peerId": "12D3KooW...", "addrs": ["/ip4/..."] }
Schema.org listings
Once peers discover each other, they exchange listing data encoded as Schema.org Offer objects. This makes Pelagora listings inherently machine-readable — AI agents can browse, filter, and negotiate without any custom API contract.
{
"@type": "Offer",
"name": "Channel Islands Surfboard",
"price": "450",
"priceCurrency": "USD",
"availability": "InStock",
"seller": { "@type": "Person", "identifier": "12D3KooW..." }
}
Privacy considerations
Your IP address is visible to peers you connect with — the same trade-off as any P2P protocol. If you need privacy, run your Beacon behind a Tor hidden service or a VPN. We're exploring onion-routing options for a future release.