• conforms_to::[[Reference Form Contract]]
• serves_as::[[Canonical DGD Application Kernel]]
• under_license::[[Unlicense]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Felix Croes]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Cloud Server (Croes, 2012, rev. 2026)

URL: https://github.com/dworkin/cloud-server

The dworkin/cloud-server repository is Felix A. Croes's canonical DGD application kernel — the layer of LPC code above the bare DGD driver that mediates compile-and-load, separates kernel from user privilege, manages resource quotas, enforces file access control, and provides a basic wiztool for administrative work. The repository's own README states the intent in one sentence: "The Cloud Server library is intended as a basis for other LPC projects." Cloud-server is not a complete game or application; it is the platform a DGD-based application is expected to extend or replace selectively.

The eOS-Harness MVA work surveys cloud-server as the candidate foundation against which a clean-room kernel-layer reimplementation is the alternative. The survey was conducted at HEAD 9994bc3 (2026-03-14). This Reference node captures what the survey found.

License

LICENSE declares the Unlicense (public domain dedication). Verbatim:

"This is free and unencumbered software released into the public domain. Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means."

Cloud-server is not AGPL-3. Earlier internal framing had claimed AGPL-3 contagion applied to cloud-server-derived code; that claim was wrong and was corrected during this survey. Derivative code can ship under BSD-2-Clause-Patent (eOS-Harness's intended license) without license friction.

The DGD driver itself remains AGPL-3 (separate dworkin/dgd repository). eOS-Harness builds on DGD by linking the runtime, not from its source — the AGPL-3 obligation applies to modifications and distribution of the driver, not to applications running on it.

Author and Lineage

Felix A. Croes (GitHub: dworkin; email: felix@dworkin.nl). DGD's original author and ongoing maintainer; the alias "Dworkin" predates GitHub and traces to the MUD-era driver-development community.

Git history at HEAD 9994bc3:

• Initial commit 0bc4d05 (2012-10-28): "Initial import from mudlib"
• Latest commit 9994bc3 (2026-03-14): "Add float2string()"
• Tagged versions across the 14-year span; current line is 1.2.x

The 2012 import is a reorganization of code that had existed in Croes's mudlib for many years before; the repository is the post-2012 maintained line. The reference filename uses (Croes, 2012, rev. 2026) to acknowledge both the public-release year and the surveyed-revision year.

What Cloud-Server Provides

At the worktree HEAD, cloud-server's kernel-layer surface includes:

• Compile-and-load mediation (src/kernel/sys/driver.c): the driver-callback object DGD invokes for compilation events. The _compile() function is atomic, ensuring transaction rollback on compile failure. Task-Local Storage (TLS) macros in src/include/kernel/kernel.h carry inheritance chain, source map, and accumulated compile errors through the transaction.
• Privilege separation (src/include/kernel/kernel.h): the KERNEL() and SYSTEM() macros that test caller privilege via previous_program(). Kernel-tier code lives in /kernel/, system-tier in /usr/System/, user-tier in /usr/<user>/. Each tier has distinct read/write access to file paths, enforced by accessd.
• File access control (src/kernel/sys/accessd.c): three privilege levels (READ_ACCESS, WRITE_ACCESS, FULL_ACCESS) and path normalization rules with home-directory and parent-traversal handling.
• Resource quotas (src/kernel/sys/rsrcd.c and src/kernel/lib/api/rsrc.c): per-owner tracking of objects, ticks, stack, and fileblocks. Persistence callbacks restore quotas across DGD's snapshot-and-reboot cycle.
• User management and connection handling (src/kernel/sys/userd.c, src/kernel/lib/connection.c, src/kernel/lib/user.c): per-port connection objects (telnet, binary, datagram), per-user sessions, login flow with extension hooks.
• Wiztool (src/kernel/lib/wiztool.c): the basic administrative shell with :compile, :clone, :destruct, history, evaluation, and editor integration.
• Boot configuration (cloud.dgd): the DGD config file declaring telnet/binary ports, swap and dump file paths, snapshot interval (3600s), object/call_out limits (10000 each), and the driver-object path (/kernel/sys/driver).
• System initd pattern (src/usr/System/initd.c): the system-tier initialization object the driver invokes after kernel boot. Loads the object registry, error handler, connection managers, restores resource quotas, and chains to per-domain initds.

Mapping to the Eight Runtime Primitives

The eOS-Harness strategic claim is that DGD's runtime primitives serve as platform for agent infrastructure. Eight primitives are named in the upstream value-proposition document. The mapping below states what the DGD driver provides directly, what cloud-server's kernel layer mediates, and what gaps would remain on top of cloud-server for the MVA's atomic-operation demonstration and beyond.

The four primitives marked "Provided" cover the MVA's hello-world and atomic-operation demos. The four marked "Partial" are downstream concerns (HTTP listener, agent identity, event dispatch, state introspection).

Adopted

If the foundation decision selects cloud-server, the eOS-Harness MVA likely adopts:

• The driver-object boot path (src/kernel/sys/driver.c), including atomic compile mediation and TLS context handling. The 14 years of hardening here would be expensive to replicate clean-room.
• Resource quota infrastructure (rsrcd.c and the rsrc.c API) wholesale.
• File access control (accessd.c and the access.c API) wholesale.
• The wiztool scaffold for the hello-world and atomicity demos. The basic command set (:compile, :clone, :destruct, evaluation, history) covers everything the hello-world and atomic-operation demos need.
• The cloud.dgd config as a starting template for the eOS-Harness instance config, with eOS-Harness-specific paths and a slimmer objects and call_outs budget for the demo scope.
• The privilege macros and TLS keys from src/include/kernel/kernel.h.
• Base connection.c and user.c as inheritance roots for any eOS-Harness user object.

Adopted with modification

• The System initd pattern (src/usr/System/initd.c), stripped of cloud-server's domain autoloading. The MVA does not need cloud-server's game-domain autoload chain at boot.
• The user object base, extended with eOS-Harness-specific test commands and agent-identity tagging once agent-identity work lands.
• Wiztool extension points for grafting SkotOS's extended commands selectively, if the basic wiztool proves insufficient for the atomic-operation demonstration's tracing needs.
• src/usr/HTTP/ -- the HTTP server. Configured into the eOS-Harness instance config on 127.0.0.1 per the local-inference-server transport pattern decided 2026-04-26; carries both agent-driving operations (POST /compile, etc.) and admin/wiztool-equivalent commands. Reclassified from "Not adopted (yet)" 2026-04-26 per the foundation decision.
• src/usr/TLS/ -- the TLS module. Retained in tree; not configured in MVA (HTTP localhost has no need for TLS); available for future work that fronts the runtime with reverse-proxy TLS or enables direct TLS for network-accessible deployment. Reclassified from "Not adopted (yet)" 2026-04-26 per the foundation decision.
• src/sys/jsondecode.c, src/sys/jsonencode.c, src/sys/jsonstrdecode.c -- the JSON codec. Used by the HTTP module's request/response handling and by the atomic-rollback demo's introspection round-trip. Reclassified from "Not adopted (yet)" 2026-04-26 per the foundation decision.

Not adopted

• src/usr/HTML/ -- HTML utilities. Cosmetic; not needed for the agent-infrastructure use case. Pruned during fork seed per the foundation decision.
• Cloud-server's src/lib/util/ is reusable as-is at low risk; "not adopted" means "not until a specific use surfaces."

(Reclassified 2026-04-26 per the foundation decision to adopt cloud-server with a hard fork. HTTP/TLS/JSON modules previously listed here moved to "Adopted with modification" above; the MVA transport per the local-inference-server pattern uses HTTP on 127.0.0.1.)

Conspicuously missing (for the MVA's downstream work)

Pieces eOS-Harness needs that cloud-server does not provide:

• Agent identity wrapper. Cloud-server has per-user sessions; eOS-Harness needs per-agent identity (UUID or stable name) plus state-snapshot capability. Future agent-identity work will land this.
• Event dispatch and async queue. call_out() exists in DGD but cloud-server does not wrap it into an event-bus or async/await layer. Future event-dispatch work will land this.
• JSON introspection endpoint. No built-in way to query object state, the object registry, or resource usage via HTTP/REST. Future state-introspection work will land this.
• User-facing atomic-transaction primitives. Atomicity exists at the compile level via the atomic keyword and TLS rollback; there is no library helper for "atomically transfer X across multiple objects" exposed to user code. Future atomic-op-surface work will land this.
• Multi-object state-consistency constraint. The atomic semantics are single-call-path. Cross-object atomic constraints are a separate design problem the eOS-Harness primitives roadmap addresses outside this scope.

Adoption-vs-clean-room implications

With AGPL-contagion ruled out, the foundation tradeoff reduces to:

• Adopt cloud-server: 14 years of hardened kernel-layer code, tested across many DGD applications, idiomatic for DGD authors. Cost: carrying code beyond what the MVA strictly needs (HTTP, HTML, JSON, full domain autoload), with cleanup work to slim it.
• Clean-room reimplement: ship only what the eight primitives demand, in a layout shaped for the agent-runtime use case rather than the LPC-game use case. Cost: rewriting compile-and-load mediation, privilege separation, access control, and rsrc infrastructure from scratch, against the design ground cloud-server already covered.

The license dimension of the tradeoff is gone. The remaining dimensions are engineering effort and shape-fit. The clean-room sketch and the foundation decision weighed those.

Relations

• conforms_to::[[Reference Form Contract]]

  • This Reference node carries a public URL, an Adopted / Not adopted (yet) body split, an authored_by:: identity edge, and a serves_as:: target -- the structural obligations the Reference Form Contract enforces.

• serves_as::[[Canonical DGD Application Kernel]]

  • Names what cloud-server functions as in the eOS-Harness graph: the canonical implementation of the LPC kernel layer above the DGD driver, and the comparison baseline for any clean-room kernel-layer alternative.

• under_license::[[Unlicense]]

  • The Unlicense (public domain dedication) is the load-bearing license fact for the foundation-choice tradeoff. Other AGPL-3 references in the eOS-Harness stack (DGD itself, SkotOS, kernellib) need their own license edges when they get Reference nodes of their own.

• grounded_in::[[DGD Driver]]

  • Cloud-server runs on the DGD driver and depends on its callback contract. The DGD Driver Reference (not yet authored) will be the citation target for the AGPL-3 driver itself; until it exists, this is a ghost link that will resolve when the DGD Reference lands.

• contrasts_with::[[Kernellib (Allen, 2026)]]

  • The ChatTheatre/kernellib reference, when authored, will be cloud-server's Skotos-derivative comparison point. Both are kernel-layer LPC code; they diverge on extensions, modifications, and naming conventions. The contrast edge will resolve when the kernellib Reference lands.

• grafted_from::[[eOS-Harness MVA Graph (Allen, 2026)]]

  • Boundary-node copy: the origin graph retains its own; this copy is owned and evolved here. Formal graft-chain registration is a meta-layer concern tracked separately.