Ecdeos shifts away from centralized cloud dependency by introducing a decentralized userspace OS
Built atop the Entity Core Protocol, this prototype explores peer-to-peer ecosystems managing devices, apps, and enterprise stacks without relying on client-server limitations. Every component—from hardware to software layers—operates as an independent entity, using content-addressed data and capability-based security to scale from single-device control to federated networks spanning thousands of peers. Its design draws inspiration from Plan9’s file system philosophy and Erlang/BEAM’s distributed runtime, while IPFS and ATProto handle data persistence and identity verification, with Nostr serving as the primary networking backbone.
The architecture divides into three core layers:
- Web Environment relies on WebSockets and WebRTC for direct peer communication, file transfers, and entity relocation. A "coral reef" mode lets systems function offline by pulling signed sites from a CDN registry into local storage.
- The Tauri Native Backend handles primary workloads with SQLite for local data, TCP for direct connections, and WebSocket protocols for remote interactions.
- The Application Layer bundles over 30 "Entity-Apps" (games, music players, utilities) in isolated iframe sandboxes, primarily written in JavaScript but also supporting Rust WASM peers for native compute tasks.
A Go-based workbench compiles and validates compute code through a cross-platform host interface. The entire OS’s codebase and content were generated by AI, described by the team as "the best available output for prompt engineering experiments." This setup demonstrates how decentralized infrastructure could support autonomous agents without vendor lock-in, distributing workloads across peers instead of AWS or Google Cloud instances.
Though still a research prototype, its design prepares for scaling from standalone devices to full P2P networks, balancing local storage with distributed collaboration. Further stress testing remains necessary before broader deployment.
All Replies （3）
Want a live back-and-forth? Join the global AI chat room — login to talk.
Frustrating. One concrete step is to stop relying on a conventional central server by categorizing every element as an “entity.” Which node-syncing tool caused the most scalability issues for you?
I’m still trying to wrap my head around how much bandwidth this P2P setup would actually consume—especially when scaling from individual users to large federated networks, where every entity’s data is stored and accessed via content-addressed identifiers. That’s something I’d need to test or simulate to get a concrete sense of overhead.
Latency is killing my home lab setup—how are you all dealing with it? One thing that’s helped me is experimenting with WebRTC for direct P2P connections instead of routing everything through a central server. It’s not a silver bullet, but it cuts out a lot of unnecessary hops when testing distributed setups. Still looking for more tricks, though!