Neighbors, Not Tenants: How Towns Can Mesh Their Mini Data Centers
The open-source stack for linking independent data centers is further along than most towns realize — and the gap that’s left is exactly the one worth building in.
Every town hall conversation about a community-owned node arrives at the same question, usually about forty minutes in, usually from someone who runs IT for the school district:
“Fine. We own the box. But the county next door owns theirs. How do our two systems talk to each other without us both signing up for Amazon?”
It’s the right question, and for years the honest answer was a shrug and a research grant. That’s changed. The plumbing for organizations to federate their infrastructure — to share data across institutional lines while each side keeps physical custody of its own hardware — is not a thought experiment anymore. Part of it is on an internet standards track.
Here’s what actually exists, what it does, and where the real gap is.
The sharing layer: a vendor API that grew up
The most useful development is one almost nobody outside research computing has noticed, and its history is the whole argument in miniature.
Open Cloud Mesh (OCM) is a server-to-server protocol that lets a user on one system grant a user on a different system access to a file — without the recipient making an account on the sender’s server, and without the file leaving the sender’s storage.
It started life in 2015 as ownCloud’s Federated Cloud Sharing API: one company’s feature. It then became the GÉANT-hosted Open Cloud Mesh initiative, picked up serious momentum from the European research-computing community — CERN and a constellation of universities who needed cross-institution collaboration where no institution surrenders custody — and in 2026 it has an IETF working group of its own, chartered in the Applications and Real-Time area under chairs Lisa M. Dusseault and Thibault Meunier.
The active Standards Track draft, draft-ietf-ocm-open-cloud-mesh, reached revision 06 on 19 July 2026. Its authors are Giuseppe Lo Presti of CERN, Michiel B. de Jong, Mahdi Baghbani of Ponder Source, and Micke Nordin of SUNET, the Swedish research network. The working group’s milestone is to request publication by 31 December 2026.
That trajectory — vendor feature, to consortium project, to internet standard — is the thing to notice. A vendor API can be deprecated the week its owner gets acquired. OCM very nearly was that story. An IETF standard is a public commitment that outlives any one company, which is the whole point when you’re asking a school board to sign off on infrastructure for fifteen years.
Three things the charter is explicit about, worth knowing before you plan around it:
- The transfer isn’t OCM’s job. The protocol covers share and invitation flows, data models, trust mechanisms and share management — but the bytes move over established protocols like WebDAV. OCM deliberately doesn’t reinvent that.
- Identity federation is out of scope. If you want single sign-on across your mesh, that’s a separate problem with separate tools (OIDC, SAML, or OpenStack’s Keystone).
- So is establishing trust where none existed. OCM assumes the parties already have a relationship. That’s not a weakness — it’s an accurate model of how a county, a library system, and a school district actually relate to each other.
Who speaks it: Nextcloud ships federated sharing out of the box and its founders wrote the original API. CERNBox has been leading recent standards work, including the Sovereign Tech Agency–funded Directory Service and discovery effort. ownCloud Infinite Scale — now under Kiteworks, which in May 2026 stood up an open-source program office and replaced its CLA with a DCO — implements federated sharing as well.
There’s also OpenCloud, founded in September 2024 by Berlin’s Heinlein Group and launched publicly on 22 January 2025, built on the Infinite Scale codebase with a number of former ownCloud engineers. If governance independence matters to you it’s worth a look — but do your own diligence first: German trade press reported that ownCloud’s owner threatened legal action over the departure. Read that thread to its end before you standardize on either one.
The storage layer: pooling hardware across owners
Below the sharing layer sits the question of the disks themselves.
Ceph is the workhorse. It’s a software-defined distributed storage platform whose RADOS Gateway implements a large subset of the S3 API — meaning tools written for Amazon largely work against it unmodified. Its multi-site replication lets geographically separate clusters mirror each other. Ceph is what CERN and a long list of universities and public agencies actually run at petabyte scale. If your mesh needs object storage that commercial software already knows how to talk to, this is the default answer.
OpenStack is the full private-cloud control plane — compute, networking, and storage. Its Keystone service federates identity across institutional boundaries, including keystone-to-keystone federation, which is precisely the piece OCM leaves out. Governance note: the Open Infrastructure Foundation announced its intent to join the Linux Foundation in March 2025 and completed the move on 3 June 2025, bringing a community it describes as 110,000 people across 187 countries under the same roof as the kernel. For a town evaluating fifteen-year bets, foundation stability is not a footnote.
Ubicloud is the newer, lighter-weight option — a Y Combinator (W24) company with $16M in seed funding building an open-source control plane that runs on bare metal from multiple independent providers. It’s less battle-tested than OpenStack and considerably less work to stand up. For a small mesh that wants portable cloud primitives without a dedicated ops team, it’s a real contender.
The trustless layer: when you don’t know your peers
IPFS and Filecoin, and Storj, solve a different problem: distributing data across nodes run by strangers, with cryptography rather than institutional trust doing the work.
Be honest about the fit. A mesh of neighboring municipalities, libraries, and school districts is a high-trust network with real legal agreements between named parties — exactly what OCM and Ceph assume. Zero-trust protocols are engineered for the opposite case, and you pay for that in complexity, latency, and a set of token-economics questions your municipal attorney will not enjoy. Reach for these when you actually need trustless durability, not because “decentralized” sounds like it should mean the same thing you mean.
Worth noting where this is heading, though: Storj now sells GPU capacity for AI training and inference alongside its storage product. The distributed-storage players can see the same gap described below, and they are moving into it.
The stack at a glance
| Layer | Tool | What it federates | Fit for a municipal mesh |
|---|---|---|---|
| Sharing | Nextcloud / OpenCloud / ownCloud Infinite Scale | Access to files across servers (OCM) | Start here. Weeks, not years. |
| Storage | Ceph | Object storage, S3-compatible, multi-site | The durable foundation. |
| Control plane | OpenStack | Compute, network, storage + identity (Keystone) | Powerful; needs real ops staff. |
| Control plane | Ubicloud | Cloud primitives on bare metal | Lighter lift, younger project. |
| Trustless | IPFS / Filecoin / Storj | Storage across untrusted peers | Only if you need it. Usually you don’t. |
| Inference | see below | Partial, and none of it municipal | The open problem. |
The gap, stated precisely
Here’s the part worth being careful about, because the sloppy version of this claim is easy to make and easy to disprove.
The sloppy version is “nothing federates AI compute.” That’s false, and a well-read skeptic will say so within a minute. What’s actually true is narrower and, I’d argue, more interesting:
No vendor-neutral standards effort yet defines federated AI inference across independent operators — with metering, attestation, routing, and settlement — at a scale a county can deploy and govern.
Everything in that sentence is doing work. Here’s what exists and why each piece stops short:
- IETF CATS (Computing-Aware Traffic Steering) is a chartered working group doing genuinely relevant work: steering traffic to the best of several geographically distributed compute sites based on computing-resource metrics. It’s the closest thing to what a mesh needs. But its charter states the WG “will focus on single domain models” — one administrative domain. Cross-operator is explicitly not the problem it’s solving.
- llm-d — Kubernetes-native distributed inference, backed by Google Cloud, IBM, Red Hat, NVIDIA and CoreWeave, accepted into the CNCF Sandbox in March 2026. Real, well-funded, and scoped within a cluster you control, not across clusters other people control.
- KServe’s Open Inference Protocol (V2) is a genuine multi-vendor inference API implemented by Triton, Seldon, TorchServe and OpenVINO. So the API shape problem is largely solved. What remains unsolved is everything around it: who pays, who verifies, who routes.
- The Linux Foundation’s Tokenomics Foundation, launched 3 June 2026 with the FinOps Foundation and backers including Google Cloud, IBM, Microsoft, Oracle and SAP, is standardizing how AI token consumption is measured and costed. That’s the metering-and-pricing half of the problem being worked in the open — by hyperscalers, for hyperscale economics.
- GSMA Operator Platform and ETSI MEC 040 actually do define federating edge compute across independent operators, including discovery, onboarding and charging. This is the closest existing analogue to what a municipal mesh needs — and it’s built for telcos, by telcos, at telco scale and telco complexity.
- EGI Federated Cloud federates real compute, including GPUs, across independent European institutional providers using OpenStack APIs plus EGI Check-in for SSO. It works today. It also assumes you’re a research institution inside a decades-old grid-computing collaboration.
- Akash, io.net, Bittensor, Prime Intellect and Storj’s GPU product all sell decentralized inference commercially. Several are open source. None is a vendor-neutral standard, and none is governable by a city council.
Read that list and the shape of the gap comes clear. It isn’t that the problem is unexplored. It’s that every serious effort is scoped to a single administrative domain, or to telcos, or to research grids, or to a company’s own marketplace. Nobody has assembled the version a county of 40,000 people can deploy, afford, audit, and govern — and the pieces that would compose into it are being designed right now by people optimizing for very different constituents.
That’s not a reason to wait. It’s the opposite. The storage and sharing layers are solved well enough to build on today — a library, a school district, and a city IT department can stand up federated Nextcloud over Ceph this quarter and be genuinely useful to each other by spring. The compute layer is where the defaults are still being set, which means the communities that show up now are participants in that decision rather than recipients of it.
That’s the DataMesher thesis in one line: the bridges are being built right now, and it matters enormously whether they get built as public infrastructure or as somebody’s moat.
What to do with this
If you’re the person in the room who gets asked the interoperability question:
- Start with the sharing layer. Federated Nextcloud between two willing institutions is a weekend, not a program. It proves the concept to the people who control budgets.
- Ask vendors one question: “Do you implement Open Cloud Mesh?” The answer tells you whether you’re buying a bridge or a moat.
- Don’t buy the trustless stack because it sounds more decentralized. Match the tool to the trust model you actually have.
- Watch CATS and the Tokenomics Foundation. They’re building the routing and metering primitives. Whether those primitives work across independent operators is still an open question — and open questions can be influenced.
- Treat the compute gap as an opportunity. A town standing up a node now is not a late adopter of a finished thing. It’s an early participant in an unfinished one.
Working on this in your own community? I’d rather hear what’s happening in your town than talk. Grab a slot.
Sources
- IETF Open Cloud Mesh working group charter
- draft-ietf-ocm-open-cloud-mesh-06 (19 July 2026)
- Kiteworks launches the ownCloud open source program office (May 2026)
- OpenCloud, founded by the Heinlein Group
- Ceph Object Gateway (RADOS Gateway)
- OpenStack Keystone identity federation
- OpenInfra Foundation completes its move into the Linux Foundation, 3 June 2025
- Ubicloud
- IETF CATS (Computing-Aware Traffic Steering) working group charter
- EGI Federated Cloud compute documentation
