SolidusPod

How it works

From a DID to an app reading your data

Four steps. Each one shows the actual output our code produces rather than an illustration of it — the address really is derived this way, and the access-control document really is what the share dialog writes.

  1. 01

    Sign in with a did:solidus

    Your pod address is not assigned, looked up, or stored — it is computed from your DID. The first twenty characters of the base36 form of SHA-256 of the DID. The same DID always produces the same address, on any machine, with no database in between.

    deriveSlug("did:solidus:example:0000-demo-did-for-docs")
    6cazw9rb8c0qr3a34j59

pod.solidus.network/6cazw9rb8c0qr3a34j59/
WebID: pod.solidus.network/6cazw9rb8c0qr3a34j59/profile/card#me

  2. 02

    The pod is provisioned

    Four containers are created: storage for files, credentials for verifiable credentials, inbox for messages other agents send you, and profile, which holds the WebID document that lets those agents find you at all.

    curl -H "Accept: text/turtle" .../<slug>/
    <> a <http://www.w3.org/ns/pim/space#Storage>, ldp:BasicContainer;
    ldp:contains <inbox/>, <README>, <storage/>, <profile/>, <credentials/>.

  3. 03

    Grant an agent access

    Sharing writes a Web Access Control document next to the resource. Access is per resource and per agent — not a folder-wide toggle, and not a link anyone holding it can use. The document below is the real output of granting one agent read access to one file.

    setAccess(doc, "https://example.org/profile/card#bob", { read: true, write: false })
    <../.acl#owner> a acl:Authorization;
    acl:mode acl:Read, acl:Write, acl:Control;
    acl:agent <../profile/card#me>;
    acl:accessTo <passport.pdf>;
    acl:default <passport.pdf>.

<#03be4165-68af-4629-955b-680e72a39a56> a acl:Authorization;
    acl:mode acl:Read;
    acl:agent <https://example.org/profile/card#bob>;
    acl:accessTo <passport.pdf>.

    The fragment name is a UUID regenerated on every grant, so the identifier differs each time — the shape does not. The owner rule is written when the resource is created; the second rule is the grant.

  4. 04

    An app reads it over LDP

    Any Solid client can now read what it has been granted, with an ordinary HTTP request and no integration with us. That is the whole point of the arrangement: the app talks to your pod, not to our API.

    curl -H "Accept: text/turtle" .../<slug>/storage/
    <> a ldp:Container, ldp:BasicContainer, ldp:Resource;
    dc:modified "2026-08-11T16:54:47.519Z"^^xsd:dateTime.
<passport.pdf> a ldp:Resource,
    <http://www.w3.org/ns/iana/media-types/application/pdf#Resource>.
<> ldp:contains <passport.pdf>.
<passport.pdf> posix:mtime 1786467287;
    posix:size 1048576.

Captured 2026-08-11 by running these paths against Community Solid Server on the same configuration production uses. The DID is a documentation value, not a real account.

The longer explanation: what Community Solid Server does, what we added, and why Read the full explanation

What this does not do

You can encrypt individual files in your browser, and that is off by default — an encrypted file is opaque to the other Solid clients the four steps above exist to serve, so it is a choice with a cost rather than a setting to leave on. The pod as a whole is not encrypted, for the same reason. Links do not expire, because Web Access Control has no expiry primitive. There is no mobile or desktop sync.

Create your podSolid compatibility
How it works — Solidus Pod