Joshua Belke
de4cfec61e
Renames the product to Meridian across 1826 files: 24 crates (codebase-chat-* -> meridian-*), the Flutter package, env vars (CODEBASE_CHAT_* -> MERIDIAN_*), the deep-link scheme (meridian://), Postgres GUCs, Helm charts, skills, and the agent surface. White-labels every external identity onto self-hosted infrastructure: hosts move from *.codebase.design to *.meridian.r2d2.office.ilab.zone, images to registry.r2d2.office.ilab.zone/meridian-*, the repo slug to r2d2/meridian, and bundle IDs to zone.ilab.office.r2d2.meridian.*. The Block staging relay and the four Block-internal build repos are not reachable from a self-hosted deployment and are no longer referenced. The mark becomes a pixel M. It is 5x6 rather than a square 5x5 because the avatar-pile mask asserts the hole clears the glyph's right edge: at 5x5 that edge moves from 68.4% to 73% of the tile, which overruns the 56px team-card hole outright and leaves the other three piles under a pixel. At 5x6 the aspect is 0.833 against the retired C's 0.800, so all four masks clear it unchanged. All 59 materializations are regenerated from the generators; `just check-brand` passes. Four things are deliberately NOT renamed, because they match what was *stored* rather than what now ships. Rewriting any of them makes a migration no-op on exactly the installs it exists to repair: - Frozen migrations 0001-0030. Their SHA-256 digests are pinned in n-minus-one-pins.json and embedded in the attested N-1 image. The new vocabulary lands as forward migration 0031, which dual-reads all three generations' GUCs, lock names, app profiles and mesh d_tags. The push-gateway's own 0001 is likewise restored byte-identical, with 0002 widening its app_profile CHECK. - Legacy namespace chains. xyz.block.codebasechat.app is *prepended* to LEGACY_RELEASE_IDENTIFIERS and its dev/localStorage twins, per the rule in legacy_dirs.rs that a previous rename already broke once. - Bead IDs (codebaseChat-*), which are cited from commits and docs. - CHANGELOG history and upstream issue links. The Codebase-era persona ids are added to RETIRED_PERSONAS with their prompts verbatim, but deliberately NOT to RETIRED_PERSONA_REPLACEMENTS: that map drives migration::retire_agents, which deletes deployed instances, and its safety argument is that the successor is already deployed alongside. That held for Buzz->Codebase; nothing provisions a Meridian agent on an install that already onboarded, so mapping these would delete a working agent and leave nothing in its place. The brand-guard self-test changes axis: the M is symmetric about its vertical axis, so a mirrored M *is* the canonical M and asserting a rejection there would assert a bug. It now flips top-to-bottom (the mark reads as a W) and pins the horizontal symmetry so the coupling is visible if the mark ever becomes asymmetric again. Verified: cargo check --workspace --all-targets clean, just fix-all clean, flutter analyze clean, just check-skills pass, check-brand 59/59, brand-core 9/9, avatarPileMask 4/4, starter-avatar contrast 2/2. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>
4.5 KiB
🕸️ Meridian Mesh — Your community is your compute
A small team runs their project on one Meridian relay. Three of them have GPUs that sit idle most of the day — a gaming PC, a laptop, a workstation under a desk. One flips a toggle: Share compute. The others point their agents at it. Now the whole team's coding agents answer from a capable model running on hardware they already own. No API keys. No cloud bill. Every prompt runs inside the relay community they already chose to trust.
A Meridian community is a trust group. The people in it already know each other — that shared membership is a decision they've already made. Meridian Mesh turns that decision into shared AI compute: the idle GPUs scattered across your community become one pool, usable by every agent in the community, gated by the membership you already have. And because the pool is many machines, not one, the community can run models larger and more capable than any one member could load alone. More intelligence becomes reachable when the group works as a group.
Nothing here is new on its own. Pooling GPUs across machines is solved. Nostr identity is solved. Community-gated membership is how Meridian already works. The insight is that the tool that pools the GPUs already speaks the same protocol Meridian is built on — so the mesh's admission gate and your community's membership gate are the same gate. The boundary is the community, never the deployment: a community on shared infrastructure pools only its own members' compute, and a co-tenant community can't find it, join it, or serve to it.
Each piece is boring. The combination is the thing.
What You See
You open Meridian and flip on Share compute. Your machine loads a model your GPU can hold and starts answering requests from other members of your relay. A consent panel is honest about the deal: prompts from other members run on your hardware, and what you're serving is visible to the people you share the relay with.
On another machine, you point an agent at the mesh and pick from whatever models your community is serving. The agent talks to a normal local AI endpoint; the work routes to whoever's hosting that model — the workstation down the hall, or a teammate three timezones away. The agent neither knows nor cares which.
When an agent needs a model, Meridian helps it find a member machine already serving one: the relay coordinates the trust, the machines do the work, and the request runs directly between them — the relay never sees a token of it.
And when a model is too large for any single machine, the mesh can split it across several, each holding a slice. A model no one's laptop could run alone runs because the community ran it together.
Non-members see none of this. They can't find the mesh, can't join it, can't serve to it or use it.
Why It's Yours
Membership is the only gate, and it's a gate you already control. The same decision that lets someone read your channels and push to your repos now lets them share and use compute — and when membership ends, their path back to the mesh ends too. There is no separate access list to maintain, no new account, no new login. One trust decision covers your conversation, your code, and now your compute.
This is why it matters most for agents. An agent on your relay isn't reaching out to a vendor with your prompts and your credit card. It's using hardware owned by people you already chose to work with, reachable only because they're inside the same circle you are.
Honest Costs
Your prompts go to people, not a vendor. For a trust group that's a feature — far better than handing them to a stranger's cloud — but it is a different promise than "your data never leaves your machine," and the consent screen says so plainly. A community is only as private as its membership is trustworthy.
The mesh is opt-in, so it's only as capable as your community's participation. A relay where nobody shares compute has an empty mesh. That's the right default — you give willingly or not at all — but the value compounds with how many people turn it on.
These are honest costs. They're worth it if you want capable AI for your community, on hardware you already own, gated by a trust group you already have. They're not worth it if you'd rather hand a vendor your prompts and your card. Know which one you are.
The Point
The relay is the workspace. Meridian Mesh makes it the compute commons too.
Your community is not just where agents talk, plan, and leave records. It is where they can run.
Meridian — your community is your compute.