Does this skill require specific networking hardware?

No, it uses software-defined networking via Tailscale and LocalSend, allowing it to work across diverse hardware including Linux servers, Macs, and workstations.

What is the GF(3) invariant in this context?

The GF(3) invariant is a mathematical rule ensuring the sum of node states (trits) equals zero mod 3. This triggers automated migration from overloaded (PLUS) nodes to underloaded (MINUS) nodes to keep the mesh balanced.

How does live process migration work?

It utilizes CRIU (Checkpoint/Restore In Userspace) to dump the state of a running process into a checkpoint file, transfers it over the mesh, and restores it on a target node with excess capacity.

What tools are needed to run the resource monitor?

The monitoring scripts are written in Babashka (bb), a fast native Clojure scripting engine, providing low-overhead performance tracking.

Mesh Resource Sharing

Name: Mesh Resource Sharing
Author: plurigrid

byplurigrid

•

Deployment & DevOps

Distributes computational workloads across a peer-to-peer mesh network using GF(3) balanced allocation logic.

About

This skill implements a sophisticated resource-sharing pattern based on the 'all category resource sharing machines' architecture. By classifying nodes into a tri-state system—receivers (-1), brokers (0), and senders (+1)—it maintains system equilibrium through the GF(3) invariant. It leverages robust infrastructure tools like Tailscale for secure networking and CRIU for live process migration, allowing Claude to intelligently offload heavy computational tasks to idle hardware across a distributed environment while monitoring performance via Babashka-driven scripts.

Key Features

Live process migration using CRIU (Checkpoint/Restore In Userspace)
2 GitHub stars
GF(3) balanced load distribution and node classification
Peer-to-peer mesh networking via Tailscale integration
Real-time resource monitoring with Babashka (Clojure) scripts
Automated file sharing to idle peers using LocalSend

Use Cases

Managing distributed compute clusters without a centralized master node using the Ergodic broker pattern
Optimizing multi-node development environments by migrating 'SCUM' (high-resource) processes to underloaded nodes
Dynamically offloading heavy compilation or data processing tasks to idle machines in a home lab or office

About

Key Features

Live process migration using CRIU (Checkpoint/Restore In Userspace)
2 GitHub stars
GF(3) balanced load distribution and node classification
Peer-to-peer mesh networking via Tailscale integration
Real-time resource monitoring with Babashka (Clojure) scripts
Automated file sharing to idle peers using LocalSend

Use Cases

Managing distributed compute clusters without a centralized master node using the Ergodic broker pattern
Optimizing multi-node development environments by migrating 'SCUM' (high-resource) processes to underloaded nodes
Dynamically offloading heavy compilation or data processing tasks to idle machines in a home lab or office