# Solid Open-source Tools (2026/03/25)

Tools:

* https://ldo.js.org (Jackson Morgan - [e-mail])
* https://github.com/rdfjs/wrapper ([Samu Lang](https://github.com/langsamu))
* https://soukai.js.org/ ([Noel De Martin](https://noeldemartin.com))
* https://github.com/uvdsl/solid-rdf-store
* https://github.com/muze-nl/metro (Auke van Slooten - [e-mail])
* https://github.com/muze-nl/oldm (Auke van Slooten - [e-mail])
* https://github.com/muze-nl/jsfs-solid (Auke van Slooten - [e-mail])
* https://github.com/ldhop/ldhop (Michal)
* [SAI application](https://www.npmjs.com/package/@janeirodigital/interop-application) (elf Pavlik) package moving to JSR soon! mostly discovery and authz affordances, should integrate with any of the tools above
* [NextGraph ORM](https://www.npmjs.com/package/@ng-org/orm) (Niko)

## Sub-Topics: Discussions of Specific Devtools

### Soukai:

- Noel: You can go to my website and see my talks to learn more (specially noeldemartin.com/solid-symposium-dx). Soukai is an activerecord implementation of Solid. It was built 7 years ago for 2 reasons:
- I was used to Laravel Eloquent and I wanted something similar to it.
- I came from a background of an SQL database, but other libraries were focused on RDF. We work by defining a schema, then not worrying about RDF after that.
- Note, Soukai is good for beginners or traditional application developers.
- Recent Developments:
- I started a rewrite. There's an issue with the current codebase. It has 2 libraries: 1 for core and 1 for Solid because I started working on Soukai before I knew Solid existed. But, since I've worked in Solid for so many years, I wanted to build it from scratch with Solid at its core.
- I'm using [Zod](https://zod.dev/) which is a validation library. I'm building it on top of Zod so it's easy to define models.

### RDF/JS Wrapper Samu:

- Samu: RDFJS wrapper was recently developed and published under the ODI. It's an object relation mapping library. I've done it in Java and in C# and now it's time to do it in JavaScript using RDF/JS.
- The emphasis is on as little baggage/dependencies as possible. I would like all patterns that can be modeled and queried in RDF to be represented in JavaScript. I want it to be very idiomatic for class based JavaScript.

## SAI.js

- Elf-Pavlik: Sai.js is about authorization. It's bound to LDO, but it shouldn't be tied to any lower level library. It's mostly about discovery and basic affordances [for authorization] and UI rendering.

## Main Topic: Coordinating Devtools

### Interface for Retieving Documents

- Niko: We know most of the projects in the room and we all have a slightly different version of it. We're focusing on the frontend and what's happening in JavaScript. We have the sense that the app developer is not so interested in RDF. They're more used to JSON and want to have access to the data. Then, there are the frontend frameworks like React/Vue etc, which are good because they're reactive and have bindings for the data. That's what a developer of an app wants to use. And it's even easier to use AI when it's more similar to JavaScript.
- Niko: The first principal that I got was that you ask for a resource, then you can get it, then you can subscribe for changes, but you must fetch it again. We can know atomic updates (a triple has been inserted or removed). Essentially, I want to common API that can subscribe to a name graph and get an update on the triples on top of that.
- Elf-Pavlik: I've contributed to Rdf/js and the idea was to have a low level common-ground for JavaScript. Here, I think the we care about higher level libraries for Solid. We can converge, but it's not required that we converge. There are reasons to diverge as well. The goal is that if there's a difference we understand well why.
- Auke: We have an unusual position in that we are also developing server-side implementations. I think to do this well, we should have a special connection to the server that allows you to get those updates efficiently and not having to fetch the entire resource. I'm very much in favor of doing that so we can have this subscription stuff at a lower level. The difficulty I believe is that while triples are naturally streaming, that only adds information. If you want to remove a triple there's nothing in the vocabulary that does that except for SPARQL style patches. If we go that route we want to figure out the protocol to do that. It's the only viable way if we want to have some efficient applications.
- Noel: I agree with all of that. But, if something is not supported by the Solid protocol, it would be hard to do something with.
- Noel: I agree on reaching a common interface. But, these things don't make sense for Sokai because Sokai doesn't care about RDF or triples.
- Niko: We don't work with triples as well at a high level. We hide it at a high level, but this interface is proposed for work at a low level.
- Samu: I'm not sure I know what this is all about. I don't know of any implementation or spec that talks about communicating changes to triples. I also know there is nothing in the RDF/JS spec to this. So, maybe it belongs in the RDF/JS spec if not lower. So, if we talk about this mapping libraries or object relation libraries, that parts that have to do with RDF should deal with RDF changes. But, the parts that have to do with Solid. So, I don't know what we can agree on.
- Noel: We can agree on an ontology.
- Niko: For us it's not about an ontolgoy, it's at a lower level.
- elf Pavlik: I think it would be helpful to have a user story. As a developer I want to have x accomplished for me... Also for communicating diffs, there's a CG for CRDTs. Currently Solid uses SPARL update, so if the notification can use the same payload that would be helpful.
- Auke: I think it's an interesting discussion. As a developer I'm into CRDT stuff. Is this the most pressing issue right now with the Solid ecosystem and building front-end software for Solid? I want to be able to build this kind of Software and we've chosen Solid as the main base to start from, but we've decided that local-first is something for the future. There is not application ecosystem right now so we need to focus on that. I'm not going to block anything, but I'm wondering if anyone else feels the same.
- elf-Pavlik: There should be a line drawn between real time and local first. Real time is the minimum.
- Noel: I don't agree 100% with that. The reason I'm doing local first is the current solid ecosystem isn't
- Niko: The interface LDO has is good, we were able to adapt nextgraph to it and now comes the problem to send patches to the client. Read acces should be easy to solve. If we do this as a standard then it may be a way to push LWS to be more modern.
- Elf-Pavlik: Since we are talking about LWS, Samu I think you are creating a reference implementation from LWS.

ACTION ITEM: Niko will write document summarizing.

### Decide on Something Common to use to define shapes
// Discuss next meeting

### RDF/JS Async

- Samu: Does anyone else suffer from the lack of async in RDF/JS specification. Let's talk about the match method of the of the rdf. It's very problematic because it's hard to make it work in modern contexts.
- Samu: Interop is the not the only concern here.
- elf-Pavlik: RDF/JS is a community group, so this feedback would be good to post to the mailing list. RDF/JS was split into streams/datasets. Streams were the async way to deal with things.
- Samu: I hear you, but the streams are not "asynchronous" in the way that you expect in JavaScript.
- elf Pavlik: There's an interest to use RDF/JS in a new process. For me, I don't like the equal method on the data model, but that's a separate topic.
- Niko: The interface for recieving updates could be there in the RDF/JS spec. I do also do transactions. But, if there were a common interface, I could go to that standard. A year ago, I followed the advice of Jesse, and talking to the RDF/JS people was like talking to a wall.
- Samu: I'm recently working with the RDF/JS people. Because Jesse got this wrapper library under the github NPM.
https://www.w3.org/community/rdfjs/

https://matrix.to/#/#rdfjs_public:gitter.im

ACTION ITEM: Samu will write the