Cryptofabrics
A cryptofabric is the machinery that moves and stores Cursors material without pretending the machinery itself is identity or authority.
The cockpit should make a fabric feel like a board you can probe:
producer / mailbox / resolver
│
▼
semantic envelope
│
┌─────┴─────┐
│ fabric bus │
└─────┬─────┘
│
carrier / store
│
▼
consumer / mailbox / body
What you are looking at
When you select a fabric node, you are looking at an ensemble of routing, admission, deduplication, persistence, rendezvous, and carrier choices.
When you select a wire, you are looking at one relationship inside that ensemble.
When you zoom into a wire, the little packets are message specimens: structured examples of the semantic material that can ride that relationship. They are not meant to imply that every modeled field is presently observed on the network.
A wire is richer than bytes
The lower carrier may only know about frames and bytes, but Cursors needs the higher semantic envelope to remain inspectable.
A mailbox wire can carry something shaped like:
envelope/v1
id
subject
causal parents[]
author evidence
capability refs[]
payload ref/body
expiry
receipt policy
A pointer-resolution wire can carry:
resolve/v1
target
requested view
resolver constraints
trust refs[]
capability refs[]
curve hint
locality preference
expiry
An authority-bearing wire is visibly different:
grant/v1
issuer fingerprint
subject
resource
rights[]
budgets
validity
nonce
signature
Only the last family may carry explicit authority after verification. The TCP, WebRTC, torrent, HTTP, relay, or local-memory carrier underneath it still grants nothing by itself.
Carriers are replaceable machinery
A browser body can use:
- WebRTC / WebTorrent;
- HTTPS webseeds;
- BroadcastChannel for same-origin local exchange;
- browser persistence.
Other bodies may use TCP, µTP, UDP DHT, IPC, removable media, radio, or delay-tolerant stores.
The message model should not have to mutate every time the carrier changes.
What each visible layer proves
| Visible thing | Useful evidence | Does not automatically prove |
|---|---|---|
| semantic message | declared fields, signatures/refs when present | successful delivery or execution |
| wire | relationship and observation state | identity or authority |
| carrier frame | bytes moved on a transport | message authorship |
| piece hash | immutable-piece integrity | decryption right |
| delivery receipt | the stated delivery fact | external effect completion |
| capability/grant | explicit rights after verification | reachability |
Natural inspection rule
The user should be able to move in either direction:
message → wire → fabric → carrier
or:
carrier → wire → message family → authority / identity evidence
without the UI silently changing what kind of fact is being inspected.
That is why transport, message, identity, authority, execution, and persistence stay visually distinct even when they overlap on the same physical path.
Programming a fabric
Cryptofabric programs describe meaningful work before execution:
exchange(target)
mailbox(address)
exec(program)
split(...branches)
sequence(...steps)
A program can therefore be rendered as machinery before a body runs it. Future operators such as resolve, join, race, retry, store, checkpoint, delegate, and observe should preserve the same inspectability.
Continue with Mailboxes and Traffic, Cryptopointers, and Cursor Apps and Contemporary Runtimes.