Relationship-specific by design
The Solid Databox is a hypermedia communications service: a secure data vault and exchange point operated for a declared program. Through it an organisation securely delivers records, receipts, credentials, warranty information and notices; the person returns submissions, corrections, claims, preferences or evidence. Every program relationship is a separate security domain—compartmentalised by design so that no single breach or authority collapses the whole picture of someone's life.
- Isolated security domains: each program relationship is cryptographically separate—no organisation, and no shared hosting provider, sees a graph of the person's other relationships.
- Auditable record lifecycle: accepted records are never silently overwritten—changes create linked, auditable events, and retention, correction and lawful deletion follow rules each program declares.
- Portable connections: a holder-bound connection credential scoped to one program, exchanged for short-lived access tokens—rotatable and revocable, never a reusable secret.
- Cryptographic receipts: every accepted deposit and submission produces a signed receipt the person keeps independently.
Explore the Web Civics Databox
Want the plain-language Databox guide? The Web Civics Databox site explains how it works for people, community groups, organisations and decision-makers. It includes a visual guide, an engine comparison, and a clear explanation of the Web of Data.
Two sides of one exchange
A databox relationship keeps two Solid data spaces, not one shared database. The organisation operates a relationship pod—its governed view of dealings with each counterparty: the records it issued, the submissions it accepted, and the policies and receipts that bind them. The other side holds their own pod—a Solid-compatible store they choose and control. There is no master copy of the relationship: the organisation is authoritative for what it issues; the counterparty is authoritative for what they submit and consent to.
An exchange is finished not when data arrives but when both sides hold proof of the same thing. Each party keeps the signed envelope, its provenance and its receipt, so either can later show exactly what passed between them—and a correction propagates as a governed, receipted event rather than a silent edit.
The other party's side
The counterparty connects through software they choose—for a person, a personal agent, vault or knowledge bank running against their own pod; for another organisation, its own Solid-compatible system. The connection credential it carries behaves like a program-scoped API key in persistence—no login for every sync—but is bound to keys the holder controls and cannot simply be copied. One vault can hold credentials for many relationships; none of them discloses the others.
Seraphim is the open-source reference agent for this side of the exchange—credential wallet, document capture, corrections, consent management and QR-based connection setup. Any conforming Solid application can fill the same role: the interface is the standard, not the app.
What it looks like in practice
The same pattern—governed exchange between two data spaces each party controls—repeats across very different relationships:
Cooperative projects
Contribution records, resource commits, role agreements and equity between participants move as governed records—each side holding proof of what was committed, delivered and compensated. This is the pattern behind the cooperative projects work.
Private health, better food
A person keeps health and dietary information in their own pod—it stays private. A local restaurant, supermarket or takeaway requests a scoped disclosure—an allergy, a dietary requirement, a nutrition goal—granted for that purpose alone, then ended. What makes it "precision" rather than preference is a shared evidence layer: a linked-data map connecting hundreds of normalised foods to their constituents, the human organ systems they may support, and graded evidence tiers—worked all the way down to practical menu items a kitchen can actually serve. The vendor's databox matches the scoped disclosure against that graph and returns better choices; the person's health record never leaves home. See the food & health evidence opportunity.
The evidence map is educational infrastructure, not medical advice—its own method sheet grades every claim and carries cautions and interactions for exactly that reason.
Governing participation
Membership, entitlements, delegated access and complaint routes—the relationship-governance machinery in the databox design—transposed to community-grounds needs: site agreements, concession verification, role credentials, and correction channels that produce evidence rather than arguments.
Care and dependants
Many people manage services for others who depend on their care—children, ageing parents, family members with disability. The design keeps the acting agent and the represented person distinct: a carer receives records, lodges submissions and manages entitlements for a dependant through delegated, visible and revocable authority—never by impersonating them (see care & guardianship).
Built on open standards
Solid and the Solid Databox are different things. Solid is the underlying open protocol work—led by Tim Berners-Lee and the W3C community—defining pods, identity and access control so that independent systems can interoperate. The Solid Databox is an implementation built on it: software that lets an organisation operate data relationships with agents—people, other organisations, software—that hold their own Solid pod or vault.
Underneath, it runs on W3C Solid-compatible data pods—the Linked Data Platform for storage, WebID and Solid-OIDC for identity, WAC/ACP for access control and Linked Data Notifications for delivery. Because Solid content is RDF, records can carry meaning in any shared vocabulary: ODRL for rights and duties, schema.org for everyday description, Web of Things and SOSA/SSN for devices and readings. Program URLs are opaque 128-bit identifiers carrying no customer information, and exchange is governed by an ODRL policy engine, a deposit and submission gateway with shape validation, and an append-only evidence ledger with signed dispositions.
The stack keeps two planes deliberately separate. A control plane (the Forge) onboards programs, validates each program's machine-checked institution profile, mints opaque relationship mappings and bridges records in from the organisation's existing systems—raw customer identifiers never reach a URL, a credential or a notification. The data plane is ordinary Solid: any conforming client exercises its granted access over standard HTTP and linked-data operations, with no proprietary transport.
It is designed for the edge: the open-source Solid-CSS-Databox stack runs in a container on the kind of Linux edge controller described on the digital economy page—working at a community ground or local council without depending on a cloud provider.
Governance and consumer rights built in
Beyond transport, the databox carries the machinery of accountable exchange. Automated systems may propose a record, but only a signed human attests to it; a record's sensitivity gates the assurance required of the current login, not merely account ownership; and every institutional actor is logged under a resolvable identifier. Outsourcing does not launder accountability—records name the delivering party and who remains responsible.
Consumer-rights workflows are first-class—access requests, correction requests with field-level tracking, data portability with a portability registry, and an append-only evidence ledger of all interactions—including lawful corrections and deletions. Versioned ODRL policies travel with each record class, so the rights, prohibitions and duties that governed an exchange—and the instrument that required them—can be established later, not asserted. An MCP (Model Context Protocol) server API lets authorised tools and agents work against the same governed surface rather than a parallel private integration.
The organisation's own stack
The databox is one module of a broader idea: an organisation running its own standards-based services on its own hardware. The same Solid-native module system—an opt-in layer on the Community Solid Server—carries domain and hosting setup, a public website, point-of-sale with receipts as verifiable records, payments behind a gateway-safe boundary, and connectors that bridge the databases and directories an organisation already runs. Every module stores its state as Solid resources, so the whole stack stays portable and degrades cleanly back to a vanilla pod.
A module system, not a monolith: a program enables only what it needs—bookings, inventory, concessions and entitlements, consent and delegation, emergency access, loyalty, provenance—each declared with capabilities and routes, and each tailored to a non-expert operator on modest hardware rather than a data centre. For the civics.au context, the concessions module is the obvious meeting point with the concession credentials work: entitlement management and programmable-grant settlement delivered through a governed, person-connected data vault.
Built for local operators
The databox is designed for the organisations enterprise software ignores: small businesses, community organisations and SMEs. It runs locally on a small server—a Mac mini or a small-form-factor PC—and serves its interfaces to whatever machines people already have, whatever operating system they run: Windows, Android, iOS, macOS or Linux.
Once built and customised it carries no subscription rent. Local tech-savvy consultants can tailor it to each business—the skills base described on the community IT support page—and every deployment becomes part of a local digital ecosystem offering an alternative to foreign, cloud-controlled subscription services. That keeps the money, and the community's digital agency, local.
Devices and the Web of Things
Physical devices join the same fabric as governed participants rather than vendor-cloud endpoints. A display, scanner, sensor or turnstile is enrolled in the relationship directory with its own WebID: a one-time claim URI lets a small on-device agent generate its keys and receive a certificate, after which it authenticates by mutual TLS with scoped, revocable, least-privilege access like any other agent.
Readings are described with W3C Web of Things Thing Descriptions and the SOSA/SSN sensor ontologies, so telemetry lands in the pod as standard RDF with time and context, streaming over Solid's own notification protocol. A device can hold append-only access—filing observations without the power to alter history. The same pattern covers a smart meter feeding a microgrid, a ticket credential opening a turnstile without exposing identity, and a printer accepting a purpose-limited licensed job.
Where it fits the ecosystem
Community grounds need trustworthy plumbing between people and programs: site agreements, concession verification, project contribution records, repair histories, receipts. The databox supplies that plumbing as open infrastructure the person controls. On the cooperative projects page the same evidence-ledger pattern appears as the resource-commit record; on the infrastructure page it is the software layer running on the edge databoxes.
The ecosystem exists to serve people, not the reverse. It depends on services that meet human needs—for individuals, and for those who depend on their care—and supplying the infrastructure those services run on is the purpose of the digital cooperative: shared local capacity for records, entitlements, care coordination and commerce that stays accountable to the people it serves.
The larger ambition is the knowledge bank: local datacentre infrastructure on which a town's organisations and its people each run their own data services—secure vaults and exchange systems, records, credentials, local applications—instead of renting them from remote platforms. Because every side speaks the same open standards, a regional community ground interoperates with agencies, businesses and systems internationally while keeping the data, the money and the community's digital agency local. It is groundwork for the digital transformation of a local socioeconomy, not just a better inbox. Working demos and the Forge admin console are linked from the project site.
Status: open-source reference implementation with in-browser demos (synthetic data). Production deployment still requires hosting, governance agreements and security review appropriate to the data it will carry.