Build the path,
not just the endpoint.
An overlay is a social agreement made executable: what belongs, who keeps it, how newcomers catch up, which questions can be answered, and what evidence travels with each answer.
Open the roadmapThe design order
Start with shared interest. Technology cannot create a stewardship community that does not exist.
A production-minded path
Write the sentence
Define the public interest before the code.
“This topic contains ___ when ___, and stops tracking it when ___.”
- Name one bounded dataset
- Name who benefits from sharing it
- Name what must never be admitted
Specify admission
Make belonging deterministic and versioned.
Implement a BRC-22 topic manager and publish test vectors for accepted, rejected, and spent outputs.
- Validate scripts and payloads
- Define state transitions
- Reject ambiguous versions
Specify questions
Design for the reader, not the database.
Implement BRC-24 lookup queries with stable parameters, pagination, and proof-bearing responses.
- List real user questions
- Set canonical identifiers
- Document empty and error states
Carry evidence
Treat proofs as part of the record.
Exchange transactions using current BEEF/Atomic BEEF conventions and retain the block evidence needed for SPV validation.
- Validate transaction ancestry
- Upgrade proofs after mining
- Keep raw artifacts portable
Find and synchronize
Let compatible peers discover and catch up.
Advertise through SHIP/SLAP where appropriate; use current GASP behavior for graph-aware synchronization and BASM when confirmed completeness matters.
- Authenticate peer policy
- Bound resource use
- Make sync observable
Rehearse disappearance
Prove the system without its creator.
From a clean host, recover through independent peers, rebuild lookups, verify a known record, and publish the evidence.
- Remove original infrastructure
- Time the recovery
- Repeat after schema changes
Current implementation route
The shortest path
into working code.
The actively maintained TypeScript stack is the safest starting point today. Evaluate versions and deployment requirements from the repositories themselves before production use.
Before production
Operational questions
are protocol questions.
Abuse
What limits submissions, lookups, graph traversal, and peer fan-out?
Privacy
Does replication expose data or relationship metadata people did not expect?
Evolution
How do old and new rule versions coexist without silently changing history?
Completeness
Can a host distinguish “I found nothing” from “I do not have everything”?
Exit
Can users take a verifiable copy without permission from the original operator?
Succession
Who can operate and explain the network when its first author leaves?
Keep going