Hey, I’ve given the app a try and I like it, good job :D.
One improvement that comes to mind is allowing shared links to be viewable without logging in. That way this can be useful even for non-Solid users and be a nice way to get people into it. They could read the documents just with the link, but in order to write they’d need to log in with their Solid account.
I also tried using the app without setting any passwords to see if I could see the unencrypted data, but it seems like that didn’t work properly. Maybe passwords should be required? Or at least make sure that this works.
On the data side, I know that linked data and interoperability were out of the scope, but In case you’re interested I’ve been trying to implement a CRDT approach for Solid as well. Although my approach is for a much simpler use-case; real time editors are certainly on another league. I’m working on a vocab to declare the CRDT operations, but one immediate problem I can see is that it’s probably not compatible with
yjs’s data structure. An additional challenge is adding encryption on top of all this, of course. But it’s very interesting to see these things in Solid starting to appear :).
Maybe a half-way approach would be to just declare the CRDT/encryption algorithms in RDF and have the whole encrypted blob in another property. That way, applications could be interoperable but if they don’t support the CRDT/encryption algorithm at least they could show an error “encryption algorithm ‘whatever’ not supported”. I imagine something like this:
a crdt:TextDocument ;
crdt:crdtAlgorithm "yjs" ;
crdt:encryptionAlgorithm "keystores" ;
crdt:keystores </solidcryptpad-data/keystores/keystores.json.enc>, </solidcryptpad-data/keystores/root.json.enc> ;
crdt:data "U2FsdGVkX1/ooT+U69NASWTXeEhzi97RfpuRxyH73Y9NR0xj0l17+8pafKHsFsmcDfFWP371sjGHQ4anacIxSg==" .
And finally, I have some comments/doubts about the synchronisation mechanism. It seems like the clients are actually connected to each other using WebRTC, and the Solid POD is used to store the data that will be needed for new clients to join, right? That’s actually very nice, because even if the Solid POD goes down for whatever reason, the clients can continue working with each other. But one concern I have is that this seems to create a lot of unnecessary network requests.
For example, imagine I have two clients open: A and B. When I make a change in A, this both writes the data in the POD and sends it to B through WebRTC. So far so good, but then when B gets the update, it’s in turn writing data in the POD again. I’m aware that the way CRDTs work sometimes this is expected, because part of the information stored is what’s the latest operation that a given node has seen. But seeing that every tiny update causes a PUT request that overwrites the entire document is concerning from a performance point of view, specially if this were to be used in mobile devices or other data-sensitive contexts. And I think this is exacerbated because CRDTs are notoriously infamous for creating a huge data overhead. It would be a lot better to just update with the new information, rather than overwriting the entire document.
In any case, I guess those are probably not real concerns you have at this point, but it’s food for thought :).