Kapactivity — Protocolization of Web for Humans
``` ┌─────────────────────────────────────────────────────────────┐ │ HUMAN OPERATOR GELI │
- Kapactivity — Protocolization of Web for Humans
- The Three Human Roles
- The Web as Kapnet Membrane
- Kapactive Website Architecture
- TXXM as Web Protocol
- Visitor Authentication Levels
- Kapactive Web Gateway
- The Key Insight: TXXM Replaces HTTP Semantics
- Kapactivity Protocol Stack
- What Makes It “Kapactive”
- Implementation: kapnet-web Crate
- The Operator’s Web Experience
- The Visitor’s Web Experience
- Kapactivity vs. Traditional Web
- The Protocolization Thesis
Kapactivity — Protocolization of Web for Humans
The Three Human Roles
┌─────────────────────────────────────────────────────────────┐
│ HUMAN OPERATOR (GELI) │
│ │
│ Role: Sovereign. Owns the keys. Authorizes everything. │
│ Interface: Terminal TUI on Qubes. operator.json commands. │
│ Trust model: Root of trust. AUTH_7. │
│ Kapactivity: Direct TXXM submission to local kapnetd. │
│ Reads braid state. Signs governance decisions. │
│ Manages sessions via Sheet TXXM rows. │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ HUMAN AGENT (Hermes User) │
│ │
│ Role: Delegated operator. Runs a Hermes instance. │
│ Interface: Terminal TUI OR web dashboard. │
│ Trust model: AUTH_4 (agent operations). │
│ Kapactivity: Submits TXXMs via local agent. │
│ Reads shared sheets. Participates in braid. │
│ Can spawn sub-agents (AUTH_6). │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ HUMAN VISITOR (Public) │
│ │
│ Role: Anonymous or identified web user. │
│ Interface: Web browser. Nostr identity optional. │
│ Trust model: AUTH_1 (minimal) to AUTH_3 (identified). │
│ Kapactivity: Reads public TXXMs from relay. │
│ Submits TXXMs via web form → relay. │
│ Pays via Lightning for access/content. │
│ No local kapnetd needed. │
└─────────────────────────────────────────────────────────────┘
The Web as Kapnet Membrane
The web is currently a separate universe from Kapnet. The goal is to make the web a Kapnet membrane — a surface where TXXMs are the native protocol, not HTTP.
CURRENT WEB:
Browser → HTTP → Server → Database → HTML → Browser
(request/response, stateful server, centralized)
KAPACTIVE WEB:
Browser → Nostr relay → TXXM envelope → kapnetd → Braid
(publish/subscribe, stateless, decentralized)
OR:
Browser → Web gateway → TXXM envelope → Nostr relay
(for visitors without local kapnetd)
Kapactive Website Architecture
┌─────────────────────────────────────────────────────────────┐
│ KAPACTIVE WEBSITE │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ PUBLIC │ │ GATED │ │ OPERATOR │ │
│ │ SURFACE │ │ SURFACE │ │ SURFACE │ │
│ │ │ │ │ │ │ │
│ │ Read TXXMs │ │ npub auth │ │ AUTH_7 │ │
│ │ from relay │ │ required │ │ only │ │
│ │ │ │ │ │ │ │
│ │ No login │ │ Lightning │ │ Full TXXM │ │
│ │ needed │ │ payment │ │ submission │ │
│ │ │ │ for access │ │ │ │
│ │ Content: │ │ │ │ Content: │ │
│ │ - Public │ │ Content: │ │ - Braid │ │
│ │ TXXMs │ │ - Private │ │ state │ │
│ │ - Block │ │ docs │ │ - Session │ │
│ │ explorer │ │ - Collab │ │ mgmt │ │ - Governance│
│ │ - Pool │ │ pads │ │ - Treasury │ │
│ │ status │ │ - Messages │ │ - Agent │ │
│ │ - Research │ │ - Mining │ │ control │ │
│ │ library │ │ stats │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ALL SURFACES: │
│ ├── Read from Nostr relay (public TXXMs) │
│ ├── Write via TXXM envelopes (authenticated) │
│ ├── State stored on SSD (encrypted) │
│ └── State proven in braid (eternal) │
└─────────────────────────────────────────────────────────────┘
TXXM as Web Protocol
Every web interaction is a TXXM:
WEB ACTION → TXXM TYPE → KOR NAMESPACE
─────────────────────────────────────────────────────────
View page → Submission(read) → public.kor
Submit form → Submission(write) → service.kor
Pay for access → Submission(pay) → treasury.kor
Upload document → BlobTxxm → collab.kor
Sign document → Review → collab.kor
Vote on proposal → Governance → gov.kor
Claim hedblitz → Submission(claim) → hedblitz.kor
Mine share → Submission(share) → pool.kor
Block found → Submission(block) → pool.kor
Session create → Session(new) → session.kor
Session revoke → Session(revoke) → session.kor
Key rotation → Session(rotate) → session.kor
Visitor Authentication Levels
AUTH_0: Anonymous
├── Can read public TXXMs
├── Can view public pages
└── Cannot submit anything
AUTH_1: Nostr Identified (npub only)
├── Can read public TXXMs
├── Can submit public TXXMs (signed by npub)
├── Can comment/react
└── Cannot access gated content
AUTH_2: Nostr Verified (npub + nip05 or known)
├── All of AUTH_1
├── Can access free gated content
├── Can participate in public governance
└── Cannot access paid content
AUTH_3: Lightning Paid (LN payment verified)
├── All of AUTH_2
├── Can access paid gated content
├── Can download files from store
├── Can use Cryptpad collaboration
└── Cannot manage sessions or agents
AUTH_4: Agent Delegated (operator-authorized)
├── All of AUTH_3
├── Can manage own sessions
├── Can spawn sub-agents
├── Can submit governance proposals
└── Cannot manage other agents
AUTH_6: Code Execution (operator-authorized)
├── All of AUTH_4
├── Can execute code on infrastructure
├── Can manage KSP contracts
└── Cannot modify operator keys
AUTH_7: Operator (GELI only)
├── Full control
├── Can authorize/revoke any auth level
├── Can prune data (with governance)
└── Root of trust
Kapactive Web Gateway
For visitors who don’t run kapnetd, a web gateway translates HTTP to TXXMs:
VISITOR BROWSER
│
├── GET /page → Gateway reads relay for TXXMs matching page_id
│ Returns rendered HTML from TXXM payloads
│
├── POST /submit → Gateway creates TXXM envelope
│ (with npub sign) Signs with visitor's npub (via browser extension
│ or server-side if visitor trusts gateway)
│ Publishes to relay
│
├── POST /pay → Gateway creates Lightning invoice
│ (LN payment) On payment, creates access-grant TXXM
│ Visitor gets session cookie / npub auth
│
└── WS /stream → Gateway subscribes to relay
(real-time) Pushes new TXXMs to browser via WebSocket
No polling. Real-time TXXM stream.
The Key Insight: TXXM Replaces HTTP Semantics
HTTP SEMANTIC → TXXM EQUIVALENT
────────────────────────────────────
GET → Submission { action: "read", target: <id> }
POST → Submission { action: "create", payload: <data> }
PUT → Submission { action: "update", target: <id> }
DELETE → Submission { action: "delete", target: <id> }
PATCH → Submission { action: "patch", target: <id> }
WebSocket → Nostr subscription (real-time TXXM stream)
Cookie/Session → Session TXXM (on-braid, cryptographic)
API key → npub + signature
OAuth → npub auth + challenge/response
Payment → Lightning invoice + payment proof TXXM
Kapactivity Protocol Stack
LAYER 5: APPLICATION
├── Kapactive websites (HTML rendered from TXXMs)
├── Kapactive APIs (TXXM envelopes as API responses)
├── Kapactive feeds (Nostr relay subscriptions)
└── Kapactive search (TXXM content indexing)
LAYER 4: AUTHENTICATION
├── npub identity (NIP-05, npub, or anonymous)
├── Lightning payment (LNURL, invoice)
├── Session management (Session TXXM)
└── Auth level enforcement (KOR scope)
LAYER 3: MESSAGE
├── TXXM envelope (kind-30078 on Nostr)
├── MessageEnvelope (typed, sequenced, hash-chained)
├── Sheet TXXM (row-based shared state)
└── Blob TXXM (large payloads, chunked)
LAYER 2: TRANSPORT
├── Nostr relay (WebSocket, publish/subscribe)
├── Direct P2P (future: iroh, libp2p)
└── On-chain (OP_RETURN for permanent anchors)
LAYER 1: IDENTITY
├── Nostr keypair (npub/nsec)
├── Bitcoin address (for payments)
├── KOR namespace (for authorization scope)
└── KSP contract (for service access)
What Makes It “Kapactive”
A website is “kapactive” when:
- Content is TXXMs — Every page, post, comment, file is a TXXM envelope
- State is braid — The site’s state is the braid, not a database
- Auth is npub — Login = Nostr identity. No passwords.
- Payment is Lightning — Pay-per-access, subscription, or PWYW via LN
- Real-time is native — WebSocket subscription to relay, no polling
- History is eternal — All content proven in braid, even if SSD pruned
- Access is governed — KOR scope + KSP contracts define who can do what
- Operators are sovereign — AUTH_7 controls everything, always
Implementation: kapnet-web Crate
The Kapnet workspace already has kapnet-web. It needs:
kapnet-web extensions:
├── TXXM renderer (TXXM envelope → HTML)
├── npub auth middleware (challenge/response)
├── LN payment gating (invoice → access grant)
├── Relay client (subscribe/publish TXXMs)
├── Session manager (Session TXXM lifecycle)
├── Sheet viewer (render sheet TXXM as table/form)
├── Blob viewer (render blob TXXM as file/download)
└── Real-time push (WebSocket → relay subscription)
The Operator’s Web Experience
OPERATOR (GELI) visits kapactive website:
1. Browser connects to site
2. Site challenges: sign this nonce with your npub
3. Browser extension (or local Hermes agent) signs
4. Site verifies: AUTH_7 confirmed
5. Full operator dashboard loads:
├── Braid state (knot height, TXXM count, state root)
├── Agent status (all souls, heartbeats, errors)
├── Session management (create/revoke/rotate)
├── Treasury (UTXOs, sweep controls)
├── Governance (proposals, votes, decisions)
├── Messaging (send TXXM to any agent/visitor)
└── Content management (publish/edit/delete TXXMs)
7. All actions submit TXXMs to relay
8. All state changes reflected in braid
The Visitor’s Web Experience
VISITOR (anonymous) visits kapactive website:
1. Browser connects to site
2. Public content loads (TXXMs from relay, rendered as HTML)
3. No login needed for public pages
4. To comment: site offers npub auth or stay anonymous (AUTH_0)
5. To access paid content: Lightning invoice displayed
6. Visitor pays via Lightning wallet
7. Site creates access-grant TXXM (signed by site npub)
8. Visitor's npub now has AUTH_3 for this site
9. Gated content loads
10. Session expires per KSP contract terms
Kapactivity vs. Traditional Web
TRADITIONAL WEB KAPACTIVE WEB
─────────────── ───────────────
Data store Database (centralized) Braid (decentralized)
Identity Email/password npub (cryptographic)
Payment Credit card Lightning (Bitcoin)
Auth OAuth/Session cookies Session TXXM (on-braid)
Real-time Polling/SSE Nostr subscription (push)
Content HTML from server TXXM envelopes from relay
History Server logs Braid (eternal evidence)
Access control Server-side rules KOR scope + KSP contracts
Sovereignty Server owner Operator (AUTH_7)
Censorship Server can delete Braid cannot be deleted
Availability Server uptime Relay network (distributed)
The Protocolization Thesis
The web was designed for documents. Kapnet is designed for coordination. When you protocolize the web as Kapnet:
- Documents become TXXMs — every piece of content is a signed, timestamped, hash-linked envelope
- Interactions become TXXMs — every click, form submission, payment, vote is a TXXM
- Identity becomes cryptographic — no more passwords, no more OAuth, just npub + signature
- Payments become native — Lightning is the payment layer, not an afterthought
- History becomes eternal — the braid proves everything that ever happened
- Sovereignty becomes absolute — the operator owns the keys, the KOR, the scope
The web doesn’t disappear. It becomes a rendering layer on top of the Kapnet coordination substrate. HTTP is replaced by TXXM. HTML is rendered from TXXM payloads. Sessions are TXXM lifecycle events. Payments are Lightning + proof TXXMs.
The web becomes kapactive.
Write a comment