ChatTheatre Kernellib Carries Object Registry and Granular Resource Tracking Absent From Cloud-Server Kernel

Claim

ChatTheatre/kernellib at HEAD d86b427 (2020-09-24) implements an object registry daemon (objregd) and tracks callouts, events, editors, tick usage, and create-time resources as named resource categories. dworkin/cloud-server's src/kernel/ at HEAD 9994bc3 (2026-03-14) implements neither: there is no objregd daemon, and the resource map carries only objects, stack, ticks, and fileblocks. Both trees share daemon names (accessd, rsrcd, userd, driver) and the binary KERNEL() / SYSTEM() privilege macros, but they diverge sharply on multi-agent state coordination and resource granularity.

Grounds

This is a Retrospective Observation. The grounds are direct reading of the source trees at fixed worktree HEADs; the limits are that the snapshots cannot reconstruct the development history that produced the divergence -- in particular, whether kernellib added the missing features after forking from dworkin/kernellib (in 2016, per kernellib's README) or whether cloud-server stripped features the shared ancestor carried. Both directions of historical reading are consistent with the snapshots; the snapshots themselves cannot adjudicate between them.

What the worktrees show, file by file:

c resources = ([ "callouts" : ({ -1, 0, 0 }), "objects" : ({ -1, 0, 0 }), "events" : ({ -1, 0, 0 }), "stack" : ({ -1, 0, 0 }), "ticks" : ({ -1, 10, 3600 }), "tick usage" : ({ -1, 10, 3600 }), "filequota" : ({ -1, 0, 0 }), "editors" : ({ -1, 0, 0 }), "create stack" : ({ -1, 0, 0 }), "create ticks" : ({ -1, 0, 0 }), ]);

c resources = ([ "objects" : ({ -1, 0, 0 }), "stack" : ({ -1, 0, 0 }), "ticks" : ({ -1, 10, 3600 }), "fileblocks" : ({ -1, 0, 0 }), ]);

Protocol Kernellib coverage Default port (kernel.dgd) Source
Telnet Full -- connection lifecycle, login flow, manager registration telnet_port = 6047 src/kernel/obj/telnet.c, userd::set_telnet_manager(port, obj)
Binary Full -- connection lifecycle plus admin-backdoor login on first binary port binary_port = 6048 src/kernel/obj/binary.c, userd::set_binary_manager(port, obj)
Datagram Full at the connection-object level; not bound in the default config (applications register a port and manager at runtime) (none) src/kernel/obj/datagram.c, userd::set_datagram_manager(port, obj)
HTTP / HTTPS Not in kernellib. Cloud-server carries src/usr/HTTP/ at its application layer; kernellib's kernel surface has no equivalent -- --
WebSocket Not in kernellib. No native handler at any layer -- --
SSH Not in kernellib. No native handler at any layer -- --
TLS / SSL (transport-layer security) Not in kernellib. Note the name collision: kernellib's lib/api/tls.c and include/kernel/tls.h are Task-Local Storage, exposing set_tlvar() / get_tlvar() for transactional context; they are not transport-layer security and do not provide cipher / certificate / handshake handling -- src/kernel/lib/api/tls.c (TLS = Task-Local Storage, not Transport Layer Security)

Bytestream framing on the wire is delegated to the underlying DGD driver; kernellib's role is the LPC-side connection lifecycle (open, close, receive_message, send_message, redirect). Higher-protocol layers (HTTP request parsing, WebSocket frame handling, TLS termination) are application concerns kernellib does not address.

c if (hash_string("crypt", str, password) != password) { ... } password = hash_string("crypt", str);

hash_string() is a DGD driver kfun (not a kernellib primitive). dworkin/dgd's driver at HEAD aafc3784 provides the following crypto-related kfuns in the standard set, each backed by a name-dispatched table that extensions can extend via KFun::add():

Kfun Built-in algorithms Source
hash_string(algorithm, ...) "crypt" (Unix password hash with random or fixed salt), "MD5", "SHA1", "CRC16", "CRC32" src/kfun/extra.cpp (FUNCDEF at line 1005, dispatcher at line 1429)
crypt(string) Convenience wrapper around hash_string("crypt", ...) src/kfun/extra.cpp:1450
encrypt(algorithm, ...) "DES key" (key preparation), "DES" (block encryption) src/kfun/extra.cpp:28, dispatcher at line 67
decrypt(algorithm, ...) "DES" (block decryption) src/kfun/extra.cpp:89, dispatcher at line 134

The encrypt / decrypt / hash_string dispatchers consult name-prefixed extension tables (kfenc, kfdec, kfhsh in src/kfun/table.cpp); extension modules can register additional algorithms by adding kfuns whose names start with "encrypt ", "decrypt ", or "hash " -- the prefix is stripped at registration. Modern primitives -- SHA-256 / SHA-384 / SHA-512, AES, RSA, Ed25519, X25519, HMAC, ChaCha20 / Poly1305 -- are not in the standard kfun set; applications needing them either link a DGD extension that registers them or implement them in LPC. There is no built-in support for X.509 certificate parsing, key-derivation functions (PBKDF2 / Argon2), or constant-time comparison helpers.

For downstream agent-identity work, this means: agent identity that needs cryptographic verification (signed capability tokens, content-addressed identifiers, sealed audit logs) requires either a DGD extension layer registering modern primitives, an LPC-level implementation of the chosen scheme, or an architectural choice to delegate crypto to an external service.

The Retrospective limits: structural comparison without access to the development branches that produced each tree. A full archaeology would clone dworkin/kernellib, walk its history alongside dworkin/cloud-server's, and identify which features moved which direction at which commit. That work would refine but not contradict the structural claim above.

What Would Revise It

Sources

External: https://github.com/ChatTheatre/kernellib, https://github.com/dworkin/cloud-server.

Relations