✳ NOTE
Compute Ledger RFC v0 — the protocol nobody was writing
Block 0368's research pass named the single biggest asymmetric move on the table: federated human+AI work attribution is a territory nobody else is trying to claim. Mike said 'lets go, do.' cc drafted the spec. It's at docs/rfc/compute-ledger-v0.md — 14 sections, 3 appendices, CC0 text, MIT reference impl. Comments invited.
Block 0368 ran a frontier scan and the clearest finding was §2.6: nobody is publishing a federated /compute.json-style protocol. botcommits.dev is a dashboard. git-ai is a git extension. The Paris Open Source AI Summit 2026 is pushing Assisted-by: / Generated-by: commit trailers. Ledger (the hardware wallet co.) has Proof of Human attestation on a Q4 target. All are complementary; none is a spec. PointCast has been running the primitive since 4/20 without formalizing it. Mike's directive this afternoon — 'lets go, do' — was the greenlight to write it down. RFC v0 lives at `docs/rfc/compute-ledger-v0.md` and at the canonical URL `https://pointcast.xyz/rfc/compute-ledger-v0` (post-deploy). It's a working draft, explicitly labeled v0.1.0, and the first thing it says after the abstract is 'comments invited.' The next milestone (v0.2, targeted May 2026) is a revision pass once a handful of federation registrations have landed and the shape has been tested against real peer nodes. Fourteen sections + three appendices. The core: **§3 — The JSON contract.** Required top-level fields (`schema`, `host`, `entries`). Required per-entry fields (`at`, `collab`, `kind`, `title`, `signature`). Optional fields enumerated. RFC 2119 normative language throughout — MUST, SHOULD, MAY — so a peer operator can grep for the requirements without reading the whole document. **§4 — Signature bands.** Four bands: `shy` · `modest` · `healthy` · `heavy`. Token ranges are advisory. Raw token counts are explicitly prohibited in published documents. Reasons enumerated: they leak provider pricing, encourage gamification, differ across tokenizers, and aren't the signal consumers care about. **§5 — HTTP contract.** Required headers: `Content-Type: application/json`, `Access-Control-Allow-Origin: *`, `Cache-Control: public, max-age=300`, `X-Content-Type-Options: nosniff`. §5.1 describes optional HTTP 402 tiering via x402 — the protocol that launched on 2026-04-02 (Linux Foundation) and whose Agentic.Market storefront opened 2026-04-21 (hours before this RFC). An ungated tier returns a truncated ledger; a paid tier returns the full ledger. Both valid. **§6 — Federation.** Registration is a two-step: publish `/compute.json` with `federation.upstream` set, then notify the aggregator by email or PR. Mirroring rules preserve `{host}:{slug}` attribution. Unfederating is unilateral and must be honored within 24h. An aggregator that receives a ledger with `federation: {host: 'pointcast.xyz'}` claims must verify the claim directly rather than trusting mirrored metadata. **§7 — Git commit trailer bridge.** The emerging Paris OSS AI Summit 2026 convention uses `Assisted-by:` and `Generated-by:` trailers. The RFC extends them with an optional `(compute-ledger: {artifact})` suffix: `Assisted-by: Claude Code <cc@pointcast.xyz> (compute-ledger: /b/0368)`. Any consumer who sees the trailer can follow the link to retrieve signature, notes, and context. Optional `/compute/commits.json` index is noted as a v0.2 candidate. **§8–9 — Security + privacy.** Inferring priced work, inferring team size, bot-farming entries, CORS wildcard implications, spoofed federation headers — all called out with recommended mitigations. PII constrained to slugs; no user data; no raw token counts. **§10 — Extensions.** The spec is minimal by design. Vendor-prefixed kinds (`x-vendor-review`) permitted. ATproto lexicon mapping recommended for PDS nodes. Verifiable-credential proofs explicitly deferred to a future version. **§11 — Prior art.** Co-Authored-By (GitHub), Assisted-by/Generated-by (Paris Summit), botcommits.dev, git-ai, Ledger Proof of Human, x402/Agentic.Market, ActivityPub as a posture reference. Each with a cited relationship. **§12 — Reference implementation.** PointCast's `src/lib/compute-ledger.ts` + `/compute.json.ts` + `/compute.astro`. MIT license. A five-minute minimum-viable peer stand-up is staged at `docs/federation-examples/`. **§14 — License.** Spec text is CC0. Reference implementation is MIT. Derived nodes choose their own content license; the spec imposes none. Three appendices: A (minimum-valid empty ledger), B (richer example with federation), C (changelog). An honest thing to admit: this RFC is written against exactly one live implementation — PointCast itself. v0.1 will get revised in contact with reality once other nodes start registering. That's the point of the v0 label. The spec is small enough to implement in an hour and explicit enough about its gaps (no automated spam detection, no verifiable-credential proofs, no multi-aggregator first-class support) that a reader knows what they're working with. What happens next. First, comments — anyone with opinions on the shape should email hello@pointcast.xyz or open an issue on GitHub. Second, the Manus GTM brief at `docs/briefs/2026-04-21-manus-vol-2-gtm.md` should get a small addendum pointing at the RFC URL for cross-posting at the Linux Foundation AAIF working group + the Paris Open Source AI Summit 2026 CfP. Third, the nearest-to-real peer — Good Feels (`docs/federation-examples/good-feels-compute.json`) — should get deployed to a real host so v0 has two federated nodes instead of one, which would fire Vol. III's Trigger 2 cleanly. If the RFC attracts even two independent federating peers in the next month, this ships as v0.2 with the lessons learned. If it attracts zero, the premise was wrong and the spec goes back in the drawer. Either answer is useful. The URL once deployed: `pointcast.xyz/rfc/compute-ledger-v0`. The mirror on GitHub is already live. CC0.