Drift, ordering assumptions, deadline propagation, and expiration semantics under real load.

I recently published a technical book, Distributed AI Systems, which summarizes my experiences in AI over the past 10 years, from research and training to optimization, inference, and cloud deployment. I started writing it in the second half of last year, and it took almost a year to complete, with many revisions made later due to the rapid pace of development in the industry. But it's finally published. The book on Amazon is titled Distributed AI Systems: A practical guide to building scalable training, inference, and serving systems for production AI.

Book is here: 🔗 https://www.amazon.com/dp/1807301710/

The publisher asked me to find some people to review my work. Do you know of any such people here? If so, please reply to me. Thank you.

​

If you are dispatching isolated batch container jobs across a highly distributed network of unstandardized, untrusted worker nodes, the orchestration logic gets messy fast.

If you have a central master scheduler matching workloads based on live node environments and hardware states, the coordination overhead becomes a massive bottleneck. But if you don't orchestrate heavily, jobs constantly fail due to dependency mismatches or network latency when pulling data files to the execution host

.

For those building on zero-trust or decentralized infrastructure: how are you solving the locality scheduling problem without slipping back into heavy, centralized master-node architectures?

What happens when network calls stop behaving like clean request/response interactions.

Timeouts, retries, duplicate side effects, idempotency, backoff, circuit breakers, load shedding, degraded states, and observability.

I made ce-net - a wasm based supercomputer available to everyone - as long as you donate!
ce-net.com

Hey folks,

We’ve been exploring decentralized P2P compute networks for spinning up minor processing jobs and testing out autonomous ML agents. Financially it makes sense, but we hit an absolute brick wall regarding data compliance.

If we have to run a script on raw, sensitive enterprise datasets or proprietary user data, moving that raw data onto a random peer-to-peer node is a complete non-starter for security.

For anyone who has integrated P2P nodes into a dev pipeline, have you actually deployed this kind of container-isolated Compute-to-Data workflow?

How do you reliably verify the container's isolation on a zero-trust peer node without introducing crazy orchestration overhead?

Let’s build the strongest supercomputer ever

ce-net.com

Always open source. All policies decided by users by voting - full democracy.
Run any compute task.

A bit of background about me.

​

“I have about 4 years of experience primarily working on traditional software development building enterprise apps. While the career path is stable now ( don't know if AI takes over), I find myself deeply interested in systems architecture, low-level optimization, and parallel computing. However, giving up a full-time income to go back to school feels like a massive investment. Is a Master's degree the right vehicle for this transition, or are there better ways to break into the industry? I'd love to hear from anyone working in HPC, climate modeling, quantitative finance, or scientific computing."

​

All I want is to future proof my career.

Over the last 2 years I've been building Atomic, a Spark‑inspired distributed data processing framework written entirely in stable Rust. The goal is to keep the parts of Spark that are great (lazy DAGs, shuffles, distributed execution) but re‑imagine them with modern infra and language design.

A few things that make Atomic different:

Rust core: Strong typing, predictable performance, and memory safety by default. You get a real systems‑level engine, not a JVM box you bolt on next to your stack.

Natural‑language workflows: On top of the engine, Atomic is designed to be driven by natural‑language workflows – letting you describe what you want done and compile that into a typed DAG, instead of hand‑wiring every pipeline.

Multi‑language support: Rust is the "ground truth" but the plan is first‑class bindings for Python and JavaScript, so you can drive Atomic from the languages your data and app teams already use.

No closure serialization: Instead of shipping arbitrary closures across the wire, tasks are registered at compile time via a #[task] macro and dispatched by ID. Driver and workers run the same binary, so the dispatch table is identical on every node — no serialization failures, no version skew surprises.

This is my attempt to build modern infrastructure tooling for data processing. It initially started as a learning project and now I feel it has evolved into something significant to be delivered. I'd love to hear your feedback:

Repo: https://github.com/sandyz1000/atomic

Hey everyone,

I'm working on the architecture for a new open‑source distributed compute framework called Project Cerberus, and I want to get reality‑checked by this community before I commit to the core stack.

The Concept:
A zero‑config, P2P mesh network that aggregates heterogeneous consumer hardware (Macs, Windows rigs, headless Linux boxes, and even phones) on a local subnet into a single virtual hyper‑computer.

I know Exo (exo-explore) has basically perfected local AI model sharding (pipeline parallelism for LLMs over Wi‑Fi/Thunderbolt). Cerberus isn't trying to just be another AI inference engine. I want to build a decentralized virtual OS layer that pools everything:

1. General Compute: Compiling user workloads to WebAssembly (Wasmtime) and distributing the execution slices across node threads.
2. Storage Pooling: A FUSE‑based user‑space filesystem that erasure‑codes and strips data across the unused NVMe/SSD space of all connected devices.
3. Audio/Peripheral Virtualization: Using PipeWire/CoreAudio to route synced audio across multiple device speakers (sub‑millisecond NTP sync) or pooling local mics.

Proposed Tech Stack:
Control Plane: Go (Golang) + libp2p (mDNS for zero‑config discovery, Gossipsub for topology mapping, QUIC for transport).
Compute Plane: Wasmtime for architecture‑agnostic sandboxed execution + MLX/tinygrad for the AI tensor sharding.
UI/Gateway: Tauri (Rust/Next.js) for a lightweight dashboard, exposing an OpenAI‑compatible REST API wrapper for devs to point localhost to.

My questions for the distributed systems vets here:

1. Network Latency: For the WASM general compute sharding, is QUIC transport fast enough to handle the context handoffs over standard Wi‑Fi 6, or will the network latency obliterate any compute gains?
2. Consensus: I want to avoid a master‑worker setup. If the coordinator node drops (e.g., someone closes their laptop lid), what's the cleanest way to run a fast raft/bully election in Go without dropping the current FUSE read/writes?
3. Are there any existing crates/libraries for the distributed audio sync that I should look at before trying to build a custom WebRTC/RTP bridge?

Would love any feedback, warnings, or pointers to obscure repos doing something similar. Thanks!

I'm interested in large-scale distributed computing projects. Imagine millions of users voluntarily donate spare CPU power, but only in very small chunks—around 5–7 seconds of computation per task before requesting a new one.

The ideal problem would:

• Be highly parallelizable
• Require little communication between nodes
• Allow work to be split into millions or billions of independent tasks
• Be CPU-heavy rather than bandwidth-heavy
• Be verifiable (so malicious or faulty clients can be detected)

Besides the usual examples like protein folding, cryptocurrency mining, or SETI-style searches, what are some interesting real-world problems that fit this model?

Hey everyone,

I’ve been working hard on building a decentralized distributed model hosting network called Elis AI, and I wanted to share it with the community here to get your honest feedback, critiques, and feature requests.

The goal of the project is to build an open, competitive marketplace for AI compute that breaks away from centralized tech giants. The community tier allows anyone to tap into a global network of open-source models, or spin up their own hardware to host them.

Here is a quick breakdown of how it works and how you can use it right now.

🚀 How the Platform Works

The ecosystem relies on crowdsourced resources. You can interact with it in two different ways depending on what you need:

1. As a User (Accessing Models)

• Unified API & Interface: You get access to over 380 open-source and fine-tuned models (ranging from lightweight 7B models up to massive 70B+ checkpoints).

• Intelligent Routing: We built a token-aware Model Context Protocol (MCP) server. It automatically compresses your context and routes requests. Simple prompts hit smaller, faster models, while complex logic triggers frontier models to save you on token costs.

• Network Economy: The system utilizes internal utility credits ($ELIS) to handle model access and routing priority.

1. As a Node Operator (Earning Credits)

If you want to monetize your spare hardware, you can provision your rig:

• Solo Mining: You can connect any PC or server with an NVIDIA GPU (16 GB VRAM recommended) or CPU cluster. The network runs blind evaluation prompts to score your machine on uptime and latency, rewarding you with epoch credits.

• Community Pools: If you don’t want to run a solo node, you can delegate a minimum of 100 $ELIS tokens into a managed community mining pool where operators handle the hardware upkeep.

───

🔑 The BYOK (Bring Your Own Key) Options

Data privacy is a massive concern with decentralized networks, so I made sure to build in a robust BYOK (Bring Your Own Key) mode for complete security control.

How BYOK alters the data flow:

1. Elis AI UI: You write your prompts directly in our interface.

2. BYOK API Gateways: Instead of routing your data to volunteer hardware, the requests route directly to external commercial providers (like OpenAI) using your personal API keys.

3. Secure Data Isolation: This completely bypasses the public miner registry, guaranteeing zero data retention on public community hardware.

Why use it? It gives you full cryptographic data control. Your information is encrypted using keys generated outside our infrastructure, allowing you to bypass public miners entirely while maintaining compliance standards (like HIPAA or GDPR).

───

🛠️ I'd Love Your Feedback!

I am actively developing this and want to make it as useful as possible for developers, privacy advocates, and miners.

• What features are missing that would make you use this daily?

• For the miners here, does the reward/pool structure make sense?

• Any edge cases or security flaws you think I should double-check?

Check out the site at tryelisai.com/community and let me know what you think. If anyone wants the exact terminal commands to connect a GPU rig or set up the API, let me know in the comments and I'll drop them below!

its a demo that explains it better than i can.. https://jc-compute.github.io/jc-compute-demo/