The > Web 4 < Channel Paradigm

How to read this manual

Every statement about the code is taken from the source files and carries a file:line reference. Where the sources do not say something, this page says planned or leaves it out. Each channel and each sub-channel wears one of these labels:

“Opened at boot” is a separate question from “built”. Several sidecars have working code that nothing in NetXecChannel.c opens automatically; those are marked not opened at boot.

All numbers use decimal unless written 0x…. Offsets count from byte 0. “BE” means big-endian, the wire order of every pod record.

Expand all tablesCollapse all tables

Part 1

NetXecChannel: the System, core Channel 0

built NetXecChannel.c (1,608 lines) is the “Web4 microkernel bootstrap and main loop” (NetXecChannel.c:1-15). It is the program that builds as solidpod.exe. NetXecChannel is the System: core Channel 0, one of the sixteen cores. In the current source, core 0 is named “System” in the name tables and there is no separate SystemChannel.c; this file holds its code. As core 0 it creates the sixteen cores (itself included), executes them and routes between them. Its job in four parts:

1. Create the 16 core channels (its own System slot, channel 0, among them), each with a name, a lock, a run-state record and a thread (BootstrapChannels, NetXecChannel.c:466-556).
2. Allocate the crossbar, the shared 8 MiB block that is meant to carry data between cores (NetXecChannel.c:481).
3. Route wake-ups: when one channel has something for another, it sets a bit; the per-core threads (one per core, core 0 included) see it and run the matching handler from a 512-entry dispatch table (NetXecChannel.c:600-756).
4. Run the main loop: poll the window system, tick STDIO and Container, run a watchdog, and shut everything down in a safe order (NetXecChannel.c:1301-1565).

The structures it owns

Sizes are compile-time asserts at channels.h:456-498. Also asserted there: IORequest 64, NetXecThread 64, ThreadParams 32, SPSCRing 32, Field 112, Object 312, MemoryHandle 64, ArbitrationChannel 2,128.

Boot sequence

OpenNetXecChannel (NetXecChannel.c:152-460) opens things in this order. Memory comes first because everyone allocates through it; it is closed last.

The environment variables are read at NetXecChannel.c:289, 370-380, 398-454:

Threads, wake-up flags and the dispatch table

Every core channel has its own thread (CoreChannelThread, NetXecChannel.c:600-695). The thread sleeps on the channel’s HyperLock condition, waking at least every 16 ms (ri_wait_time), or earlier when another channel pokes it.

The poke is one bit. Each channel owns a 64-bit ch_event_flags word. It is cut into 16 nibbles, one per possible sender (defines.h:34-44):

The woken thread reads and clears the word (NetXecChannel.c:662), then for each non-zero nibble n it looks up dispatch_table[IO_PERMUTATION_INDEX(n, self, dir)] and calls the handler (NetXecChannel.c:675-686). The index is (src<<5) | (tgt<<1) | dir with DIR_READ 0 and DIR_WRITE 1 (defines.h:55-62). Sixteen sources × sixteen targets × two directions = 512 entries.

Example flow: a key press reaches System

1. The main loop polls the window system and turns each event into a 64-bit code with EncodeEvent (NetXecChannel.c:797-822). Key down is 0x05010000 | scancode<<8, key up 0x05020000…, mouse button down, button up and motion use 0x0601…, 0x0602… and 0x0603…. Motion packs x and y; button down and up pack the button number and x only (NetXecChannel.c:805-816). Quit is 0xFF010000.
2. HandEventToEventChannel pushes the code on the EventChannel ring (NetXecChannel.c:1175-1216).
3. WakeSystemForSignal sets the READ bit in System’s nibble 4 (NetXecChannel.c:853-863).
4. System’s thread wakes and runs SystemReadFromSignal, which pops 8-byte codes from the ring into the crossbar slot [System][Signal][READ] (NetXecChannel.c:713-744).
5. STDIO, joined to Event and Signal at boot, reads the same events from the Event ring through its own cursor (EventChannelPopSTDIO, STDIOChannel.c:525-540), not from the crossbar slot, for the command line (channel 12).

The sub-channel table

SubChannelAllocatedNames[256] (NetXecChannel.c:82-115) is the master list of names. A flat id is core × 16 + sub, so Memory’s “registry” (core 2, sub 4) is flat id 36. Unused cells hold the string “null”. Names are not code: the right-hand column of each channel card below says what, if anything, stands behind each name. The table below is generated straight from the source by a small C program, so it cannot drift.

Process1 “code” (flat id 188) is present in the source but was missing from the earlier version of this page. It is the Code Share front (docs/CODECHANNEL.md). Container’s header also defines a fifth sub, CC_SUB_CONFIG 4 (ContainerChannel.h:42), that the name table does not list.

The CoreChannelNames table (NetXecChannel.c:66-71) gives the display names; CoreChannelClearNames (:74-79) gives the STDIO prefixes such as SystemChannel (core 0, NetXecChannel) or ContainerChannel.

Main loop, watchdog and shutdown

• Main loop (RunMainLoop, NetXecChannel.c:1301-1350): poll events; tick STDIO; run the watchdog; tick Container every 16 ms. The window is 1280×960, twice HyperView’s 640×480 (NetXecChannel.c:1226).
• Watchdog (NetXecChannel.c:828-847): for each core that is sleeping on its wait condition (RT_WAITCOND) and has waited longer than its wait time plus 10 ms (100 ms if none is set), sets bit 0x1 and signals it, so an idle waiter always wakes.
• Diagnostic menu: Esc opens a menu of keys r (print channel diagnostics), e, x, c, u, s, t; q quits (NetXecChannel.c:1059-1173).
• Shutdown (NetXecChannel.c:1373-1565) follows the HyperView rule: mark every runtime RT_STOPPING then RT_SHUTDOWN, wake all threads, join every thread, wait up to 1 s for each runtime to reach RT_ZOMBIE or RT_STOPPED (then force RT_STOPPED), and only then close Server, Clock, Container, Image, Code, URL, Bridge, STDIO, Font, Media and Event, free the channels and the crossbar, and close Memory last.
• main prints “NetXec: 16 core channels online” once boot completes (NetXecChannel.c:1571-1608).

Part 2

The sixteen core channels

Ids are CHANNEL_SYSTEM 0 to CHANNEL_NIMOSINI 15 (defines.h:73-88). Channel 0, System, is NetXecChannel (part 1); the other fifteen follow it. Each card gives: the id and status, what the channel is for, what reading and writing mean for it, its sub-channels, what it may be joined to, and an example flow. “Links” come from the draft join chart (docs/channel-joins.md); the binary does not enforce that chart yet (see Joins and the policy chart).

Reading a card: “read” and “write” are the two directions of the crossbar pair. A channel reads from the slot [self][peer][READ] and writes to [self][peer][WRITE] (channel_io.c:112-140). Core slot versus core id: bootstrap makes a plain Channel in every channel_base[n] (NetXecChannel.c:507-547). Only Clock replaces its slot (ClockJoinCore, ClockChannel.c:137). Container, URL, Media, Server and STDIO open their own channel object that carries the core id but leave the slot as bootstrap made it (ContainerChannel.c:4, 214, URLChannel.c:883, MediaChannel.c:41, ServerChannel.c:40, STDIOChannel.c:167). (Some source comments call these objects “sidecar”; this manual keeps “sidecar” for channels that are not the core’s own object.)

Part 3

Sidecars, the Blitter Bus (crossbar) and the blit path

Sixteen cores are not enough for a whole system, so Channels has three more ideas that sit beside them. Sidecars are extra channels with ids of 100 and above. The join fabric says who is connected to whom. GPUChannel, the Blitter Bus (crossbar), is meant by design to carry the data between the cores: the Blitter Bus is the crossbar of the Web 4 Channel Paradigm. planned What exists today: NetXecChannel allocates the 8 MiB block Crossbar8MB (512 slots × 16 KiB, NetXecChannel.c:481); only SystemReadFromSignal writes to it; ChannelWriteSlot and ChannelReadSlot have no callers; and GPUChannel is not connected to it yet. Together these are the “bus” of this manual.

Sidecars

A sidecar is a channel that is not one of the sixteen. It has the same parts as a core (buffer, Runtime, RunInfo, lock) and can be joined to cores, but it lives outside the 16×16 matrix. Two kinds exist:

• Own-id sidecars (id ≥ 100): they have an id of their own.
• Homed sidecars: most of the code files (Image, URL helpers, Encryption, Stock, …) are sidecars that claim a core id as their home. They do not add a sixteenth-and-first core.

How a sidecar is joined. ChannelJoin stores a core peer at the index equal to the peer’s id; a sidecar takes the first free of the 16 listener slots, and the listener mask bit is the slot index (channel_io.c:50-64). Sidecars have no crossbar slot: ChannelBindIO leaves their input and output pointers NULL (channel_io.c:136-139). They use their own buffers and wake bits. A wake sent by any id of 16 or more is recorded as coming from Signal, nibble 4 (channel_io.c:158-160). The join policy for sidecars is kept apart from the core chart (docs/channel-joins.md, “policy by sidecar id ≥ 100”).

The crossbar (the Blitter Bus)

One contiguous block, allocated by Memory as shared memory at boot (NetXecChannel.c:481):

• 512 slots = 16 channels × 16 peers × 2 directions, each 16 KiB, 8,388,608 bytes in all (defines.h:50-59).
• Slot address: base + (((ch*16 + peer)*2 + dir) * 16384) (CROSSBAR_SLOT, defines.h:55).
• Each core gets ch_input = [self][peer][READ] and ch_output = [self][peer][WRITE] for a joined core peer (channel_io.c:112-140). Before binding, ch_output = ch_input (NetXecChannel.c:545).
• Data moves in 8-byte words. The writer advances the interrupt cursor; the reader advances the user cursor (channel_io.c:184-230).

Slot header (36 bytes) · channels.h:160-177

Two more facts a reader of the code will notice. ChannelWriteSlot(A,B) fills [A][B][WRITE] while ChannelReadSlot(B,A) reads [B][A][READ], which is a different address. The one handler written so far, SystemReadFromSignal, writes straight into the reader’s own READ slot (NetXecChannel.c:727-744). And a slot is a plain wrapping buffer of 8-byte words with no lock and no “full” check. A set of proposed fixes (per-pair lock, range checks, a status return from the wake call) exists as an unapplied patch.

Joins and the policy chart

• ChannelJoin(a, b) is symmetric. It fails on self or NULL, and for a sidecar peer when the listener slots are all in use (core peers are stored at index = their channel id, so a core-to-core join cannot run out of slots, channel_io.c:50-55), and it rolls back if only one side succeeds (channel_io.c:85-100). ChannelLeave undoes it (:102-110); ChannelIsJoined asks (:172-182).
• Joins made at boot: STDIO ↔ Event and Signal; MainChannel ↔ every live core (MainJoinHub). ClockJoinCore is not a join: it only seats Clock in channel_base[6] (ClockChannel.c:131-138, no ChannelJoin call). NimosiniJoinCore would seat channel_base[15] and join Signal and Memory when the optional stub is enabled; SQLJoinCore joins Server, Process1 and Memory (docs/channel-joins.md).
• The draft join chart below is the policy the designers want: of the 256 ordered core pairs, 144 ALLOW, 96 DENY, 16 SELF. As undirected pairs that is 72 allowed links. Memory is allowed with all; the “dense core” is System, Memory, Thread, Signal, Clock, Container, STDIO; the rest are spokes. It is generated from docs/channel-joins-corexcore.csv.
• Not enforced yet. The document itself says “No hard allow-table in binary yet.” A later step is a join_policy[16][16] table consulted inside ChannelJoin, and showing it in the Container config board. planned
• Counting the name cells instead: 256 cells make 65,536 ordered pairs (about 255²). That figure shows why the design does not mesh everything.

✓ ALLOW   × DENY   · SELF   Row = source channel, column = target channel; the column numbers are channel ids. For the interactive chart see /dev/channels/joins/.

Blit path and Blitz

The display blit (inside one machine)

Container draws every frame in the HyperView order animate → composite → status → present. To avoid redrawing the whole 640×480 view each time, it keeps a list of dirty rectangles: ContDirtyAddRect(x, y, w, h) adds one, ContDirtyClear empties the list, ContDirtyCount returns how many there are, and ContDirtySetFullBlit(on) says “redraw everything” (the count then reads −1) (ContainerChannel.h:727-730, cont_wave.c:734-745). Title bars and the wave code call the full-blit switch whenever something large changes (Titlebar.c:222, cont_wave.c:102).

Blitz (between machines)

Blitz is the binary request/response protocol the headless server speaks on TCP 23232, with BML pages as its content (WEB4-CONTRACT.md, “Blitz protocol”). All Blitz numbers are little-endian — unlike pod records, which are big-endian. A frame is [opcode u8][flags u8][reserved u16][length u32] then the payload. Flags: MORE 1, ERR 2. The tables below follow WEB4-CONTRACT.md and the channels7 copy blitzbrowse/blitz_proto.h; the newer master channels-server/blitz_proto.h adds opcode NOP 0x00, method PUT 0x04, two more header ids and the statuses 201, 401 and 409.

Capability bits: BML 1, CHDD 2, KEEPALIVE 4 (keep-alive is not implemented; one request per connection). Limits: payload 1 MiB, 64 headers, URL 1,024, header value 4,096, 30 s I/O timeout. The page store behind it is TachyonDB (PAGE_PUT / PAGE_GET, local port only). By contract (WEB4-CONTRACT.md, “Storage”), inline Blitz sends are capped at the crossbar slot payload, 16,348 bytes, while larger pages use references; no Blitz code uses crossbar slots today. The data object on the Blitz wire is CHDD. The blob starts with the u32 magic 0x43444844 (CHD_SER_MAGIC_CD, chd_serialize.h:20), written little-endian, so the first four bytes on the wire are 44 48 44 43; then version u32 = 1; then the 80-byte ChannelData body, 88 bytes in all (CHD_CD_WIRE_SIZE, chd_serialize.c:49). An object uses 0x4348444F (CHD_SER_MAGIC_OB). The comments in the source and WEB4-CONTRACT.md call the magic “CHDD”, but 0x43444844 does not spell that in either byte order; the name is a label, not the bytes. BML v2 pages start with ‘B’ ‘M’ ‘L’ 0x02 and are little-endian too.

Part 4

Take your pod with you, bind on demand

A solid pod is a person’s own store: identity, records, files and settings, owned by them and signed by their key. The Web 4 idea is that the pod does not live in a server. The pod is the thing, and a server or a device is somewhere it binds when it needs CPU and a network connection, and leaves when it does not.

What makes a pod portable

• Everything is a record, mostly fixed size, and most carry a version byte. Big-endian, one write per record, 64-bit node ids (records). A record can be copied to a drive, a phone or another server and still means the same thing.
• Records are signed. Ed25519, compiled into the source (TweetNaCl-style), no external library. Each family has its own signing tag so a signature from one family can never pass as another’s: W4MESHv1 (mesh), W4NMv1 (Nimosini), W4PHv1 (phone).
• Identity is a WebID, the standard Solid way. The pod’s node card lives in its Solid pod and is linked from the WebID profile (MESH-SPEC.md).
• Threads are portable too. A PodThread is 256 bytes, signable with the pod key (Thread). Restoring one on the receiving side is a TODO. planned
• Memory has a pod hook. The CLOUD allocator is marked TODO: remote pod-backed storage (MemoryChannel.c:275). planned
• Data can carry a “belongs to the pod” tag. Three ChannelData flags are defined for this: HOME_BOUND (bit 19), TRANSPORT_HOME (20) and POD_AUTHORITATIVE (21) (defines.h:676-712). They are defined only; no behaviour is documented yet.

Bind on demand: the thumb-drive story

The design rule is one sentence: “The thumbdrive is the node. Host supplies CPU and network; drive supplies identity and data.” The drive holds a sealed pod package: WebID, sealed key store, friend (FOAF) list, phone number, a pointer to the DHT root, and a pod marker. It is not an operating-system image.

1. Plug in. The host sees a removable volume. Device’s USB channel is to be the sensor, and today it is still a stub. planned
2. Detect and bind. Container recognises the pod marker and binds: it opens the pod, loads the WebID and phone number, and starts a local front door (an Apache with the BML module, or a Solid endpoint) on a local address. planned
3. Open the door, if allowed. If GalaxyGate is on, the host is on DHCP and the owner allows it, UPnP may open ports 80 and 443. planned
4. Say where you are. The pod registers a signed record in the IP registry: “phone / WebID → current IP:port, with a time-to-live and the public key”. The signature is made with the pod’s Ed25519 key, so a random host cannot steal a number. planned
5. Unplug. The pod unregisters, or its record simply expires. planned

Many pods, one machine. Plug several drives into a USB hub and many pods bind on one compute brick, each keeping its own WebID, phone number and port. planned

Trust rules locked in the design

• Binding or publishing is never silent on an unknown host such as a café PC. It needs local consent, an unlock PIN or key, and/or a host allow-list.
• The first mount on a host needs a confirmed phone number and an unlock.
• A stolen drive must not advertise itself without being unlocked.
• The registry says where, never what. Content stays in the pod or the DHT, so the registry is not a chokepoint for content. Where the registry runs is an open question.
• A call needs mutual enable: A may ring B only if B is on A’s list and B has enabled A. The phone number is the human dial id; the friend graph is FOAF; Solid WebID stays the identity on the wire.
• Not Kubernetes ingress, and not GalaxyCore (a thin Docker / kubectl relay). Content is never published automatically from a sealed pod on an unknown host.

Phase sketch (design)

The flag name SP_FLAG_GALAXY_GATE is only proposed in the design note. It does not exist in defines.h. Pod cloud (a 4 KB resident file system per user) is likewise intent only.

The mesh: WebID, Ed25519 handshake, DHT

Pods find and trust each other without a central switchboard. The flow in mesh/MESH-SPEC.md (draft) is:

1. Discovery. B fetches A’s WebID profile. The profile links to the pod’s node card: node id, public key, mesh endpoint.
2. Challenge. A sends B a random one-time nonce with a short expiry.
3. Proof. B signs with Ed25519; A checks the signature against the key in B’s profile. HELLO and CHALLENGE are unsigned, so nothing is trusted until the PROOF verifies.
4. Admission. A adds B to its peer table with “WebID-verified” and “key-pinned” set; state goes handshake → online. B joins the DHT.
5. Ongoing. Every message is signed. A key rotation must be signed by the old key.

The endpoint is /cgi-bin/mesh.cgi, and the message types are HELLO 1, CHALLENGE 2, PROOF 3, ACCEPT 4, PEERS 5, LEAVE 6. Safety rules: rate limits per address and per WebID, a banned state, never fetch private or loopback addresses when resolving a WebID, constant-time comparisons, no secrets in logs. The records are specified in meshrec.h and tested in C (node-records/test_*); a live mesh endpoint is not shown in the sources. records built · endpoint planned

The DHT (planned)

Pod content is meant to be found by key through a Kademlia-style table with 64-bit routing keys and XOR distance: 64 buckets × 16 entries × 16 bytes = 16,384 bytes of routing table. Message types: PING 0x10 … STORED 0x18, and a HEAD record 0x40 of 174 bytes (dhtrec.h, draft 1; design in dht-fs/DESIGN.md). There is no live DHT. planned

One Nimosini per pod

The AI controller (channel 15) travels with the pod and is exactly one per pod. Every pod announces a presence record, even a dormant one (NM_PRESENCE, AI records), so peers see a single “Nimosini @ node” per pod. A pod advertises the AI capability bit (CAP_AI = 8) only while a valid, granted AI configuration exists; otherwise the bit is stripped before the hello or node card is built (airec.h:125-138). Peers may serve each other language-model requests only when the owner has switched that scope on.

Part 5

Solid pod structure: bits, sizes, capabilities

The pod has three layers, and this part of the manual covers all three. Read them from the inside out:

1. The pod struct (struct SolidPod): a lean index of identity, settings and pointers. Big data stays as files in the encrypted pod archive (SOLID-POD-INTENT.md).
2. Flag words: 64-bit words that switch features on and off, and pack small settings. Two sets exist in the sources: set A (defines.h, canonical) and set B (solid_pod.h, being conformed to A); both are shown.
3. Wire records: big-endian, mostly fixed-size records that travel between pods. These are the pod’s public language.

Expand all tablesCollapse all tables

The SolidPod struct (v6.1)

From solid/solid_pod.h (660 lines): magic SP_POD_MAGIC 0x504F4453, version SP_POD_VERSION 0x00060001, config version SP_CONFIG_VERSION 2. In the pod file the first fields are the header, then identity, profile, bit words, times, quotas, home page and the collections. The offsets below were computed by compiling a small C program against that header with 64-bit gcc; the total is 78,416 bytes. Fields after sp_video_url contain pointers or nested structs whose sizes depend on the 64-bit build.

Note: the header comment says “HEADER – 16 bytes” but its fields (magic, version, size, checksum, config version) occupy 24 bytes. Offsets here follow the fields.

Flag words and bit defines

Set A (canonical) · channels7/defines.h: SP_FLAG_ and SP_FLAG2_

Set A is the canonical flag set. These two tables list the defines.h names and bit numbers exactly as written (checked row by row against defines.h:157-276).

Set B (being conformed to set A) · solid_pod.h v6.1: feature, user, social, storage bits

Set B is the older pod-header naming. It is being conformed to set A (a pending change, not done yet): names that exist in both sets will take the defines.h name and bit number, and the rest stay pod-only. Until that lands, these tables print the header as it stands, so the bit numbers below do not match set A.

Each is a 64-bit word in the struct (sp_flags, sp_user_flags, sp_social_flags, sp_storage_flags). The mask is 1<<bit.

Wire records: the pod’s public language

Every record below is big-endian and written in one write; most are fixed size (a few carry a count byte, and PROFILE and the pod image entry have a length), and all use 64-bit node ids (id 0 is invalid). The mesh, AI, phone and DHT records start with a two-byte header: ver u8 (=1) then type u8; the node, edge, peer, workload, replica, avatar, news and theme records have no such header. Reserved bits must be 0, and readers reject any record with a reserved bit set, so a bit can only be given a meaning by raising the version. The local TacyonMem copy uses native byte order with the same bit layout (NODE-RECORD.md). In a browser, 64-bit ids need BigInt or hex strings (RECORDS-FOR-UI.md).

Node, peer and profile records

NODE flags (byte 8)

Size codes: value = ((8 + mantissa) << exponent) >> 3, where the code byte is exponent<<3 | mantissa (noderec.h, size_enc / size_dec). RAM is in KiB, storage in MiB.

PEER flags (byte 8) and hop/load (byte 9)

Byte 9: high nibble = hops, low nibble = load in sixteenths. A peers body is ver 1 | count N | N × 16. The WebID side table is keyed by FNV-1a 64 of the WebID bytes, with the full WebID compared on lookup (peerrec.h:15).

Mesh messages

Accept status: OK, RATE, BADPROOF, EXPIRED, BANNED, UNKNOWN, BADMSG (0–6). Leave reasons: NORMAL, SHUTDOWN, REKEY, MOVED (0–3). The node card is published in the pod and linked from the WebID profile; a key rotation is a new card also signed by the old key (MESH-SPEC.md; meshrec.h:1-27). Signing tag for every mesh message: W4MESHv1.

Capability bits

The 16-bit caps field of HELLO (offset 30) and of the node card (offset 56) (meshrec.h:27).

meshrec.h:46, 85 (hello_get and card_get reject bits 4–15); airec.h:125-138 (ai_hello_caps).

AI records (Nimosini) staged

Defined in airec.h with passing C tests; staged, not live. Signing tag W4NMv1 (6 bytes), different from the mesh tag at byte 2, so one family’s signature can never pass as the other’s. Every Nimosini (NM_*) message carries to inside the signed bytes, and a reader rejects to ≠ its own node id, so a captured message cannot be replayed to another pod.

Presence state: 0 dormant, 1 starting, 2 running, 3 degraded, 4 paused, 5 breaker, 6 leaving (sent once on a clean shutdown; the receiver treats the sender as gone at once instead of waiting for the record to go stale); 7 is rejected (airec.h:75-76, airec.h:200). Backend: 0 none, 1 CPU, 2 GPU. Receivers keep a seen-ring of 1,024 entries × 24 bytes (up to 128 per sender, 300 s windows) so a repeated request is refused; the deadline window is at most 300 s; a grant time may be at most 300 s in the future (AI_GRANT_SKEW_S, airec.h:36). A receiver verifies the signature before changing any state and admits only known peers (airec.h:236-250). A server may first run the read-only nm_lm_precheck_sender to drop a sender that already holds its 128 live entries without paying for the Ed25519 verify (airec.h:309-315).

AICFG grant mask (grant_mask, 15 bits, GS_ALL = 0x7FFF)

Bits and names: airec.h:65-69 (bit 15 must be 0, comment at line 65). Pre-ticked default NM_GRANT_DEFAULT = 0x0205: airec.h:70-71. The “irreversible” column follows the spec’s list of mail, publish, dial, delete and peer admit.

AICFG policy byte (byte 24)

LM order values: 0 pod, 1 peer, 2 pod then peer, 3 peer then pod. Both b7 and b6 default to 0. Bit 6 is named “frames off pod” and means that when it is set, camera frames are allowed to leave the pod; unset, they never do (airec.h:72-73; the later draft renames it FRAMES_MAY_LEAVE).

Resource limits: RAM 256–8,192 MiB (default 1,024); disk 2,048–65,536 MiB (default 8,192); RAM at most 50 % of physical, disk at most 25 % of free; a pod language model needs at least 2,048 MiB (airec.h:38-63).

Phone, pod files, ChannelData and the roadmap

Phone records staged

phonerec.h (v1) defines a video-phone built on the pod. Staged, not live. A pod has one pod number: 12 decimal digits, the first 1–9, the last a Luhn check digit, stored in 5 bytes and shown as 4444-4444-4444. Phone messages are signed with the pod server’s key; devices never sign. Signing tag W4PHv1. As with the AI records, to is inside the signed bytes and a reader rejects any message whose to is not the local node. A message older than 300 s (PH_FRESH_S) is stale; a seen-cache holds 128 call ids for 600 s.

Type bytes are shared across families: mesh 1–6; Nimosini 8, 9, 16–18; DHT 0x10–0x18 and 0x40; phone 32–63 (32–39 call, 40–45 conference, 46 roster, 47 spare signed, 48–50 stored rows, 51–63 spare).

How a call works. A call rings every ringable device the callee has. The first to answer wins; the others get a CANCEL with reason 9, “answered elsewhere”. The call state machine is DIALING, RINGING, CONNECTED, ENDED. The page never signs anything; the server does. A caller who is blocked is shown “no answer” (RECORDS-FOR-UI.md). The sound and picture travel through Media, encrypted with DTLS-SRTP; Nimosini may decline within its grant but never touches call media.

Other pod records

ChannelData flags (CD_FLAG_*)

ChannelData is the 80-byte typed header that wraps any value that moves between channels. It carries a 64-bit flag word (defines.h:676-712). Types: 32 values = 8 base types (byte, short, char, int, long, float, double, object) × 4 shapes (single, array, 2-D, 3-D) (defines.h:410-452). Content classes (:718-727): DATA 0, CONTROL 1, SIGNAL 2, STREAM_FRAG 3, FRAG_END 4, HEARTBEAT 5, ERROR 6, RETRY 7, OBJECT 8, REGISTRY 9. The flags marked pod are the hooks for “your data lives in your pod”.

Pod flags: HOME_BOUND 19, TRANSPORT_HOME 20, POD_AUTHORITATIVE 21. Also relevant to ownership: ENCRYPTED 5, SIGNED 10, FEDERATED 22, DHT_PINNED 23, SENSITIVE 28, AI_LABELED 26. Defined only; the sources do not describe their run-time behaviour.

Future plans

Everything on this list is planned. Each item says where the source marks it as not done.

Part 6

Privacy and ownership: your data, your choice

Web 4 is solid. The pod is yours, the keys are yours, and every switch that matters is a switch you flip. This is how the design above turns that sentence into rules. Each rule points at the place in the sources where it is written.

Only a few of these are running code today. The record formats, the policy bits and the grant checks are built and tested in C; the Nimosini channel and the portable-pod bind are designs. Privacy statements about Nimosini describe the design, not a deployed service.

Questions about your own pod: contact · privacy policy.

Part 7

Glossary

Web 4

The project’s name for a web built on solid pods: the owner holds the data and the keys, and servers are places a pod visits.

Solid pod

A person’s own data store: identity, profile, records, files and settings. Described in part 5. “Solid” also names the open standard for WebIDs and pods that the wire format follows.

WebID

A web address that names a person or pod and links to a profile document with its public key and node card.

FOAF

“Friend of a friend”: the friend graph. A call needs both sides to have enabled each other.

Channel

A small program with one job, a numbered place in the table, its own lock and run-state record.

Core channel

One of the sixteen channels with ids 0–15: System (NetXecChannel, Channel 0), Device, Memory, Thread, Signal, Media, Clock, Container, URL, Server, Process0, Process1, STDIO, Compiler, Debug, Nimosini.

Sub-channel

One of sixteen named cells under a core. The flat id is core × 16 + sub, 0–255.

Sidecar

A channel that is not itself one of the sixteen cores: it has an id of 100 or more, or is a code file homed on a core’s id (Image, Font, Video, CLI, BQL, GPU). A core’s own channel object (Container, URL, Media, Server, STDIO) is not called a sidecar here. Has no crossbar slot.

NetXecChannel

The System, core Channel 0, one of the sixteen cores. As the conductor it creates the cores (itself included), owns the crossbar (the Blitter Bus) and dispatch table, and runs the main loop.

Crossbar

See GPUChannel, the Blitter Bus (crossbar). A block of 512 slots (16 KiB each, 8 MiB in all), addressed [channel][peer][direction], that is meant by design to carry data between cores. Today NetXecChannel allocates it and only System←Signal writes to it.

Slot

One 16 KiB cell of the crossbar: a 36-byte header and 16,348 bytes of data.

Dispatch table

512 handlers indexed by source, target and direction.

Join

A symmetric link between two channels, held in each one’s listener table (16 slots).

HyperLock

A mutex plus condition variable, one per channel, that its thread sleeps on.

Event ring

The 64 KiB single-producer ring of 8-byte OS-event codes in the EventChannel.

Cont

The sources’ shorthand for the Container layer and its API and coding style (“Cont style”: no typedef, no enum, no union).

HyperView

The Java UI framework whose structure Container mirrors (gobs, gadgets, panes). The view is 640×480.

Blit

Copying finished pixels to the screen. Container tracks dirty rectangles or forces a full blit.

Blitz

The binary protocol on TCP 23232 that carries BML pages (little-endian).

BML

The binary page format. A v2 stream begins with the bytes B, M, L, 0x02.

BQL

The query side of page storage. BQLChannel holds a query string and the connection settings for TachyonDB.

TachyonDB / TacyonMem

The page store (PAGE_GET / PAGE_PUT, local port) and its in-memory copy of pod records (native byte order).

Code Share / CodeVault / PCL

Code hosting. CodeChannel is its front; PCL is its control language of one-byte opcodes.

ChannelData / CHDD / .chd

The 80-byte typed header for moving data; its 88-byte wire form starts with the u32 0x43444844 (bytes 44 48 44 43 on the wire; see Blit path and Blitz); saved objects are NAME.chd.

Node id

A 64-bit number naming a pod or device on the mesh. 0 is invalid.

Node card

The 122-byte self-signed record that tells peers a node’s id, key, port and capabilities.

Ed25519

The signature scheme used for every signed record. The code is compiled in (TweetNaCl-style); no library is needed.

Signing tag

A fixed prefix signed with the message so one record family cannot pass as another: W4MESHv1, W4NMv1, W4PHv1.

DHT

Distributed hash table; a Kademlia-style table of 64-bit keys for finding pod content. Planned.

GalaxyGate

The planned reachability mode: optional UPnP port mapping on a DHCP host and a signed IP-registry entry. Not Kubernetes ingress.

GalaxyCore

A thin Docker / kubectl relay. Different from GalaxyGate.

IP registry

A planned signed “number or WebID → where to reach it” directory with a time-to-live.

Pod number

The 12-digit phone number of a pod, last digit a Luhn check.

Nimosini

The planned AI controller, channel 15; one per pod.

Net

One of eight independent neural-network slots (neural0–7) in the Nimosini design.

Grant, scope, tier, taint

The owner’s one-time permission (grant) is split into scopes; actions have tiers 0–3; input the owner did not provide is tainted and capped at tier 1.

AICFG

The 26-byte local record that holds the owner’s grant, resource limits and policy byte.

Nexus

The eight-layer resource-sharing pyramid held in the pod struct. Not built.

Big-endian

Most-significant byte first. The byte order of every pod record. Blitz and BML are little-endian.

Part 8

Index A–Z

• AICFG
• AI records
• CAP_AI, CAP_ALL, capability bits
• ChannelData, CD_FLAG
• Signal channel (4)
• Clock (6)
• Compression, encryption (10)
• Container (7)
• Crossbar, Blitter Bus (GPUChannel)
• Device (1)
• Dispatch table
• DHT, Ed25519 handshake
• Blit, Blitz
• Future plans
• GalaxyGate, thumb drive
• Consent, privacy defaults
• Join chart, ChannelJoin
• Memory (2)
• Mesh, WebID
• Nimosini (15)
• NetXecChannel (System, core 0)
• Node record, peer record
• Phone records, pod number
• Portable pod, bind on demand
• Process0 (10)
• Process1 (11), Code Share
• Server (9)
• Sidecars
• SolidPod struct
• SP_FLAG (set A), SP_FEATURE (set B) bits
• STDIO (12)
• Sub-channel table
• System (0), NetXecChannel
• Thread (3), PodThread
• URL (8)
• Compiler (13)
• Debug (14)
• Media (5)

Known gaps and source notes

Where the sources disagree or are silent, this manual says so rather than guessing:

• Two flag sets. Set A, SP_FLAG_* / SP_FLAG2_* (channels7 defines.h), is canonical. Set B, SP_FEATURE_* (pod header solid_pod.h v6.1), describes the same pod differently and is being conformed to A (pending, not done yet); both are printed in part 5.
• The join chart is a draft. It is not enforced in the binary. It denies Nimosini↔Server, Nimosini↔Clock and Nimosini↔Debug (as well as Device, Media, URL and Compiler), while the Nimosini design relies on Server to hold the key and sign, on Clock for the tick and on Debug for counters; the chart and the design need reconciling.
• Home core vs name table. GPS and GPRS are homed on Device in code but named under Process1; BML is homed on Process0 but named under Server and Process1; Java is homed on Process0 but named under Compiler.
• Nimosini sub-channel names. The master table says grok / bert / chatgpt / neuralnet at 248–251. The staged prototype uses other names for 248–250 (aichannel, speech, translate). No code in the running system uses either.
• Record sizes. An older Nimosini draft lists AICFG 32, NM_PRESENCE 81, NM_AICFG 86 and NM_LM 1,088 bytes. The record headers, which this page follows, say 26, 89, 94 and 1,096.
• Handshake signing. The mesh note mentions libsodium and signing the nonce; the record header and the node-record note specify the compiled-in Ed25519 and the W4MESHv1 tag over every preceding byte. This page follows the record header.
• Type bytes. DHT messages 0x10–0x12 reuse the numbers of the Nimosini mesh types 16–18; the signing tag and the channel keep them apart.
• Pre-ticked AI scopes. The record header now holds the safe default 0x0205 (local tune, basic call, pod language model); an earlier draft's 0x1E87 is gone. See AI records.
• Blitter Bus. GPUChannel, the Blitter Bus (crossbar), is the crossbar of the Web 4 Channel Paradigm. By design it carries data between the cores; today the crossbar is the block NetXecChannel allocates, only System←Signal writes to it, and channels7/GPUChannel.c (153 lines) is a query-name stub that is not connected to it. The 1,838-line channels7-read/GPUChannel.c is a different file and does not use the crossbar. The draft join chart gives Device (where GPUChannel is homed) only four partners (System, Memory, Thread, Signal), and the 512-entry dispatch table has one real handler (the other 511 are no-op defaults, NetXecChannel.c:746-755); both need work before the Blitter Bus carries data between all cores. See The crossbar.
• Not documented in the sources: run-time behaviour of the three pod ChannelData flags; the Debug channel; handlers for 511 of 512 dispatch cells; a live mesh endpoint; a live DHT.

Source files this manual draws on

channels7: NetXecChannel.c, defines.h, channels.h, channel_io.c, ChannelConfig.h, MainChannel.h, ServerChannel.h, ThreadChannel.c, MemoryChannel.c, EventChannel.c, SignalChannel.h, ClockChannel.c, ContainerChannel.h, URLChannel.c, EncryptionChannel.h, CompressionChannel.c, SolidChannel.h, StockChannel.h, STDIOChannel.h, CLIChannel.c, GALAXYGATE.md, docs/channel-joins.md, docs/channel-joins-corexcore.csv, docs/CODECHANNEL.md, URLChannel-CURL.md, SOLID-AUTH-HEADERS.md. Pod: channels6-review/solid/solid_pod.h, pod_sticky.h (not in channels6-review/solid; it is in publish-vaultmagic/src), channel_data.h, handoff-solid-pod/SOLID-POD-INTENT.md. Records: node-records/*.h and NODE-RECORD.md, mesh/MESH-SPEC.md, WEB4-CONTRACT.md. Design: nimosini-channel/NIMOSINI-CHANNEL-SPEC.md.