Re: Some thoughts on storage backends and live updates

Paul

Is there any open source access to your implementation in CSS.
This could be a nice add-on.

Alain

Le jeu. 16 avr. 2026, 00:26, Paul Worrall <paul.worrall@interition.com> a
écrit :

> Hi Sarvin
>
> I have implemented git repo support in my CSS servers.
>
> I had to put it in place because there was no way I could risk data
> getting corrupted/wiped out by erroneous clients.
>
> Paul
>
> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
>
> ------------------------------
> *From:* Sarven Capadisli <info@csarven.ca>
> *Sent:* Wednesday, April 15, 2026 10:30:12 pm
> *To:* public-solid@w3.org <public-solid@w3.org>
> *Subject:* Some thoughts on storage backends and live updates
>
> Hi all, have some work and thoughts to share and would appreciate
> discussion/collaboration.
>
> In dokieli ( https://dokie.li/ ) , we recently released several
> features: read and write support for different storage backends,
> slideshow creation, and a collaborative editor. These were things we had
> been putting off for a while. We shared a short thread here:
>
> https://w3c.social/@dokieli/116409432956275621
>
> and in the dokieli chat:
>
> https://matrix.to/#/#dokieli:matrix.org
>
> with a screencast and demo playground.
>
> The work is not flawless, but the foundations and core functionality are
> in place and taking shape. Some areas still need polishing, and others
> may require revisiting.
>
> Any way, a couple of things relevant to Solid specs and implementations:
>
> We now support Personal Access Token, with OAuth coming soon, to enable
> read-write access for HTML/Markdown, as well as referenced media and
> scripts, to GitHub and Forgejo repositories. Setup is straightforward:
> create a token for a repository and grant read-write access. This is
> part of a broader effort to support multiple storage backends in dokieli.
>
> This also brings back an idea we explored in 2015 at MIT. A simple shell
> script triggered sync to a git repo whenever the inode changed, i.e.
> when a Solid server wrote to the filesystem. When an app interacts via
> the web interface, the Solid server can synchronise those changes with a
> repo, and also pull in updates for Solid apps.
>
> I previously opened feature requests in CSS and NSS to make storage
> repository-aware, but that work seems to have stalled. Are there any
> open source Solid servers today that integrate with git or other
> versioning system repos? If so, we would like to experiment. dokieli
> just wants to read-write to wherever the user directs it to.
>
> The other feature is collaborative editing. This is complex but
> important. We are currently using WebSockets. The Solid CG explored this
> (in almost like another lifetime ago) but we could not resolve authn/z
> in the context of a Solid server. As it stands, anyone could send
> patches to a WebSocket server that distributes updates to clients. Even
> if the underlying resource is protected, this creates a security gap.
> dokieli's demo location is intentionally limited and resets itself, and
> doesn't update the resource itself, until related concerns are addressed.
>
> Some mitigations are possible, but the problem is not unique to Solid.
> If anyone has been working in this area, I would appreciate pointers.
>
> As much as we'd love to, we don't have the bandwidth right now to go in
> all directions an authoring, annotation, notification tool touches with
> respect to specifications, let alone development, and other concerns. It
> is about a complex application as it gets on the open web platform.
>
> I would like to see renewed focus on real time capabilities in Solid.
> These are essential for a range of applications. Without a viable
> approach in the near future, it becomes harder to justify Solid as a
> platform for such use cases.
>
> So, I would like us to get back on track with building and *using*
> advanced apps.
>
> -Sarven
> https://csarven.ca/#i
>
>