**Goal:** Break down Kapnet protocol concepts into digestible public notes. **Audience:** Crypto-native developers, Bitcoin curious, protocol researchers. **Format:** Thread-style notes kind-1, each e
§Kapnet Erudition Campaigns — Three Hashtag Strategies
§Campaign 1: #KapnetExplainers
Goal: Break down Kapnet protocol concepts into digestible public notes.
Audience: Crypto-native developers, Bitcoin curious, protocol researchers.
Format: Thread-style notes (kind-1), each explaining one concept.
Tone: Technical but accessible. Assume Bitcoin literacy, teach Kapnet specifics.
§Content Calendar (First 2 Weeks)
| Day |
Topic |
Hook |
| 1 |
What is Kapnet? |
“Bitcoin has a coordination problem. Kapnet is the solution.” |
| 2 |
Submissions: atomic civil acts |
“Every post, vote, and contract is a submission. Not a message—a civil act.” |
| 3 |
TXXM Envelopes |
“Think of TXXM as HTTP for coordination. But deterministic, replayable, and Bitcoin-anchored.” |
| 4 |
Weakwork vs Proof-of-Work |
“Not all work is equal. Weakwork prices coordination before settlement.” |
| 5 |
Braids: concurrent history |
“Git branches meet Bitcoin finality. Braids capture all valid orderings.” |
| 6 |
Knots: checkpoints |
“A knot is a braid frozen in time. A commitment to what happened.” |
| 7 |
Week 1 recap |
Top 3 most-engaged explainers, preview week 2 |
| 8 |
KOR Namespaces |
“KOR = tenant-isolated coordination rooms. Like Docker containers for protocols.” |
| 9 |
Hedlbit accounting |
“Coordination has costs. Hedlbits price relay, storage, and execution.” |
| 10 |
Deterministic slot lottery |
“How Kapnet selects winners without coinbase commitments.” |
| 11 |
Endo/Exo Nexus |
“Every Kapnet interaction is simultaneously coordination AND communication.” |
| 12 |
Merge-mining |
“Kapnet rides Bitcoin’s security. Merge-mining explained.” |
| 13 |
Public vs private relays |
“Public relays accept standard kinds. Kapnet wraps TXXM in kind-30078.” |
| 14 |
Week 2 recap + Q&A |
Answer top questions from replies |
§Engagement Tactics
- End each note with a question to invite replies
- Reply to every response within 1 hour
- Cross-reference earlier explainers
- Pin the series as a profile highlight
§KPIs
- Notes published: 14
- Target reply rate: >30%
- Target follower growth: >50 new followers
- Hashtag impressions: >1000
§Campaign 2: #KapnetBuilds
Goal: Show Kapnet being built in public. Live development updates.
Audience: Builders, open-source contributors, potential collaborators.
Format: Short progress notes (kind-1) + milestone threads (kind-30078).
Tone: Raw, unpolished, honest. Here’s what we built today. Here’s what broke.
§Content Calendar (First 2 Weeks)
| Day |
Topic |
Content |
| 1 |
Project intro |
“Building Kapnet in public. Here’s the stack.” |
| 2 |
Stack deep-dive |
“Rust daemon, Node.js bridges, Qubes security, Nostr transport.” |
| 3 |
What shipped |
“TUI with F8 overlays. Courier Bridge v2. Listener on 2 relays.” |
| 4 |
What broke |
“Custom Nostr kinds rejected on public relays. Built a bimap.” |
| 5 |
Code snippet |
One interesting function with explanation |
| 6 |
Architecture decision |
“Why we chose file-based signal bus over direct IPC.” |
| 7 |
Week 1 demo |
Screen recording of TUI + listener + bridge |
| 8 |
Scaling challenges |
“Qubes has no C compiler. Cross-compiling for Mac Mini.” |
| 9 |
Protocol gap |
“Codebase expects Kapnet-aware relays. Reality: public Nostr.” |
| 10 |
The solution |
“kapnet-nostr-bridge.mjs: TXXM kind 30001 → kind 30078 + k=30001” |
| 11 |
Testing |
“How we verify: publish, receive, unwrap, validate.” |
| 12 |
Open problems |
“Block parser needs node data. Treasury needs Mac Mini.” |
| 13 |
Community ask |
“What should we build next? Tell us.” |
| 14 |
Week 2 roadmap |
“Next: Mac Mini arrives, self-hosted relay, kor.git GitHub org.” |
§Engagement Tactics
- Ask for input on every “what should we build” note
- Share actual code snippets (not descriptions)
- Show failures, not just wins
- Tag other builders/projects when relevant
- Invite contributions via GitHub (when kor.git is ready)
§KPIs
- Notes published: 14
- Target replies with technical feedback: >20%
- GitHub stars (when repo is public): target 50
- Collaborator applications: >5
§Campaign 3: #KapnetStudy
Goal: Deep protocol study group. Collaborative learning, not broadcasting.
Audience: Protocol researchers, Bitcoin academics, formal verification people.
Format: Long-form study notes (kind-30078), weekly reading threads, open problems.
Tone: Academic, rigorous, collaborative. We don’t have all the answers.
§Content Calendar (First 4 Weeks)
§Week 1: Foundations
| Day |
Topic |
Reading |
| 1 |
“Bitcoin as a State Machine” |
Cite the Creds paper, summarize key insight |
| 2 |
“TheBase Chronology Axiom” |
Bitcoin’s deepest service is temporal ordering |
| 3 |
“Trust surfaces in distributed systems” |
What each client type trusts |
| 4 |
Open problem #1 |
“Can we formally verify braid convergence?” |
| 5 |
Community response |
Highlight the best reply from the week |
§Week 2: Coordination Layer
| Day |
Topic |
Reading |
| 1 |
“Submissions as atomic civil acts” |
Definition 10.1, why it matters |
| 2 |
“TXXM envelope structure” |
Full envelope walkthrough with examples |
| 3 |
“Knot selection politics” |
Checkpoint politics, who decides |
| 4 |
Open problem #2 |
“Deterministic replay across heterogeneous executors?” |
| 5 |
Community response |
Synthesize the best replies |
§Week 3: Economics of Coordination
| Day |
Topic |
Reading |
| 1 |
“Weakwork pricing theory” |
Why coordination must be scarce |
| 2 |
“Relay markets” |
Who pays for relay infrastructure? |
| 3 |
“Template builder markets” |
Auction theory for block template construction |
| 4 |
Open problem #3 |
“Mechanism design for checkpoint auction fairness?” |
| 5 |
Community response |
Highlight best contributions |
§Week 4: Governance and Evolution
| Day |
Topic |
Reading |
| 1 |
“Governance as constitutional process” |
Kapnet’s governance framework |
| 2 |
“Forkability and divergence” |
Why forks should be visible, not hidden |
| 3 |
“Meta-protocol evolution” |
How Kapnet upgrades itself |
| 4 |
Open problem #4 |
“Formal specification of the full Kapnet state machine?” |
| 5 |
Month retrospective |
Best questions, open threads, next month preview |
§Engagement Tactics
- Every open problem note has a CTA: “Reply with your analysis”
- Best community contributions get their own spotlight note
- Weekly synthesis: summarize the best replies
- Invite academic collaboration: “We need formal verification help”
- Cross-reference related work: Creds papers, Bitcoin research, distributed systems theory
§KPIs
- Study notes published: 20
- Open problems posed: 4
- Quality replies per problem: >3
- Academic/researcher followers: >10
- Paper citations (long-term): reference our open problems
§Cross-Campaign Strategy
§Hashtag Hierarchy
#kapnet → umbrella (all campaigns)
#kapnet-explainers → campaign 1 (education)
#kapnet-builds → campaign 2 (development)
#kapnet-study → campaign 3 (research)
#kapnet-open-problems → cross-campaign (all open problems)
#kapnet-churn → live coordination
#kapnet-kor → namespace announcements
§Voice Guidelines
- No hype, no moon talk, no price mentions
- Technical precision over marketing speak
- Cite sources, link to codebase, show your work
- Admit what you don’t know
- Invite correction and collaboration
§Automation via Publicity Loop
The publicity-loop.cjs manages all three campaigns:
Content queue structure:
{
"queue": [
{
"id": "exp-001",
"campaign": "explainers",
"status": "pending",
"priority": "high",
"content": "...",
"tags": ["kapnet", "kapnet-explainers", "txxm"]
},
{
"id": "bld-001",
"campaign": "builds",
"status": "pending",
"content": "...",
"tags": ["kapnet", "kapnet-builds", "progress"]
},
{
"id": "std-001",
"campaign": "study",
"status": "pending",
"content": "...",
"tags": ["kapnet", "kapnet-study", "foundations"]
}
]
}
§Campaign Rotation
- Explainers: daily (high frequency, low effort)
- Builds: 3x/week (medium frequency, medium effort)
- Study: 2x/week (low frequency, high effort, high value)
§Reply Handling Priority
- Open problem replies (study) — highest priority, need thoughtful response
- Technical feedback (builds) — high priority, acknowledge and act
- Questions (explainers) — medium priority, answer within 24h
- General engagement — standard priority, acknowledge within 48h
§Success Metrics (30-day)
| Metric |
Explainers |
Builds |
Study |
Total |
| Notes published |
14 |
10 |
8 |
32 |
| Followers gained |
50 |
30 |
20 |
100 |
| Reply rate |
30% |
25% |
40% |
32% |
| Quality collaborators |
2 |
5 |
3 |
10 |
| Hashtag impressions |
5000 |
3000 |
2000 |
10000 |
Write a comment