RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
Guest posting from WWW mirror disabled. Ident on Nomad @ 9ce92808be498e9e05590ff27cbfdfe4 or sign up to post

r1s: decentralized OCI workload execution over Reticulum

Showcase

Started by mytecor ·

#1

image.png

 

Hi everyone,

 

I've been working on r1s, a small decentralized execution fabric for running OCI workloads over Reticulum.

 

The basic idea is to run containers across multiple machines without requiring a master node, central scheduler, shared database, or even direct IP connectivity between the machines.

 

Instead, Reticulum handles discovery and transport.

 

The execution model is fairly simple:

 

  1. An r1s client publishes a workload request.
  2. Available r1sd allocators respond with offers.
  3. The client selects one of them.
  4. The selected allocator starts the OCI workload through containerd.

 

There is no cluster-wide scheduler making placement decisions. Each allocator is independent and advertises its own available capacity.

 

This means the machines do not need to share a LAN, VPN, or any other common IP network. As long as they can communicate through RNS, they can participate. In principle this also makes it possible to distribute workloads across links such as LoRa or other radio transports, although obviously the actual container images need to already be available or retrieved through some other suitable mechanism.

 

A "cluster" in r1s is mostly a cryptographic trust boundary rather than a traditional cluster control plane.

 

You create it once:

 

r1s cluster init

 

which produces a public cluster ID and a secret join token. Additional clients and allocators join using that token. RNS announces only expose the derived public cluster ID, while peers prove cluster membership before exchanging control messages.

 

At this point the project has working:

 

  • RNS discovery and authenticated control traffic
  • offer/select workload placement
  • OCI execution through containerd
  • persistence and recovery across process restarts
  • temporary network partition recovery
  • cluster membership
  • workload inspection, cancellation and retained results
  • local log retention and explicit log retrieval

 

One of the main use cases I have in mind is distributed AI agent execution. I wanted something where I could start allocators on a bunch of heterogeneous machines and let agents schedule isolated workloads across them without first deploying Kubernetes, configuring a shared network, or operating a central control plane.

 

I'm particularly interested in feedback from people who have built systems on top of RNS, especially around protocol design, behaviour over constrained/high-latency links, and anything that doesn't fit well with the Reticulum model.

 

GitHub: https://github.com/mytecor/r1s

Post a Reply

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Quote
Copied to clipboard