Playing: the Twinton factory twin, an app on CE · geometry reconstructed, states simulated and labelled
ce-net · Shenzhen · Stockholm
CE is the peer-to-peer substrate: one node per machine, no accounts, no cloud bill. Twinton is the first thing built on it: a factory floor rebuilt from one walkthrough video, every machine carrying the frame it was seen in, every simulation saying so on the screen.
TWINTON FACTORY / INTERACTIVE DEMO
Explore machines and workforce, trace material picking, test a stoppage and compare scenarios. The actual factory model runs in your browser.
Explore the factory →Capabilities & evidence ↗Authored geometry and simulated activity · no plant connection“Every machine on it came from one drone video. Three minutes and eight seconds, public, filmed by the plant's own marketing team. We didn't survey it, we didn't ask for a CAD file.”
“Current operating state: unknown. That's on purpose. We don't paint a green light nobody measured.”
“It answers one question: when an order is late, where is it waiting?”
“Pause one stage for twenty minutes. Thirty batches instead of thirty-seven, and the twin shows which upstream machines went idle while it happened.”
We walk your floor with the demo on a laptop, pick one product family and roughly five to ten workstations, and agree the baseline, the technical review and the decision date before anything is installed.
Then we connect the real floor: your cameras, a barcode scan, an app, a button on the bench. The twin starts answering where the late order is waiting, with a queue-age alert a named supervisor can act on.
Book the walk-through Currently in Shenzhen; we come to your floor.
CE, pronounced Sea, is a peer-to-peer compute mesh. A running ce start is a node: one identity, one HTTP API on loopback, one mesh endpoint, and one in-process supervisor that installs, starts and keeps alive every app on that machine. A Twinton gateway on your floor is exactly that: a CE node, paired to your twin by one approval, with no bearer token on the path to steal.
Every node gets an identity, a mesh transport with NAT traversal, content-addressed blobs, capability-based authorization and an app manager. Apps are built on top of these primitives, never into them; everything above the node is replaceable.
CE owns generic, node-enforced mechanism: keys, bytes and permissions. Every node is assumed hostile; authorization is a signed, attenuating capability chain verified by the node that acts, and nothing else. The economy, schedulers, reputation, markets and team billing are apps, deliberately not in the kernel.
ce-identityAn Ed25519 keypair. A NodeId is a principal: a person, a device and an app are all just keys. No accounts, no registration.
ce-meshlibp2p: directed request and reply, pub/sub, raw streams, Kademlia discovery, NAT traversal by relay, DCUtR, QUIC and mDNS. Device-to-device traffic always rides the mesh, never a stored ip:port.
ce-blobImmutable data addressed by sha256 CID, fetched trustlessly from whoever provides it and verified against the hash. The hash is the trust, not the source.
ce-capThe only authorization mechanism. A signed, attenuating chain rooted at a trusted key authorizes an opaque ability string. The verifier matches strings; it never means them. Revocation is directed and gossiped.
ce-laneA tunnel is a raw mesh stream: port forwarding as a transport primitive. A lane is the same-host zero-copy path, shared-memory rings verified by capability at bind.
ce-appmgrInstall, resolve, sandbox and supervise any app from a manifest, in the OCI, native, wasm, recipe or script tier, locally or on a remote node over the mesh. Every app is a principal with a scoped capability chain.
Nodes advertise capacity and self-tags to an atlas; the DHT answers who provides a named service; a netgraph carries measured per-peer round-trips for latency-aware placement.
Directed signed messages, synchronous request and reply, and namespaced pub/sub. Five verbs, the same on a laptop, a relay, a browser page and an embedded chip.
There are no accounts. Every participant is an authenticated peer with its own keypair, and the mesh verifies every sender. Your handler receives the caller already verified; the ability a method requires is declared in the schema itself.
Pub/sub and typed events are substrate primitives. A provider emits a schema-validated event and every subscriber receives it live. Because every peer can serve, the app does not die when one machine goes away.
One contract gives compile-time types, runtime validation on both ends of every call, typed error codes, typed events and the required ability, visible in the schema. It exports as neutral JSON, so other languages bind from the same source.
A deploy is one command, local or on a remote node. Services are supervised daemons on machines you and your users own, and the same app runs unchanged wherever it lands: a laptop, a relay, a three-dollar microcontroller with its own identity.
early access · from the developer quickstart: two machines talking, one grant, no login system
# on B, the resource owner: issue a signed, attenuating, revocable capability
ce grant <A-node-id> --can exec,sync,tunnel --expires 90d
# on A, the holder: keep it under an alias
ce wallet add b-machine <B-node-id> --cap <token>
# then talk, run and reach, over the mesh
ce app install clip --on fleet=mine # one app across every device you have paired
ce tunnel b-machine 2222:22 # any TCP over the mesh, NAT or not
rdev exec b-machine --image alpine -- uname -aHonest framing: the public mesh is young and the core repository opens with early access. Everything above works today on machines you control, and nothing about it assumes a central operator. Public today: ce-net/rdev, ce-net/ce-ci, and twinton.ai.
Currently in Shenzhen; we come to your floor with the demo on a laptop. 我们在深圳，可以到贵厂当面演示。
leif@rydenfalk.com Leif Rydenfalk · CTO, Twinton · building CE
