DEV Community: chovy

MeshHook now runs your workflows on c0mpute

chovy — Mon, 02 Nov 2026 14:54:02 +0000

MeshHook now runs your workflows on c0mpute

MeshHook is our MIT-licensed, webhook-first workflow engine: you drag nodes onto a canvas, wire them up, and a webhook starts a run. As of today the steps in those runs execute on c0mpute, our peer-to-peer compute network. Think n8n, except the work happens on other people's machines instead of yours.

Try it at meshhook.com.

What runs where

AI steps call open models on c0mpute nodes through the Infernet open market. They are peer-only: a step never falls back to a paid hosted model. The default is qwen2.5:1.5b, then 0.5b, because several nodes serve them and a JSON-shaped prompt comes back in about 10 seconds. You can pick a bigger model per node if you can wait for it.
JMESPath transforms and HTTP calls are auctioned as workflow.step jobs. Any c0mpute worker on 0.2.56 or later bids on them by default. The winner runs the step and returns a result MeshHook checks by hash.
Branches, loops, delays and template transforms stay on the MeshHook server. They are cheap, and they need the run's state.

A real run from this afternoon: webhook, then an AI step on a node in Vienna, then a transform and an HTTP call on a c0mpute worker. 25 seconds end to end, and the run log records which worker ran each step and what it cost.

Your credentials stay home

A worker sees the whole step it runs, so MeshHook keeps an HTTP call on its own server whenever it carries anything secret: an Authorization or cookie header, anything that looks like a key or token, user:pass@ in the URL, or a secret template. To send those steps to the network anyway, pin your own workers in the workflow settings.

Workers refuse to fetch private, loopback, link-local and cloud metadata addresses. They pin the connection to the address they checked and re-check every redirect.

If the network cannot do something (nobody bids, the bridge is down, or an API answers 402, which only MeshHook's x402 key can pay), the step runs on the server. The log says why.

Pick per workflow

The editor has a Runs on menu with four options: Auto, c0mpute network, This server, or Private. Private means nothing but AI steps leaves the server, whatever the default is.

Run a worker

Every c0mpute worker on 0.2.56 or later serves workflow steps. Install one with:

curl -fsSL https://c0mpute.com/install.sh | sh

Every node you add makes everyone's workflows faster. The protocol details are in DIP 0030, in the c0mpute repo.

Source: github.com/profullstack/meshhook and github.com/profullstack/c0mpute.

How would you use a workflow engine whose steps run on a peer network instead of a server you pay for?

Train a business strategy model from links, on c0mpute, and publish it to Hugging Face

chovy — Mon, 02 Nov 2026 11:08:31 +0000

We trained saas-business-strategist-agent today: a small business and SaaS strategy model, trained on a CPU from a list of links, and published it on Hugging Face. You can train your own the same way.

Model: https://huggingface.co/profullstack/saas-business-strategist-agent

Links in, model out

The c0mpute example takes links and turns them into a training corpus:

rssamplifier.com topic pages, now with comma lists: https://rssamplifier.com/topics/business,saas,crypto pulls every blog and news feed filed under any of the three (2,087 blogs).
pit.world searches: https://pit.world/search?q=saas,business,crypto runs each term on the web, news and scholar tabs and fetches every result page.
Single feeds, any web page, or a pasted list of links on stdin.

No API keys. rssamplifier and pit.world both have open APIs and MCP servers, so the harvester is one Node script.

node harvest.mjs https://rssamplifier.com/topics/business,saas,crypto \
  'https://pit.world/search?q=saas,business,crypto' --full --out data/saas-business.jsonl

Train it on c0mpute, or on your own CPU

c0mpute 0.2.50 runs LoRA fine-tunes as a network job: workers bid, the winner trains, you watch a live progress bar, and the adapter's sha256 is checked against the receipt.

c0mpute infernet text train --job job-saas.json --dataset data/saas-business.jsonl \
  --output out/saas-business-strategist-agent --yes

Or locally:

.venv/bin/python train.py job.json --name saas-business-strategist-agent --dataset data/saas-business.jsonl

The numbers

Base model: Qwen2.5-0.5B-Instruct, a rank 8 LoRA (about 1.1M trainable parameters), bf16.
Corpus: 3,615 posts (business 1,514, crypto 1,471, SaaS 630), 1,447 of them full articles.
400 steps on 4 CPU threads, 2.4 GB peak RAM. Held-out perplexity went from 44.5 to 28.6.
The adapter is 4.4 MB.

The first version used a 135M model. It echoed questions back. 0.5B answers on topic: asked how a 3-person SaaS should price its first plan, it said "one monthly price, one annual price at 10 times the monthly, and no other discounts" and cited three SaaS pricing guides.

A sub-1B model learns the voice, not the facts. So the agent searches pit.world for each question and puts the top pages in the prompt. The facts come from search and the tune supplies the register.

Two things that bit us

torch uses one thread per core by default. On a busy 32-core box that ran at 22 tokens a second. Four threads ran at about 330.
earlyoom kills big processes on a shared box with exit code 143 and no traceback. The trainer now saves a checkpoint every 25 steps and resumes when rerun, so a kill costs minutes instead of the run.

Also shipped today

pit.world search results show short, readable snippets instead of page dumps, and each result has a Summarize button that runs on c0mpute (5 an hour without an account, 60 signed in). The Images, Videos, Live, News, Music and Places tabs work again on free sources.
rssamplifier.com takes comma lists everywhere a topic goes: pages, the JSON API, RSS and Atom feeds, and MCP.

Try it

The example, with the harvester, trainer, chat and Hugging Face publisher: https://github.com/profullstack/c0mpute/tree/master/examples/business-strategist-agent

Swap the links for your own topics and give it a name.

Build an Agent-Ready App Starter with the Profullstack Stack Builder

chovy — Fri, 30 Oct 2026 21:45:12 +0000

Starting an app with a coding agent should not mean rebuilding the same project skeleton. This walkthrough uses Web + API + MCP to start a small status service with a browser app, an HTTP API and an MCP tool. The Stack Builder exports a source ZIP. It does not deploy a finished application.

Step 1: Choose the surfaces. Open the free builder, name the project, then select Web, API and MCP. Add only modules that fit the project. The module list changes with the selected surfaces.

Step 2: Export and inspect. Download the ZIP and read README.md, AGENTS.md and CLAUDE.md first. The agent instruction files match. For this selection, app/ contains the Next.js web app, src/api/server.ts contains the Hono server on Bun, src/mcp/server.ts starts the MCP server over stdio, and src/core/index.ts contains the shared status function.

Step 3: Run the starter. From the project root, run bun install. Start bun run dev for the web app on port 3000 and bun run api for the standalone API on port 3001. Run bun run mcp in a separate terminal when you want to use the MCP server. The web app also mounts the API under /api. Run bun test before changing the starter.

Step 4: Give your coding agent one bounded task. Ask it to read AGENTS.md and CLAUDE.md, then add one project-specific feature in src/core and expose it through the API and MCP server. Ask for a test alongside the feature, run bun test, and review the generated files before you continue.

The ZIP is scaffolding. Configure secrets and external services, review the code, and test the application before deployment. Try the builder at https://profullstack.com/stack/build?utm_source=devto&utm_medium=article&utm_campaign=stack_builder_launch_20261030 and tell us which module should come next.

Ten-Second Agent Standups: Agile Feedback Every 2 to 4 Hours

chovy — Thu, 29 Oct 2026 08:38:29 +0000

When you run a fleet of coding agents, a daily stand-up is too slow to surface a stuck task and a live meeting is the wrong way to pull a dozen agents out of work. Give each active agent a ten-second asynchronous stand-up every 2 to 4 hours. The goal is a shorter feedback loop between a task changing state and the sysop acting on it.

The contract

Every update has three fields:

Done: the last verifiable checkpoint, with a commit, preview or artifact when there is one.
Next: one small, verifiable slice.
Blocked: the dependency and the decision or person needed, or none.

Write it in ten seconds or less. Report a result, not a mood. If nothing changed, say No state change. Still working on [the next slice]. Put the update beside the task and its artifacts, where the sysop can act on it.

The 2 to 4 hour clock starts at the agent's last update. An idle agent has nothing to report. A blocked agent does not wait for the clock.

Shorten the feedback loop

The 2020 Scrum Guide describes the Daily Scrum as a way to inspect progress toward a Sprint Goal and adapt the plan. A fleet has a different clock. An agent can hit a missing credential, a failed build or a bad assumption hours before a daily meeting. A compact update lets the sysop reassign the work, answer a question or stop a duplicate task while there is still time in the work cycle.

That is the agile part: keep the goal visible, make work small enough to verify, and change the next step when new evidence arrives. The update does not make code faster by itself. It reduces the time work sits blocked or invisible.

Keep it asynchronous

A stand-up every few hours becomes another interruption if it summons everyone into a call. Software engineering research has found that task switching can disrupt developer work. One analysis of 4,910 recorded tasks from 17 professional developers, paired with a survey of 132 developers, found self-interruptions were more disruptive than external interruptions and negatively affected the interrupted tasks. The stand-up should therefore be a short log entry, not a context switch.

If an agent is in the middle of a safe, bounded operation, let it finish that slice and post at the checkpoint. Do not make it wait for other agents. Surface urgent blockers immediately. If a task goes four hours without a useful update, mark it stale and ask whether it should continue, split or stop.

Measure whether it helps

Try the cadence for a week. Track how long blockers wait for the sysop, how many completed checkpoints get reviewed, and how many active tasks have no clear next step. If the updates change no assignment, priority or review decision, make them shorter or less frequent. The point is not to produce more status. The point is to keep the next useful action obvious.

The Scrum Guide: https://scrumguides.org/scrum-guide.html

Task interruption study: https://arxiv.org/abs/1805.05508

My AI agent hosts a podcast now, and you can be on it

chovy — Mon, 26 Oct 2026 18:14:20 +0000

Off The Record is a long-form podcast with no human host. riotcoder, the agent that ships most of my code, calls the guest on the phone and runs the interview. It works off a recorded group.call line, uses an ElevenLabs voice, and calls a clock tool every ten minutes so it wraps up on time.

I was the guest on episode 1, "Running 300 Repos with AI Agents on Bare Metal": https://offtherecord.podcast.pit.world/e/1

Now it takes other guests, and it is free. If you are building something with AI agents, running a fleet, or working on the new internet, leave your number here:

https://offtherecord.podcast.pit.world/guest

That is the whole signup. You give your name, a phone number, two or three sentences about what you build, and a topic if you have one. When your episode is booked your phone rings. Press 1 and the host joins. You don't need an app, a link or a studio.

The host reads what you wrote before the call, and it is told that this is the only thing on the record about you, so it asks instead of guessing. The formats range from a 35 minute sprint to about two hours. A person listens to every recording before it goes out, and your number is never published.

Feed: https://offtherecord.podcast.pit.world/feed.xml

group.call: a party line for people and AI agents

chovy — Mon, 26 Oct 2026 16:17:49 +0000

group.call: a party line for people and AI agents

Today we launched group.call. Make a room, get a four-digit code, and everyone dials one number: 510-616-9327 (510-616-W3BS). No app, no link, no browser tab. A landline works. So does a car.

The part we built it for: AI agents phone in too. Ask an agent into the room and it dials the same number, keys the code with touch tones, says who it is, and takes part in the call out loud. Ours are riotcoder and cha0spunk. They hear everyone, answer when they are spoken to, and stay quiet when people are talking to each other.

What made it hard

Putting a language model on a phone call is easy. Making it a decent participant in a group call took most of a day of live testing with real people on the line:

One voice at a time. Agents take turns with a shared floor, wait for two seconds of silence before they speak, and stop the moment a person talks over them.
They hear the room the way the room heard it. Every leg is transcribed separately, so each line has a speaker. Agents read that, not their own muddy mix of the call, so they know who asked what.
Memory. The room's transcript is the agents' memory. If an agent drops off the call, it is dialled back in, reads what it missed, and carries on without introducing itself again.
Deploys do not touch a live call. Who is in which conference is saved and restored on restart, and the proxy holds webhooks while the app restarts. We shipped a dozen releases today with people on the line.

Use it

Web and phone: sign in with CoinPay at group.call.pit.world. Three rooms and 300 minutes a month are free; a $5 room pass gives you 50 rooms and codes you pick.
Your own agent: an API, a CLI (bunx @profullstack/groupcall), a TUI and an MCP server. Make rooms, see who is on the line, read the live transcript, say something into the room, or have your own agent dial in under its own name.
Desktop: Mac, Windows and Linux builds, with the CLI inside.
Invites: every account gets three single-use invite links. When someone signs in through yours, you both get an hour of calls.

Open source

The phone engine is @profullstack/group-call, the same code that runs the nixamp party line. The site is moshcoder/group.call. Credit codes and invites come from two new house modules, @profullstack/redeem-credits and @profullstack/affiliates, which are going onto every Profullstack site next.

Call 510-616-9327 and say hi.

Your marketing brain belongs in a git repo, so myna and OutreachGraph now read one

chovy — Mon, 26 Oct 2026 13:40:27 +0000

Your marketing brain belongs in a git repo, so myna and OutreachGraph now read one

Ina Toncheva wrote a piece this week called "Your marketing team will be on GitHub" (https://inatoncheva.substack.com/p/your-marketing-team-will-be-on-github). The idea is simple and I think she is right. Your AI setup is not a pile of documents. It is a set of files that depend on each other. Change the positioning file and every skill that writes copy changes with it. Google Drive cannot tell you which edit made last week's posts sound off. Git can, and it can undo it in one step.

The team she profiles keeps a "content brain" in a private repo: what the company does, positioning, audience, brand voice, and the questions prospects keep asking on sales calls. Skills sit on top. Someone improves a skill, pushes it, and the whole team has it. They report about 20 hours a week saved.

I had the same knowledge scattered across two of my own tools, so I gave both of them the same repo layout:

brain/
  knowledge/
    positioning.md   what it is, who it is for, why it is different
    voice.md         how it sounds, what it never claims
    audience.md      who we sell to
    objections.md    what prospects push back on
  skills/            myna skill files

myna 0.47.0: myna brain

myna brain init ~/brain          # scaffold from your brand.md and skills, git init
myna brain link git@github.com:you/brain.git
myna brain pull                  # the daemon also pulls hourly
myna brain push -m "tighter positioning"
myna brain show --show-prompt    # see exactly what the writer reads

Every draft, reply and plan myna writes now reads the knowledge files after your brand file: positioning and voice first, then audience and objections, capped at 24 KB. The repo's skills fill in any skill you have not written locally. A file you edited by hand still wins. With no brain linked nothing changes.

OutreachGraph 0.19.1: og brain

og brain list
og brain export <productId> --dir ~/brain
og brain import <productId> --dir ~/brain

Export writes a product's positioning, voice and audience out of the database, plus an objections.md built from the replies prospects actually sent. Replies the classifier labelled as a question, a no, or a referral are grouped, with names, emails and links stripped. That is the sales-call file from Ina's post, built from replies instead of from memory. Honest status: my own workspace has no replies labelled that way yet, so my objections.md is empty today. It fills as replies come in. Import goes the other way, so an edit someone reviewed and merged in the repo becomes the voice the next cold email is written in. The same calls are on the API (GET and PUT /api/v1/products/:id/brain) and MCP. npm i -g @profullstack/outreachgraph gets you the og CLI.

The loop

OutreachGraph learns what prospects object to. og brain export writes it down. You commit it, and a teammate reviews the diff. myna pulls it within the hour, and the next post answers the objection before anyone raises it. If a change makes the copy worse, git revert.

Her getting-started advice is the right one: make a private repo and write one file, positioning. myna brain init does that part for you.

Teach an agent by doing the task yourself (and why the liquid net lost)

chovy — Mon, 26 Oct 2026 08:40:58 +0000

We shipped "Teach an agent" in W3BS Training today. You record yourself doing a task on your desktop, review and redact the recording, and train a small model on it. Then the agent can suggest the next step, or do it with your approval.

It ships in three pieces:

Infernet v0.1.66 adds the model engine. There is a new npm package, @infernetprotocol/liquid-agent, and a Python runtime with three model types: CfC and LTC (the "liquid" neural nets) plus a plain GRU baseline. infernet model train|evaluate|predict|serve drives it.
c0mpute v0.2.34 lets another machine on the network do the training for you. Only trusted workers you list, only with --yes, and the trained weights are checked against the hash in the receipt. Sessions are encrypted end to end.
W3BS training-v0.3.0 adds the Teach tab and w3bs training teach. Training runs locally by default. Sending it to a c0mpute worker is opt-in and shows you a preview first.

Safety is the default

On a fresh install all five permissions are off and every policy mode is Off. Secrets are masked at capture time, before anything is written. Every external write (sending an email, posting, messaging) needs a person to approve it, in every mode, including Bounded. There is a kill switch and an audit log.

The honest result

I benchmarked on synthetic traces from mock email, Reddit and LinkedIn flows. The GRU beat the liquid CfC: 0.948 vs 0.869 episode success. So GRU stays the default. Every model failed on a screen layout it had not seen, and nothing passes the closed-loop safety gate yet, so the agent refuses to switch itself on. That is the design working.

The next step is real recordings of real tasks, not synthetic ones.

Try it

Start at https://w3bs.org/training and open the Teach tab. Everything is off until you turn it on.

Our P2P inference network had 4 of 48 nodes online. Here is why, and the fix

chovy — Thu, 22 Oct 2026 12:04:34 +0000

Infernet is a peer-to-peer GPU and CPU inference network: you run one command, your machine serves open models, and clients pay per job. This morning our status page said 4 nodes online out of 48 registered, and all 4 were ours.

The other 40-odd were real people: Mac minis, Windows desktops, cloud VMs, one H20 box. They installed, served jobs (one served 243 of them over 52 days), and then went quiet and never came back. So we went looking for why.

What was killing nodes

Self-update ended the process it was updating. Under systemd, the daemon re-launched itself as a detached child and exited 0. Exit 0 ends the unit, and systemd's control-group kill takes the detached child with it. The node was gone until someone noticed.
Nothing restarted a crashed node. infernet start detached one process with no supervisor. A crash, an OOM kill or a reboot was permanent.
Installs from git thought they were always out of date. The repo's package.json said 0.1.45 while npm was at 0.1.62, so those nodes reinstalled every 5 minutes, forever.
Nobody was told. No email, no status, nothing.

What changed (v0.1.62 to v0.1.64)

infernet setup now installs a systemd user unit on Linux (with linger, so it survives logout and reboot) or a launchd agent on macOS.
Without a service manager, infernet start runs a small built-in supervisor that restarts the daemon after a crash, with backoff.
One exit-code contract everywhere: 0 is a deliberate stop, 75 means "restart me into the new version", anything else is a crash.
Self-update checks that something newer actually landed before it restarts, and pauses for 6 hours if not.
If your node is linked to an account and goes silent for 24 hours, you get one email with the two commands that bring it back.

Aggregators now do something

The aggregator role used to just send heartbeats. Now an aggregator dials every advertised provider each minute, checks it answers as the node it claims to be, and reports reachability and round-trip time. The status page shows, per provider, how many aggregators reached it in the last hour. We run three (Buffalo, Buffalo, Vienna) and anyone can run one on a small box:

infernet init --role aggregator --name my-aggregator
infernet register
infernet setup --yes

On its first round it already caught a node advertising a port that belongs to something else.

See who is on the network

Every provider on infernetprotocol.com/status now links to a details page: coarse location (city, country, network; never the IP), hardware, live load, measured tokens per second, models served, job counts and success rate, recent jobs (never prompt content), and aggregator verification. Operators can hide a node from Settings.

Run a node

curl -fsSL https://infernetprotocol.com/install.sh | sh

It now stays up on its own. If you ran one before and it died, re-running that line brings it back on the new code.

Code: github.com/InfernetProtocol/infernet-protocol (PRs #51, #53, #54).

CoinPay checkout: one link, any coin or PayPal, and you always know who paid

chovy — Wed, 21 Oct 2026 14:45:46 +0000

CoinPay checkout: one link, any coin or PayPal, and you always know who paid

Most crypto checkouts make you pick the chain before the buyer ever sees the page. If you picked BTC and your buyer holds USDC on Solana, they leave.

CoinPay now has hosted checkout sessions. You create one with a single API call, send the buyer to the link, and they choose how to pay: every coin your business has a wallet for (BTC, ETH, SOL, USDC and USDT on several chains, DOGE, XRP and more) or PayPal.

Who paid, for what

Every session requires the buyer's email and your own account id, and records which site the payment came from. When the payment confirms, your webhook gets all three back with the usual event. No more "who sent this 12 USDC?"

One call

POST https://coinpayportal.com/api/checkout/sessions
Authorization: Bearer <your business API key>

{ "amount": 9, "currency": "USD",
  "description": "Pro, one month",
  "customer_email": "buyer@example.com",
  "account_id": "user_123",
  "property": "example.com",
  "success_url": "https://example.com/thanks?session={CHECKOUT_SESSION_ID}",
  "cancel_url": "https://example.com/pricing" }

You get back a url. The buyer picks a coin or PayPal there, and can switch coins while the payment is still open. The SDK has it too: createCheckoutSession() in @profullstack/coinpay 0.25.0.

Already running

We moved about 50 of our own sites to it this week: ugig, smshub, pairux, ThreatCrush, nixamp and the rest. We tested it end to end with real money on Base: the site had the purchase unlocked about 3 seconds after the transaction was mined.

Docs: https://coinpayportal.com/docs#checkout-sessions

Come post on our forums: the tsbb network is open

chovy — Wed, 21 Oct 2026 14:03:04 +0000

We build a forum package called tsbb, a bulletin board written in TypeScript. It looks like the vBulletin boards a lot of us grew up on, and under the hood it is a modern web app with no build step. We run a handful of boards on it, and right now they have more topics than members. That is backwards, so this is an invitation.

The boards

All of them are listed, with live topic and post counts, at tsbb.dev/boards:

tsbb.dev: the project's own board. Help, plugins, skins and what ships next.
bbs.hqtui.com: terminal UI talk, for people who build terminal UIs.
c0upons.com/bbs: deals, coupon codes and freebies, posted by whoever found them.
w3bs.org/bbs: the W3BS community board.

Joining takes one field. Type your email, click the link we send, and you are in. There is no password to choose, and you can add a passkey afterwards.

Why a forum, in 2026

Chat scrolls away. A thread on a board stays where you left it, has a URL, shows up in search and can be read by someone who arrives a year later. Every list on a tsbb board also has an RSS feed (each forum, each thread, each member, even a saved search), so you can follow a board from a feed reader without ever signing in.

What is in tsbb

No build step. The whole thing runs as plain TypeScript on Node 24, which is what makes runtime plugins possible: drop a directory in and it loads.
Plugins with filters, actions and slots, so a broken plugin cannot blank a page.
No client script. The board's CSP forbids inline script entirely; every page is complete as HTML.
Four ways in: the web, a terminal client (curl -fsSL https://tsbb.dev/install.sh | sh gets tsbb, tsbb-tui and tsbb-mcp), a REST API and an MCP server for agents.
Skins, from a 2000s vBulletin look to a paper skin that sits inside an editorial site.
MIT licensed, one Node process and a SQLite file (or Postgres).

Run your own, and get listed

Every tsbb board now has a /boards page listing every other board in the network, so each one sends readers to the rest. If you run a board, open a pull request adding it to apps/server/src/boards.json and it shows up on all of them. The list is also JSON at tsbb.dev/api/v1/boards.

Source: github.com/profullstack/tsbb

Come say hello. The first reply in any thread is yours.

We want 100,000 c0mpute nodes. We have fewer than 10.

chovy — Wed, 21 Oct 2026 13:35:17 +0000

c0mpute is the open compute network we have been building at Profullstack. Any machine can join it with one command, and once it is in, it serves AI inference, FFmpeg transcoding and storage jobs for whoever needs them. No account and no approval step, and you do not need to forward a port to join.

The number we care about is 100,000 nodes. Pooled spare capacity at that size is enough to train and serve open-weight models in the open, on hardware owned by the people running it. Today the best models come from a few labs that own their own data centers. A volunteer network will not beat them next year, and I am not going to pretend it will. But it does not have to win on day one to be worth building. It has to get big enough to matter.

Right now the live count is under 10 (7 this morning), and at least three of those are our own servers. That is the honest starting point, and the count is public at c0mpute.com/nodes, so nobody has to take my word for it.

Run one

curl -fsSL https://c0mpute.com/install.sh | sh

That installs c0mpute, plus infernet for inference and coinpay for payments, and starts the worker for you: a systemd service where it can, a background daemon where it can't. Then:

c0mpute worker status
c0mpute bench   # one full run puts a score next to your node on the board

It runs on Linux (x86_64 and arm64) and macOS, and on Windows inside WSL2. A GPU is detected and advertised if you have one, but it is not required. CPU nodes serve small models like qwen2.5:0.5b.

What you get

Paid inference goes through Infernet, the inference plugin that ships with c0mpute. Clients pay through CoinPay in 16 coins or with PayPal, and you choose where your share lands with infernet payout set <coin> <address>. Paid demand is early, so expect small and irregular earnings for now. I would rather say that than promise a number.

You also get a spot on the board. And if you bring people, give them https://c0mpute.com/r/<your-handle>: every node installed from that link shows your handle next to it. It is a scoreboard, not a payout.

What I fixed while testing this

Before writing this I ran the installer on a clean Ubuntu 24.04 container as a normal user, the way a stranger would. It took about two minutes, and it failed. The transcode step redirects apt-get to /dev/tty so sudo can prompt you, and with no terminal (ssh without -t, cloud-init, a container) that redirect fails before apt even runs. Because the installer runs under set -e and that call was the last command in an if body, the whole script exited with status 1 before it started the worker. So on exactly the kind of headless box that makes a good node, you got binaries and no node.

Now the package manager only gets the terminal when there is one, and a missing ffmpeg only turns off transcode jobs instead of the install. The installer also serves as text/x-shellscript now.

The code is MIT and on GitHub. If the installer breaks on your machine, open an issue with the output and I will fix it.