open specification · reference implementation · live pods

Your data belongs to you

Every app wants to become the place where your data lives. Your calendar is in one silo, your tasks in another, your notes somewhere else, and your AI memory inside whichever assistant you used last.

sempods takes the opposite route: put the data in a pod you control, describe it as structured linked data, and let apps, websites and agents come to it with permission. The pod is not just storage. It is where ownership, meaning and access control meet.

curl -X POST https://sempods.org/aaltra/_system/sparql/query \
  -H "Content-Type: application/sparql-query" \
  -H "Accept: application/sparql-results+json" \
  --data 'PREFIX schema: <https://schema.org/>
SELECT ?e ?name ?start WHERE {
  ?e a schema:Event ; schema:name ?name ; schema:startDate ?start
} ORDER BY ?start LIMIT 3'

The familiar pieces are deliberate. sempods is not trying to win by inventing a new database, query language, auth system or agent protocol. Its claim is that HTTP resources, RDF, JSON-LD, SPARQL, OAuth/OIDC and MCP become much more useful when they are fitted into one small pod contract.

One response, three claims

clients can change

+---------+   +----------+   +---------+
| apps    |   | websites |   | agents  |
+---------+   +----------+   +---------+
      \          |          /
       \         |         /
        v        v        v

        +----------------------+
        | your pod             |
        | data + meaning       |
        | grants + provenance  |
        +----------------------+

the data stays where ownership lives

The result is not another backend-as-a-service. It is a data layer for the open web: addressable by HTTP, readable as JSON-LD, queryable with SPARQL, and built so different implementations can speak the same contract.

That is a feature, not a compromise. A pod implementer should be able to reach for RDF stores, HTTP frameworks, OAuth libraries and existing SPARQL tooling, then spend the hard work on the contract: contexts as the permission boundary, server-enforced sandboxing, stable resource IRIs and, when the MCP module is present, an agent surface that does not bypass the rest.

The direction is close to the old promise of the web: decentralized, federated, linkable knowledge that no single product has to own. sempods is inspired by the same values as Solid, but takes its own route: semantic pods as a coherent stack rather than a private platform API.

Query a live podSee how it worksRead the specificationRead sempods-kotlin

AI should not own your memory

Ask an AI assistant what is happening in your life. It can reason impressively about public knowledge, but it does not know your plans, your community, your projects or your private history unless those things are copied into yet another product.

That is the wrong direction. An agent should not need to become the owner of your memory. It should be a client of your memory: reading the contexts you grant, writing to the contexts you allow, and losing access when you revoke the token.

In sempods, AI is not a privileged path through the system. It is a client like a web app or mobile app. What makes agents interesting is that they are powerful enough to navigate a personal or organizational knowledge graph instead of waiting for every integration to be built by hand.

For people, that points toward personal pods and real data sovereignty. For companies, the same model is already becoming interesting for knowledge management: structured knowledge, clear permissions, links between sources and AI access that can find the right answer without flattening everything into one new silo.

A specification, not a private platform API

sempods is being written as an open specification. The goal is not that everyone uses one hosted service. The goal is that many pod servers, apps and agents can work with the same model.

The specification is written and published: core chapters for contexts, grants, authorization, CRUD, SPARQL and find, optional modules beside them, and an OpenAPI description of the HTTP surface. Every normative statement carries an identifier, so it can be cited rather than paraphrased.

It is deliberately descriptive until 0.1 is tagged: where the text and the implementation disagree today, the implementation is right. sempods-kotlin is that implementation — the working server and client stack the specification was extracted from, and the thing it will bind first.

Some early product conversations are already happening around this knowledge management layer. They are not public announcements, and they should not be treated as customer claims. They are a useful signal: the personal vision becomes more plausible when independent teams adopt the open model for their own reasons.

Start with sempodsRead conceptsExplore use casesDiscuss on GitHub