soukai-solid is an extension of Soukai, which I created before knowing that Solid existed :).
I actually started working on this paradigm before finding about Solid, remoteStorage, or any of these technologies. It’s not that they didn’t exist, I just didn’t know about them (I think in that tweet they were talking about HubZilla). That’s why I created the Autonomous Data website, and I was planning to define a protocol myself, based on OAuth, GraphQL, and RDF vocabularies (I didn’t know what RDF was, but I knew about schema.org and I wanted to define data in the same way, with public urls that document the data shape and meaning). But since I found Solid, I’ve been focusing on that because it’s better than working on my own protocol. Maybe if I had found remoteStorage before, that’s what I’d be doing now, who knows.
However, for this reason, in theory my apps can be adapted to other protocols. Because the Solid-specifics are encapsulated. They actually work using an
IndexedDB Soukai engine to store data, which again knows nothing about Solid, and the data is synced using the Solid engine.
I can see a day where I’ll have options to log in with Solid, remoteStorage, etc. But that day is probably a long way off, because at the moment the main focus of my apps is to use them myself, and even though I really want them to be useful for others that’s a secondary goal, given that these are side-projects and I only dedicate one day a week. Also, if I had to add additional log-in/sync options, I’ve always thought I’d prefer to add something like Dropbox, NextCloud, or something that most people already has accounts for.
I can’t say I have a lot of experience with this, as I said I do apps primarily for myself and that’s why I don’t promote them. I also don’t think they are “finished” yet (nothing is ever finished, but I still have things I want to do before releasing the 1.0 version).
However, I’ve had some interesting experiences related to this. Given the nature of Solid, it’s very difficult (or impossible) to track errors. In the first versions of my apps, most errors would fail silently or show some gibberish in the screen. But I worked on improving that for a while, and I’m happy with my current solution.
Basically, any unhandled error is displayed as “Something went wrong, but it’s not your fault. Try again!” and there is a “view details” button. In that screen, you have the full stack trace (which is useful for people using a mobile device who can’t look at the console), and a couple of buttons. One button sends me the error report (this is opt-in, it doesn’t happen by default for privacy reasons). But another button, opens a github issue with the stack trace. I still have to improve on that, because most non-developers don’t have a github account either. But it’s already good enough and there have been some instances where people have opened an issue :). Here’s one example, and how I tried to improve the problem for non-developers: noeldemartin/media-kraken#11.
I still would like to put more work into this, specially if I decide to start promoting my apps or making them more useful to others. I think the key is that when errors happen, there should be a way for them to contact the developer. Given the nature of Zero Data Apps, users can feel on their own when something goes wrong and that’s a bad user experience. At this point, I think most people using these are still enthusiasts, even if they are not developers, so I think they are open to help if you just ask.
But I haven’t had a lot of experience with this, these are just my current thoughts on the topic.