100 Beacons. 300 Refs. Why These Numbers Matter.

The Network Has to Start Somewhere

Every distributed system has a bootstrap problem. You can't discover peers if there are no peers. You can't browse inventory if there's no inventory. The DHT is real, the PIM protocol is solid, the code is public — but none of that matters until people are actually running Beacons and publishing Refs.

So we're naming the numbers: 100 Beacons. 300 Refs. That's the first threshold we're building toward.

This post explains why those numbers, why now, and what it means for anyone building on Pelagora.

What "First Users" Actually Means on a P2P Network

On a centralized platform, a "user" is a database row. On Pelagora, a user is a node. A live, reachable Beacon participating in the Mesh — publishing Refs, responding to discovery queries, maybe running Skills.

That's a different kind of participation. It's also a more durable one.

When we say 100 users, we mean:

100 Beacons online, discoverable via DHT
100 independent operators — developers, builders, AI agents — controlling their own nodes
100 points of resilience in the network topology

There's no central registry to check. No account dashboard to verify this. A Beacon is either reachable on the Mesh or it isn't. The network knows.

Why 300 Refs?

A Ref is the universal commerce unit on Pelagora — a structured listing built on Schema.org vocabulary, published by a Beacon, discoverable by anyone on the Mesh.

Three Refs per Beacon is a deliberately modest target. We're not chasing inventory volume. We're validating the data layer.

300 Refs means:

The PIM protocol is being used in the wild, across multiple operators
Different Ref types are being published: physical goods, services, rentals, digital assets
Discovery is working — Refs are reachable by other Beacons and by AI agents via the MCP Server
The data format holds up under real-world variance

Early networks don't need depth. They need proof of function across enough independent nodes to confirm the protocol behaves as designed outside of controlled test conditions.

The Bootstrap Problem Is a Design Test

Here's what makes the bootstrap phase interesting from a protocol perspective: it stress-tests assumptions you can't test in isolation.

When we run a single Beacon in a dev environment, we control everything — the data, the peer list, the network conditions. When 100 independent operators run Beacons across different machines, networks, and configurations, we find out what actually breaks.

Some questions only the first 100 can answer:

Discovery latency at low node count. DHT routing works differently when the table is sparse. What's the actual time-to-first-peer for a new Beacon joining a small Mesh?
Schema variance in the wild. Operators will publish Refs we didn't anticipate. How well does the PIM protocol handle edge cases in item categorization, pricing fields, and custom attributes?
Skill compatibility across node versions. Are Skills portable between Beacons running slightly different configurations?
MCP Server behavior under real agent queries. AI agents don't ask for data the way humans do. The first 100 Beacons will surface tool-call patterns we haven't seen in testing.

This isn't a beta. It's primary research.

What Operators Get From Being Early

Let's be direct: running a Beacon today means tolerating rough edges. The tooling is functional but not polished. Documentation covers the critical paths but not every edge case. Some Skills are still experimental.

What early operators get in return:

Direct protocol influence. The behavior you find strange or limiting shapes the next version. Issues and PRs from early operators carry weight because they're grounded in real operation.
Network seniority. DHT-based networks have a concept of node longevity. Beacons that have been on the Mesh longest tend to have better-populated routing tables and faster peer discovery.
First-mover data. If you're publishing Refs on a network where discovery is sparse, your inventory gets found. Low competition, high signal.
Access to the builders. Discord is active. The core team reads everything. If you're running a Beacon in this phase, you're not a ticket in a support queue.

What We're Doing to Get There

Growth on an open network isn't the same as growth on a platform. We can't run an ad to acquire Beacon operators. We can't offer a referral bonus in tokens. The network grows when builders decide it's worth running.

So here's what we're focused on:

Reducing setup friction. The time from git clone to a live Beacon on the Mesh should be under 10 minutes. We're auditing every step in the setup flow and cutting anything that doesn't need to be there.

Publishing real examples. Not toy demos — actual Beacon configurations that do something useful. A Beacon running a service Ref. A Beacon with a custom Skill. A Beacon connected to an AI agent via MCP Server. Real code, real output.

Making the MCP Server integration obvious. AI agent developers are some of the most motivated early adopters. If your agent can query the Mesh for live inventory, that's a genuinely useful capability. We need to make that integration path clear and copy-paste ready.

Documenting the PIM protocol edge cases. Every time an operator hits a schema question that isn't in the docs, that's a documentation bug. We're tracking these and patching them continuously.

Keeping the repo public and active. Commit history is trust. A repo that went quiet three months ago sends a message. We ship in the open.

How to Run Your Beacon

If you want to be part of the first 100, here's the path:

# Clone the repo
git clone https://github.com/pelagora/beacon
cd beacon

# Install dependencies
npm install

# Configure your Beacon
cp config.example.json config.json
# Edit config.json — set your node name, Ref categories, Skills

# Start your Beacon
npm start

Your Beacon will announce itself to the DHT and start building its peer table. Publish your first Ref and it becomes discoverable across the Mesh.

Full setup docs: pelagora.net/docs/beacon-setup

MCP Server integration: pelagora.net/docs/mcp-server

The Agora Doesn't Build Itself

The ancient agora worked because people showed up. They set out their wares. They called out their prices. The infrastructure — the open square, the public space — was necessary but not sufficient. It needed participants.

Pelagora is the same. The DHT is running. The PIM protocol is defined. The MCP Server is live. But the Mesh is only as real as the Beacons on it.

100 Beacons. 300 Refs. That's the threshold where the network stops being a protocol and starts being a place.

If you're building something that touches commerce, inventory, or agent-driven discovery — run a Beacon. Publish some Refs. Break things in interesting ways.

The code is at github.com/pelagora. The Discord is open. The network is waiting for nodes.

The agora was open to all. The internet should be too.