Practical Guide -- W3C Solid Protocol

How to Use Solid

Three entry points: as a human creating content, as a developer building AI agents, or as a person using AI agents who wants to stay in control of what they do on your behalf.

What is a Pod?

A Pod is your personal data store on the web -- a place you control, that runs at a URL you own, where your content and data live independent of any platform. Think of it as your own personal server, but with a standard interface so any Solid-compatible application can interact with it.

When you post content using Solid, the content lives in your Pod. You decide who can read it, who can comment on it, and which platforms or applications can display it. When you leave a platform, your content stays with you.

Why Solid for Content Creators? Creator

The current model: you write on Medium, Substack, or LinkedIn. They host your words. Their algorithm decides who sees them. If they close, change terms, or shadowban you, your audience and your archive are at risk.

The Solid model: you write once, store in your Pod, and syndicate to any platform that supports Solid -- or publish directly at your own URL. Your canonical content is yours. Platforms become display layers, not owners.

Practical note Solid does not replace platforms today -- the ecosystem is still maturing. What it gives you now is a sovereign archive and the ability to selectively share from it. Think of it as future-proofing your publishing infrastructure.

Set Up Your Pod Creator

01

Choose a Pod provider

The easiest starting point is solidcommunity.net (free, run by the Solid community) or inrupt.net (Inrupt's hosted service). For full control, you can self-host Community Solid Server (CSS) on any VPS.

02

Register and get your WebID

After registration you get a WebID URL -- something like https://yourname.solidcommunity.net/profile/card#me. This is your sovereign identity on the Solid web. Keep it. It is permanent and portable.

03

Explore your Pod with Penny

Penny (penny.vincenttunru.com) is a visual Pod browser. Log in with your WebID, browse your containers, create folders, upload files, and set access rules -- no code required.

04

Understand the structure

Your Pod is organised like a file system. Containers are folders (URLs ending in /). Resources are files. Create a /public/ container for content you want openly accessible, and a /private/ for personal notes.

Post Content to Your Pod Creator

You have three options depending on your comfort level:

Option A -- Use a Solid-native editor (no code)

Mashlib (the data browser at solidcommunity.net) lets you create notes, blog posts, and structured documents directly in your Pod through a web interface. Solid Focus is a task and note app that writes to your Pod. These are early-stage tools but functional.

Option B -- Upload files via Penny

Write your content in any editor, save as HTML or Markdown, then upload to a container in your Pod using Penny. Set the access rules to public. Your content is now live at a permanent URL like https://yourname.solidcommunity.net/posts/my-article.html.

Option C -- POST via curl (one command)

If you are comfortable with a terminal, you can publish a file directly:

bash -- publish a file to your Pod
# First get an access token (see authentication section) curl -X PUT \ -H "Content-Type: text/html" \ -H "Authorization: Bearer YOUR_TOKEN" \ --data-binary @my-article.html \ https://yourname.solidcommunity.net/public/posts/my-article.html

Control Who Sees Your Content Creator

Every resource and container in your Pod has an Access Control List (ACL) or Access Control Policy (ACP). You set these rules -- not the platform.

Access LevelWhat it meansUse for
Public readAnyone on the web can readPublished articles, portfolio
Specific WebIDOnly named individualsShared drafts, subscriber content
AuthenticatedAny logged-in Solid userCommunity content
PrivateOnly youNotes, drafts, personal data
Append-onlyOthers can add but not editComment streams, audit logs

In Penny: navigate to any resource, click the lock icon, and set permissions visually. Changes take effect immediately.

Tools for Content Creators Creator

ToolWhat it doesURL
PennyVisual Pod browser and file managerpenny.vincenttunru.com
MashlibData browser built into solidcommunity.netsolidcommunity.net
Solid FocusNotes and tasks stored in your Podgithub.com/NoelDeMartin/solid-focus
Startin'BloxBuild Solid-native web apps without codestartinblox.com
CSS (self-host)Run your own Pod servergithub.com/CommunitySolidServer

Why Integrate Your Agent with Solid? Developer

Autonomous agents -- systems that act persistently on behalf of users across platforms -- create a structural accountability problem: what did the agent do, with what authorisation, and where is the record? Without an answer to these questions, your agent is a liability for your users and for you.

Solid gives you a ready-made answer: every agent action can be written to the user's Pod as a linked data record, under access controls the user sets, in a store the agent cannot tamper with retrospectively. This gives you audit trails, consent management, and revocation -- for free, on open standards.

Authentication Developer

Solid uses Solid-OIDC -- an extension of OpenID Connect where the user's Pod is the identity provider. Your agent authenticates using the user's WebID credentials, not a username/password in your database.

Using @inrupt/solid-client-authn-node

javascript -- agent authentication
import { Session } from "@inrupt/solid-client-authn-node"; const session = new Session(); // Authenticate using client credentials // (user grants your app a client ID during onboarding) await session.login({ oidcIssuer: "https://solidcommunity.net", clientId: process.env.CLIENT_ID, clientSecret: process.env.CLIENT_SECRET, }); // session.fetch is now an authenticated fetch // Use it exactly like the standard fetch API const response = await session.fetch(podUrl);
Key principle Your agent never stores the user's password. It holds a client credential that the user can revoke from their Pod settings at any time -- without touching your application.

Read Data from a Pod Developer

javascript -- read user data from Pod
import { getSolidDataset, getThing, getStringNoLocale } from "@inrupt/solid-client"; import { FOAF } from "@inrupt/vocab-common-rdf"; // Read user profile from their Pod const profileUrl = "https://user.solidcommunity.net/profile/card"; const dataset = await getSolidDataset(profileUrl, { fetch: session.fetch // authenticated fetch from login step }); const profile = getThing(dataset, profileUrl + "#me"); const name = getStringNoLocale(profile, FOAF.name); console.log(`Hello, ${name}`);

Write Data to a Pod Developer

Writing creates or updates a resource in the user's Pod. Use saveSolidDatasetAt for structured linked data, or a plain PUT for files.

javascript -- write structured data to Pod
import { createSolidDataset, createThing, setStringNoLocale, setDatetime, setThing, saveSolidDatasetAt } from "@inrupt/solid-client"; import { SCHEMA_INRUPT } from "@inrupt/vocab-common-rdf"; // Create a new record -- e.g. a calendar event let event = createThing({ name: "appointment-2026-03-11" }); event = setStringNoLocale(event, SCHEMA_INRUPT.name, "Meeting with collaborator"); event = setDatetime(event, SCHEMA_INRUPT.startDate, new Date("2026-03-11T14:00:00Z")); let dataset = createSolidDataset(); dataset = setThing(dataset, event); // Save to user's Pod await saveSolidDatasetAt( "https://user.solidcommunity.net/calendar/2026-03-11.ttl", dataset, { fetch: session.fetch } );

Audit Logging for Agent Actions Developer

This is the critical pattern for safe agent architecture: every action your agent takes is written to the user's Pod before execution, as an append-only record. The user's ACL on the log container is set to append-only for the agent -- meaning the agent can add records but cannot modify or delete them.

javascript -- write action to audit log before executing
async function logAndExecute(action, podUrl, session) { // 1. Build the audit record const logEntry = { "@context": "https://schema.org/", "@type": "Action", "name": action.description, "target": action.target, "instrument": "OpenClaw/1.0", "startTime": new Date().toISOString(), "actionStatus": "PotentialActionStatus", // pre-execution "agent": { "@type": "SoftwareApplication", "name": "MyAgent" } }; // 2. Write to Pod BEFORE executing const logUrl = `${podUrl}agent-logs/${Date.now()}.json`; await session.fetch(logUrl, { method: "PUT", headers: { "Content-Type": "application/json" }, body: JSON.stringify(logEntry) }); // 3. Execute the action const result = await action.execute(); // 4. Update log with outcome (append new record, don't modify old) await session.fetch(`${podUrl}agent-logs/${Date.now()}-result.json`, { method: "PUT", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ ...logEntry, actionStatus: "CompletedActionStatus", result }) }); return result; }
Set append-only ACL on the log container The agent's WebID should have acl:Append permission on /agent-logs/ but NOT acl:Write or acl:Control. This means the agent can add records but cannot modify or delete them. The user retains full control.

Why You Need a Pod if You Use AI Agents User

If you use an AI agent -- any system that acts autonomously on your behalf, reading your email, sending messages, managing your calendar, browsing the web -- you have a problem you may not have noticed yet: you probably have no reliable record of what it did.

The agent's logs, if they exist, live on the developer's servers. You cannot read them independently. You cannot verify them. If something goes wrong -- an email sent you didn't authorise, a message posted in your name, a file deleted -- you have no sovereign evidence of what happened.

A Solid Pod gives you that. It is a place on the web that you control, where a well-built agent writes a record of every action it takes on your behalf, before it takes it. You can read that record. You can audit it. You can revoke the agent's access at any time.

The honest situation Most AI agents today do not yet support Solid. But the architecture is available, the specification is open, and asking your agent developer whether they support Pod-based audit logging is a legitimate question that creates pressure to build it.

Set Up Your Pod User

01

Go to solidcommunity.net

Click Register. Choose a username. This becomes your WebID -- your permanent, portable identity. Write it down: https://yourname.solidcommunity.net/profile/card#me

02

Log in and explore your Pod

You will see a data browser (Mashlib). Your Pod already has some default containers. You can browse, create folders, upload files. Think of it as a personal Dropbox where you set all the access rules.

03

Create an agent-logs container

In the data browser, create a new container (folder) called agent-logs. This is where you will ask agents to write their action records. Keep it private to yourself and append-only for agents.

04

Create a consent container

Create a container called consent. This is where you store records of what you have authorised each agent to do. A well-built agent will check here before acting on your behalf.

Grant an Agent Access to Your Pod User

When you connect an agent to your Pod, you are giving it a WebID credential -- a key that lets it read or write specific containers. The key principle: grant the minimum necessary access.

ContainerAgent permissionReason
/agent-logs/Append onlyAgent can write logs but not modify or delete them
/consent/Read onlyAgent reads what you authorised; you write consent records yourself
/calendar/Read + AppendAgent can read and add events; cannot delete
/private/NoneAgent has no access to your private notes
/public/Read onlyAgent can read public content but not post on your behalf without explicit consent

In Penny or the Mashlib data browser: navigate to the container, open its access settings, add the agent's WebID, and set the permission level. Changes take effect immediately.

Read Your Agent's Audit Log User

If your agent is writing to /agent-logs/, you can browse those records at any time in Penny or the Mashlib browser. Each record should tell you: what action was taken, when, against what target, and what the outcome was.

What to look for:

--

Actions you did not authorise

Any action type not listed in your /consent/ records. If you see it in the log, the agent acted outside its authorised scope.

--

Unusual targets

Actions directed at people, accounts, or services you do not recognise -- a possible sign of prompt injection (the agent was redirected by malicious content it processed).

--

Gaps in the log

If the agent took actions but did not log them, that is itself a finding worth raising with the developer.

Revoke Agent Access User

This is the most important capability Solid gives you. Revoking an agent's access to your Pod does not require contacting the developer, deleting an account, or changing passwords. You remove the agent's WebID from your Pod's ACL. The agent loses access immediately -- to everything you granted, across all containers.

01

Open Penny or Mashlib

Navigate to any container where the agent has access.

02

Open access settings

Find the agent's WebID in the access list.

03

Remove all permissions

Delete or set to none. The agent's key is now invalid. Any subsequent request it makes to your Pod returns 403 Forbidden.

Important Revoking Pod access does not revoke access the agent has to external platforms (email, WhatsApp, etc.) through other credentials. Those must be revoked separately through each platform. Solid controls only the agent's access to your Pod.