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