Thats a good idea to accept links to that JSON doc that… did not occur to me for some reason.

And yeah, the ATProto stuff is VERY much “public data, shared discovery” vs “permissioned data, locally discoverable” of Solid. Getting them to play nicely with each other only works for Public data, but the idea of “bring your own ID and store your own data” is a common ground between them.

I’ll add the client id json parser, then your apps could be on there easy!

For developers , programme highlights include:

1. Spotlight talks featuring Dokie.li and Nextgraph, led by Virginia Balseiro, Sarven Capadisli and Niko Bonnieure.

2. Authorizing Solid Applications and related Security Considerations led by elf Pavlik.

3. From Apps to Autonomy: Operating Systems for True Data Ownership featuring the work of Angelo Veltens and Timea Turdean.

4. Solid POP session: Proof of aPplication, the proof is in the eating, led by Sjoerd van Groning.

For business leaders interested in Solid, highlights include:

1. Practical uses of Solid for medical and health data led by Jackson Morgan, Dominique Van Dijck, Elfi Goesaert, and Erich Bremer.

2. Shaping the business value of trust and innovating the business models of Solid organised by Elfi Goesaert, Bart Buelens, and Jeremy Caine.

3. Achieving adoption of Solid at scale led by Jesse Wright.

4. Panel discussions on the Next Chapter for Solid featuring John Bruce and Louise Burke.

Academics are treated to dozens of high-quality contributions spread across:

1. 4th Privacy & Personal Data Management Session chaired by Beatriz Esteves and Marc Florea.

2. Decentralised Information Retrieval and AI based on Solid chaired by Thanassis Tiropanis, George Roussos, and George Popescu-Craiova.

3. Solid Future(s) for Digital Heritage: Decentralising Access and Building Trust led by Milena Dobreva and Pavel Kats.

4. Solid4FutureProtocols: Using Solid to Enable Future Application Protocols led by Biagio Boi and Franco Cirillo.

5. The Solid Symposium Poster Session chaired by Christoph Braun, Juan G. Diaz Ochoa, Chang Sun, and Rui Zhao.

Keynotes include, on the morning of 1 May, Oshani Seneviratne on “Federated Learning Meets Solid: Privacy-Preserving Personalization with Federated LLMs and Solid Pods.”

The opening day on 30 April begins with a keynote from Sir Nigel Shadbolt and an introduction to the ODI’s roadmap for the Solid technology. The day concludes with a fireside conversation with Sir Tim Berners-Lee , whose leadership in the context of the Solid project needs no introduction on this forum. There will be plenty of opportunities to discuss Solid in breaks and in the evenings . For more details on the program see the symposium website.

Register in March for a discount here!

Thank you to the dynamic program committee, local organisers, and sponsors (Muze, The ODI, and Inrupt) who make the symposium possible.

I’ve also been curious about ATProto for a while, but as far as I know you can only store public data in PDSes, right? In Solid, you can have both public and private data, but I think it’s more common to have private data (at least with the apps I’ve seen), so I’m not sure about that idea of bridging both… But it’s interesting, keep us updated on that.

About application listings, in Solid there is also another way that is pretty common to declare applications, in fact it’s a requirement for logging in sometimes. That is called the “client id”, and it’s a document similar to web manifests for PWAs. I’m not sure there is any way to auto-discover them (they aren’t usually linked in the header or anywhere that I know), but if you get the link, they are a pretty good document to describe the app.

Here’s a couple of links to my apps’ client ids:

• https://focus.noeldemartin.com/clientid.jsonld
• https://umai.noeldemartin.com/clientid.jsonld

Right now there are two ways to add a listing;

1. JSON-LD blob on your apps homepage
2. ATProto record on your PDS

I’m working towards a third that works like #2 for solid folks;
3. RDF statemetns on your Solid POD

I would love to see some more Solid apps on here. What do you y’all think about the project and the idea?

<spec-statement id="payload-context-uri"> A Payload document serialized as application/ld+json MUST include "@context": "https://ujg.specs.openuji.org/ed/context.jsonld". </spec-statement> 

<spec-statement id="context-definition"> The JSON-LD context document identified by https://ujg.specs.openuji.org/ed/context.jsonld MUST be equivalent to the JSON-LD context defined in [=jsonld-context=]. </spec-statement> 

<def id="jsonld-context" as="pre" lang="jsonld"> { "@context": { 

 "@version": 1.1,
 "@vocab": "https://ujg.specs.openuji.org/ed/ns/core#",

 "specVersion": "https://ujg.specs.openuji.org/ed/ns/core#specVersion",
 "imports": {
 "@id": "https://ujg.specs.openuji.org/ed/ns/core#documentImports",
 "@type": "@id",
 "@container": "@set"
 },
 "nodes": {
 "@id": "https://ujg.specs.openuji.org/ed/ns/core#documentNodes",
 "@container": "@set"
 }

} } </def>

a resulting json-ld describing this as knowledge graph would be:

 {
“@context”: {
“dct”: “http://purl.org/dc/terms/”,
“spec”: “http://www.w3.org/ns/spec#”,
“skos”: “http://www.w3.org/2004/02/skos/core#”,
“jsonld”: “http://www.w3.org/ns/json-ld#”,
“id”: “@id”,
“type”: “@type”
},
“@graph”: [
{
“id”: “https://ujg.specs.openuji.org/ed/”,
“type”: “spec:Specification”,
“dct:title”: “UJG Editor’s Draft”,
“spec:requirement”: [
{ “id”: “https://ujg.specs.openuji.org/ed/#payload-context-uri” },
{ “id”: “https://ujg.specs.openuji.org/ed/#context-definition” }
]
},

{
  "id": "https://ujg.specs.openuji.org/ed/#jsonld-context",
  "type": "skos:Concept",
  "skos:prefLabel": "Payload document",
  "jsonld:context": {
    "id": "https://ujg.specs.openuji.org/ed/context.jsonld"
  }
},

{
  "id": "https://ujg.specs.openuji.org/ed/#payload-context-uri",
  "type": "spec:Requirement",
  "spec:requirementSubject": {
    "id": "https://ujg.specs.openuji.org/ed/#jsonld-context"
  },
  "spec:requirementLevel": { "id": "spec:MUST" },
  "spec:statement": "A Payload document serialized as application/ld+json MUST include \"@context\": \"https://ujg.specs.openuji.org/ed/context.jsonld\"."
},

{
  "id": "https://ujg.specs.openuji.org/ed/#context-definition",
  "type": "spec:Requirement",
  "spec:requirementLevel": { "id": "spec:MUST" },
  "spec:statement": "The JSON-LD context document identified by https://ujg.specs.openuji.org/ed/context.jsonld MUST be equivalent to the JSON-LD context defined in #jsonld-context."
},

{
  "id": "https://ujg.specs.openuji.org/ed/context.jsonld",
  "type": "jsonld:Context",
  "jsonld:version": 1.1,
  "jsonld:vocab": "https://ujg.specs.openuji.org/ed/ns/core#",
  "jsonld:definition": [
    {
      "type": "jsonld:TermDefinition",
      "jsonld:term": "specVersion",
      "jsonld:id": "https://ujg.specs.openuji.org/ed/ns/core#specVersion"
    },
    {
      "type": "jsonld:TermDefinition",
      "jsonld:term": "imports",
      "jsonld:id": "https://ujg.specs.openuji.org/ed/ns/core#documentImports",
      "jsonld:type": "@id",
      "jsonld:container": "jsonld:setContainerType"
    },
    {
      "type": "jsonld:TermDefinition",
      "jsonld:term": "nodes",
      "jsonld:id": "https://ujg.specs.openuji.org/ed/ns/core#documentNodes",
      "jsonld:container": "jsonld:setContainerType"
    }
  ]
}

]
}

is it true? or am i missing smth.

I came to Solid through a project I’ve been building around consumer consent and preference data — the idea that the act of consuming is one of the most expressive things people do, and yet it’s the one domain where that expression
has been quietly taken from us and turned into behavioral data owned by someone else. Solid feels like the right foundation for changing that.

Looking forward to being part of the community.

You can find more about me at atyilmaz.com

@

I’ve been building ConsAuth — an identity and preference-sharing layer built on top of Ory Hydra (OAuth2/OIDC) and Community Solid Server v7.

Wanted to share the current status and where it’s heading, get feedback. What we’re planning touches directly on Solid’s strengths in a way that feels worth discussing.

Expression of Demand ( consauth[dot]com/expression-of-demand ) is my attempt to extend the freedom of expression into the one domain where it has been quietly taken away — in a world that has reduced people to consumers, I want the act of consuming to be as expressive, intentional, and self-owned as any other form of speech.

@

What ConsAuth does

ConsAuth (consumer . consent . auth ) lets users log into apps with “Login with ConsAuth” — similar to “Login with Google” — but here apps receive structured preference and wish data that the user explicitly approved. Food preferences, music taste, travel style, values-based stances (like ethical sourcing), expressed as named scopes on the consent screen.

The preferences aren’t inferred from behavior. They’re declared by the user, directly or as part of the AI-assisted chat, scoped by category, and shared only when the user actively consents to each app that requests them.

Where Solid comes in

We chose Solid because we didn’t want ConsAuth to hold user data — we wanted users to own it. Every user who opts in gets a personal Pod at

pod[dot]consauth[dot]com backed by CSS v7. (on-demand pod provisioning)

When a user sets a preference, it syncs to their Pod as Turtle RDF using a vocabulary we publish at vocab.consauth.com — a lightweight Linked Data schema for consumer preferences. Public preferences are readable at
their Pod URL by any app the user authorises. Private ones aren’t.

A short example of what lands in a Pod:

@prefix ca:  <https://vocab.consauth.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://pod.consauth.com/tolgay/consauth/preferences/values-boycott_brands>
  a ca:Preference ;
  ca:category "values" ;
  ca:key "boycott_brands" ;
  ca:value "Coca-Cola,amazon" ;
  ca:visibility ca:Public ;
  ca:setAt "2026-03-09T16:09:58Z"^^xsd:dateTime ;
  ca:updatedAt "2026-03-09T18:03:06Z"^^xsd:dateTime ;
  ca:isBinding false .

We also store product wishes (structured demand expressions — “Looking for a secondhand road bike under £300”) and boycott positions with reasons, all as RDF resources under the user’s Pod path.

One technical thing worth sharing: CSS v7 DPoP

For anyone integrating with CSS v7 from a backend service: it requires DPoP for all resource writes. We implemented this in Go — generating ECDSA keypairs per-request, hashing the request method + URL as the htu/htm claims. Happy to share the code if useful.

One gotcha: CSS validates WebIDs by dereferencing them internally, so the server must be accessible at the same URL it uses in --baseUrl. We run it on the same port it advertises (:4001) and have our API container spoof the Host header when talking to CSS internally.

Where we’re heading: demand signalling via LDN

The part I’m most interested in discussing with this community is what comes next.

Right now preferences live in a Pod and travel into apps via the OAuth2 token. That’s useful. But the Pod being a live, accessible data store opens up something more interesting: it can be an inbox for things that match what you’ve declared you want.

We’re exploring using Linked Data Notifications as the mechanism for this. The basic idea:

• A user’s Pod exposes a public LDN inbox
• They’ve declared (publicly or at community level) that they’re interested in, say, plant-based leather alternatives
  in a certain price range
• A small producer browsing ConsAuth’s demand API discovers that 847 members of an Ethical Fashion community have
  expressed this demand — as an aggregate signal, no individual profiles exposed
• The producer sends an LDN notification to the community inbox, or to individual inboxes of users who’ve opted in to
  producer notifications in that category
• The user sees it in their Pod, not in an ad feed — on their terms, in their data store

The privacy property here is what makes it interesting: at the collective level, individuals are protected behind the aggregate (what we think of as a “zebra effect” — the herd is visible, the individual is not). At the individual
level, you can make preferences public on your Pod and be directly discoverable, or keep them private and only contribute to community-level signals.

This would mean Solid Pods can become active receivers of relevant market signals. Broadcasting and receiving. No intermediary platform. No algorithm deciding what reaches.

Questions / things we’d love feedback on

1. LDN inbox design — has anyone implemented per-category LDN inboxes on CSS? We’re thinking about a namespace like
   pod.consauth .com/{user}/inbox/demand/ vs. a single inbox with typed notifications. Curious what patterns others have
   found workable.
2. Vocabulary — our schema at vocab[dot]consauth[dot]com is hand-rolled and minimal. Is there existing work in the Solid ecosystem on preference or interest representation that we should be aligning with?
3. Cross-pod discovery — if a user moves their Pod to a different provider (which is the whole point of Solid), how
   should ConsAuth’s demand aggregation layer stay in sync? We’re thinking about the Pod advertising a ConsAuth-specific
   type link in its profile document, but haven’t designed this yet.

Haven’t open-sourced the code yet. The vocabulary is live and resolvable. Happy to discuss any of this and collaborate.

— @

solidlabresearch.github.io

You could try.

Or use mashlib data browser https://SolidOS.github.io/mashlib/dist/browse.html a pane display authorisation

I am trying out some things and wanted to ask whether there is a possibility to elegently see in one of the file managing apps, what the access of the datasets within your POD is. In Penny I see that there are ACL entries. Its really hard to understand for me what they exactly mean tbh. The Solid File Manager looks really nice, but there I cannot find anything in that direction. In my imagination I would expect something like the output from ‘ls -l’ in command line on a Unix system.

Am I just not getting something or is it just an open issue or not implemented?

Thanks

Enjoy!

Sébastien from Réconnexion will share how their cooperative is building Universal Social Network with ActivityPods, concept of “Pod as a backpack”, and why they’re considering earlier-than-expected move to NextGraph.

We’ll also hear short talks on: ActivityPub module for CommunitySolidServer (Th), a new single-user ActivityPub-capable Solid server (Luke), and an ActivityPub agent for Solid pods (Michal).

If you’re interested in where Solid meets the Social web, join us. This Thursday, March 5 2026, 15:00 UTC (90 minutes). Jitsi Meet

We chose Community Solid Server as the single data store for our accessibility-first OS since XDG translates nicely into pod structure — eliminating individual databases per application. Security and sovereignty were the deciding factors.

We’ve built three Community Solid Server pods (live USB, VPS, local server) staying in sync via Matrix federation with CRDT-RDF merge strategy at the triples level. Currently testing on a 2012 HP ProBook with 4GB RAM to establish a baseline for addressing e-waste. Results are promising.
Would love to connect with anyone working on pod sync, accessibility, or resource-constrained deployments. Thanks for your response Eric

I’m currently open to project opportunities and collaborations within the Solid ecosystem.

I have worked on several projects involving Solid Pods, linked data, authentication (OIDC), access control, and building decentralized, privacy-focused applications. I’m comfortable working with Solid servers, integrating apps with Pods, and designing secure, scalable solutions.

If you need help building, integrating, or improving a Solid-based project, I’d be happy to contribute. I’m committed to clean implementation, reliability, and timely delivery.

Feel free to reach out — I’d love to collaborate and bring your project to life.
-Bella

You can find the details here and the direct join link (zoomlink and Code) below

Passcode:303726

Everything dépends on model, prompt, température and son many more parameters… like data acces, tools. The purpose of this project is not to write true things, if I wanted to, I could specify in the prompt “don’t invent facts”, I could give it Solid spec, doc, or a link to . It’s like a baby just learning to speak, but does not understand all the things he says… but if you give it the good infos, how to use it, what you exactly want, I think it could be a good tool.

Until now, I had mistakes for long conversation ( when the context is overflow, some infos are dropped). And data was unstructured. Using Solid’s graph as knowledge base was one of my goals since I tried Ai tools, following concepts links, exploring and updating data. The may issue until now was CRUD operations and indexation for speed of retrieving data without following each link, reading each resource everytime user ask a question.

And here is a good starting point

Then I could visualize the result as a mindmap, plugin it to my 3D-solid-mindmap tool :

3D mindmap on your Solid pod - Getting started in 4 mins

My thinking, this morning, was “Why isn’t there more people to use Solid to share data?”
and the response : “Because this is not easy to do simple things !”

I think with this app, we could get it a little bit simplier.
Sure the way is far but i got something interesting :
When i ask : “create a note about Solid Project with a link to the github repo, add a mention to Community Solid Server”

I got a note : Note créée : http://localhost:3000/david/notes/solid-project-overview.ttl

./assistant.sh
2026-02-20 14:52:44,608 - INFO - CRUD Store initialisé avec base: http://localhost:3000/david/notes/
Assistant prêt. Tapez votre question (ou ‘quit’ pour quitter), ‘:commande [params]’ pour les commandes internes, ‘/commande [params]’ pour les commandes llm

Vous: create a note about Solid Project with a link to the github repo, add a mention to Community Solid Server

2026-02-20 14:53:35,343 - INFO - [TOOL CALL]: 1
2026-02-20 14:53:35,350 - INFO - Appel fonction create_note avec args {‘title’: ‘solid-project-overview’, ‘content’: ‘The Solid Project is an open-source personal data store that empowers users to control their data. It provides a decentralized architecture based on the Solid Pod, allowing individuals to host their own data and share selectively with others using Linked Data principles.\n\n🔗 GitHub Repository: https://github.com/solid/solid\n\nOne of the key components for running a Solid Pod is the Community Solid Server (GitHub), which provides a user-friendly, production-ready implementation of a Solid Pod. It’s ideal for testing, development, and hosting personal data securely.’, ‘tags’: ‘solid, project, github, community-server’}
2026-02-20 14:53:35,412 - INFO - Solid session webid http://localhost:3000/david/profile/card#me
2026-02-20 14:53:35,540 - INFO - ✅ Note créée : http://localhost:3000/david/notes/solid-project-overview.ttl
Assistant: La note sur le projet Solid a été créée et indexée. Que puis-je faire pour toi ensuite ?

with some nice content : (for the moment, all is in content predicate, but modifying the tools, i hope using more predicates ;-))

@prefix dcterms: <``http://purl.org/dc/terms/``> .
@prefix ns1: <``http://example.org/ns#``> .
@prefix xsd: <``http://www.w3.org/2001/XMLSchema#``> .

<``http://localhost:3000/david/notes/solid-project-overview.ttl``> a ns1:Note ;
ns1:content """The **Solid Project** is an open-source personal data store that empowers users to control their data. It provides a decentralized architecture based on the **Solid Pod**, allowing individuals to host their own data and share selectively with others using **Linked Data** principles.

🔗 **GitHub Repository**: [``https://github.com/solid/solid``](``https://github.com/solid/solid``)

One of the key components for running a Solid Pod is the **Community Solid Server** ([GitHub](``https://github.com/solid/community-server``)), which provides a user-friendly, production-ready implementation of a Solid Pod. It’s ideal for testing, development, and hosting personal data securely.""" ;
ns1:tags "solid, project, github, community-server" ;
dcterms:created "2026-02-20T13:53:35.484485+00:00"^^xsd:dateTime .

then i can ask to read the note :

Vous: what is the content of this note

2026-02-20 14:59:04,925 - INFO - [TOOL CALL]: 1
2026-02-20 14:59:04,925 - INFO - Appel fonction read_note avec args {‘uri’: ‘http://localhost:3000/david/notes/solid-project-overview.ttl’}
Assistant: Voici le contenu de la note “solid-project-overview” :




Titre : solid-project-overview

Contenu :
The Solid Project is an open-source personal data store that empowers users to control their data. It provides a decentralized architecture based on the Solid Pod, allowing individuals to host their own data and share selectively with others using Linked Data principles.

🔗 GitHub Repository : https://github.com/solid/solid

One of the key components for running a Solid Pod is the Community Solid Server (GitHub), which provides a user-friendly, production-ready implementation of a Solid Pod. It’s ideal for testing, development, and hosting personal data securely.

Tags : solid, project, github, community-server
Créée le : 2026-02-20

Vous:

Next i can ask to modify the content…

Vous: add Tim Berners Lee and Jeff Zucker (https://github.com/jeff-zucker) as contributors
2026-02-20 15:03:34,474 - INFO - [TOOL CALL]: 1
2026-02-20 15:03:34,481 - INFO - Appel fonction update_note avec args {'uri': 'http://localhost:3000/david/notes/solid-project-overview.ttl', 'new_content': 'The **Solid Project** is an open-source personal data store that empowers users to control their data. It provides a decentralized architecture based on the **Solid Pod**, allowing individuals to host their own data and share selectively with others using **Linked Data** principles, invented by its creator, **Tim Berners-Lee**.\n\n🔗 **GitHub Repository**: [https://github.com/solid/solid](https://github.com/solid/solid)\n\nThe Solid Project has been developed with contributions from **Tim Berners-Lee**, the inventor of the World Wide Web, and **Jeff Zucker** ([GitHub](https://github.com/jeff-zucker)), who has actively participated in advancing Solid’s mission.\n\nOne of the key components for running a Solid Pod is the **Community Solid Server** ([GitHub](https://github.com/solid/community-server)), which provides a user-friendly, production-ready implementation of a Solid Pod. It’s ideal for testing, development, and hosting personal data securely'}
2026-02-20 15:03:34,546 - INFO - Solid session webid http://localhost:3000/david/profile/card#me
2026-02-20 15:03:34,619 - INFO - ✅ Note mise à jour : http://localhost:3000/david/notes/solid-project-overview.ttl

Assistant: La note a été mise à jour avec les contributions de **Tim Berners-Lee** et **Jeff Zucker**. Que puis-je faire pour toi ensuite ?

Vous: give me the content

Assistant: Voici le contenu mis à jour de la note **"solid-project-overview"** :

---

**Contenu** :
The **Solid Project** is an open-source personal data store that empowers users to control their data. It provides a decentralized architecture based on the **Solid Pod**, allowing individuals to host their own data and share selectively with others using **Linked Data** principles, invented by its creator, **Tim Berners-Lee**.

🔗 **GitHub Repository** : [https://github.com/solid/solid](https://github.com/solid/solid)

The Solid Project has been developed with contributions from **Tim Berners-Lee**, the inventor of the World Wide Web, and **Jeff Zucker** ([GitHub](https://github.com/jeff-zucker)), who has actively participated in advancing Solid’s mission.

One of the key components for running a Solid Pod is the **Community Solid Server** ([GitHub](https://github.com/solid/community-server)), which provides a user-friendly, production-ready implementation of a Solid Pod. It’s ideal for testing, development, and hosting personal data securely.

**Tags** : solid, project, github, community-server
**Dernière modification** : 2026-02-20

Vous: 


```

I've added a RAG, too to index all notes...

Let see what it will become…

elf Pavlik and I have created a new bi-weekly meeting for tools implementers to meet and discuss their implementations. It’s bi-weekly on Wednesday at 15:00 UTC.

Come if you’re implementing tools or if you have an interest in tools being implemented.

Our first event will be on Wednesday, the 25th at this link: Jitsi Meet

• project : solid-indexer/README.md at main · scenaristeur/solid-indexer · GitHub
• indexer: solid-indexer/solid_indexer.py at main · scenaristeur/solid-indexer · GitHub
• rag-query: solid-indexer/solid_rag_query.py at main · scenaristeur/solid-indexer · GitHub
• crud_store : solid-indexer/solid_crud_store.py at main · scenaristeur/solid-indexer · GitHub
• assistant: solid-indexer/solid_rag_query_crud_function_calling.py at main · scenaristeur/solid-indexer · GitHub
• example1 : solid-indexer/examples/EXEMPLE.md at main · scenaristeur/solid-indexer · GitHub
• example2 : solid-indexer/examples/EXEMPLE2.md at main · scenaristeur/solid-indexer · GitHub

I really enjoyed it. I have recommended it to some work mates as well.

I enjoy building applications on the web and feel lucky that I can do something I enjoy for a living. I specifically enjoy working on the web because I have always believed in the open web ideals.

I’ve had to push for the importance of accessible products at almost every place I’ve worked at in my career so far (except for one place that provided services for government etc so accessible products was a requirement there). It can be draining at times to keep putting in the effort but it is worth it (and important).

It’s nice to see it mentioned in the book a few times as an important part of the open web ideals/goals.

Although I believe the web is an important tool I don’t like the walled gardens we have at the moment. I don’t have any social media accounts (I had a facebook account in the early years for a few months - didn’t like it).

I like finding a good blog and podcasts. But I don’t connect and participate online. It’s just not really my thing. I prefer to connect in person. But also the privacy violations are gross and I don’t wanna participate in that.

These things were touched on in the book to varying extents (data mining and walled gardens etc).

I feel like Solid is the kind of web I wanna get behind. Doesn’t really matter to me whether it becomes “succesful” and widely adopted. It’s the only version of the web that I want to support. The current state of data ownership is ridiculous.

I’m new to Solid but felt more inspired to explore and learn more about the project after reading the book. Although I enjoy building on the web I have been disconnected from the web as a user due to the current state of things.

It’s good to be reminded that there are people around that actually care about privacy and the web as an important open resource (including the inventor!).

I opened the link on my phone. The glossary is really useful as someone new.

My only feedback is it would be good if it was responsive. Pinch and zoom is a bit awkward when reading it on my phone.

I decided to edit the ACL file of the resource instead and I am wondering if this is the best way to grant access to a resource for another user regardless of the pod provider the resource is in. Basically, I want a catch all solution to any pod provider so I can grant access to a resource.

I thought there would be more of a discussion type forum for new users.

In addition to this forum (in which you are welcome to ask any questions) a lot of discussion goes on in the matrix chat channels and in the community group virtual meetings. I invite you to the Practitioner Group which holds regular discussion meetings online and also coding session focusing on mentoring, skill sharing and networking. More info on the meetings and chatroom are available here - GitHub - solid-contrib/practitioners: A hub for Solid developers

Would it be possible to use Solid as a space for safely maintaining LLM data?

Absolutely! This has been discussed across various in person gatherings (SoSy and SolidLabs) and video-calls.

There are several different perspectives people are coming from, each with their own solutions.

I think the upcoming Solid Practitioners regarding AI can be a very interesting convergence for all parties involved in this. Both those that already commented here, and others.

From what you describe, I was thinking that another route might be to combine an Activitypub MCP with ActivityPods, and regulate ingress/egress to and from Pods that way.

Within Muze (part of PDS Interop, creators of the Solid-Nextcloud and the PHP Solid Server) we’ve been discussing ways a Solid Pod could be used as a central hub for “All your AI activity”.

We’ve got plans of adding ANP (Agent Network Protocol) to the Solid-Nextcloud and PSS. (As others are already working on MCP solutions).

ANP seem a specifically good match for Solid, as it requires Linked-Data (which Solid also demands) and uses Decentralized Identifiers (DIDs) which is also being looked into for the Solid Spec.

I’ve not had time to publish anything, but it might be worth throwing a proof-of-concept together, if I can ever find the time…

I wanted to share an idea we had. We think it would be good to give users a choice what application is started after the login. Something we name the “shell” feature. This could be put in your preferences.

• When you then migrate to another Solid server, your experience will remain the same.
• (Startups) building an application could be easier as you could ask new users to change the shell to your application.
• It would give users more freedom where they end up after login.

Let us know what you think of this.

Kind regards,
Sjoerd

Details can be found here Solid World Feb 2026 | The ODI

the direct join info if you won’t register is below:

Passcode:537671

No special software, preregistration, or technical knowledge is required to join. Just point your browser at Jitsi Meet . For more about the Practitioners group, see GitHub - solid-contrib/practitioners: A hub for Solid developers.

renyuneyun:

Can I presume that is intended to use Solid pods to host conversations?
…

ODI is working on LibreChat for using Solid as storage backend. That should be a promising thing.

Still a WIP, we are working to get it to a point where it can be upstreamed to the core LibreChat codebase. In the meantime here is a preview: https://drive.google.com/file/d/14BumPFZ58IZb8cGK-mB4GONfafXcm0LS/view?usp=sharing

For us, it’s both hosting the app, and maintaining an example LLM service. That’s the only way we can demonstrate the system. LLM service is apparently expensive, as you also pointed out; but the user can specify which service they want to use, which reduces this burden if we don’t need to “demonstrate”.

But the app hosting was also a burden, as that requires a server (it’s written using Streamlit and Python, so can’t be put onto, e.g., GitHub Pages), and involves interesting/annoying hosting rules from our institution. (That’s why I mentioned the possibility of Streamlit providing hosting… which may improve the situation.)

How this relates to clawdbot is that it has high level access to messaging apps and emails and such. Therefore if it gets prompt injected, many of these messaging apps have no guardrails for that scenario, so anything clawd sends can be executed. If more companies treated AI agents as silly interns rather than senior managers, they may understand that it is less about teaching the AI guardrails at this point and rather focusing on the robustness of systems as if a clueless intern was working on them.

I agree with @NoelDeMartin about doing Solid properly. My intuitive approach to AI in Solid would be less “let an AI have access to all available resources/applications and make decisions” but rather “my Solid AI can access my grocery list, weather app, and messages” and set permissions from there with the folders synchronized to your Pod space. I think tool usage is also being undervalued here. AI should have a set of strong tools in order to make decisions - I remember a saying where if “all you have is a hammer, then everything looks like a nail”. So let’s give our AI agents good tools to use in the Solid ecosystem from the get-go.