remoteStorage

Describing Solid on the Unhosted website

Hi all,

I created a pull request that describes how developers of unhosted web apps can support Solid: https://github.com/unhosted/website/pull/67

I could imagine that some of us consider “unhosted” should automatically (mainly) mean “remoteStorage”, since its’ the remoteStorage/Sockethub stack that we built as the main stack for use by the unhosted community.

I don’t see it that way myself, I think unhosted web apps can use or support any per-user storage technology they want - for instance, we also already describe how to let users store their data from an unhosted web app on Dropbox or on Google Drive.

But posting this here to get a feel for how others in the unhosted / remoteStorage community see this.

This seems pretty clear to me:

Also known as “serverless”, “client-side”, or “static” web apps, unhosted web apps do not send your user data to their server. Either you connect your own server at runtime, or your data stays within the browser.

Personally, I don’t remember having had a conversation with anyone who disagreed with that definition. Also, you are the author of that definition, so it would be even harder to disagree with your opinion on it. :smiley:

My question would be more about how to fit it in to the current structure of the website. There’s already a page about tools for unhosted apps for example:

http://unhosted.org/tools/

There’s also one about per-user (storage) back-ends:

http://unhosted.org/practice/31/Allowing-the-user-to-choose-the-backend-server.html

Are there any plans to update those pages to include Solid, and to fit the tutorial link in a place, where it’s part of the published Unhosted story?

1 Like

Good point! I’ll update those two pages as well to link to it, so it’s more coherent. I’ll also see if there are other things that changed since 2014 that I can update (for instance, I just noticed it still says Microsoft OneDrive does not offer CORS, I heard that’s no longer true nowadays).

The text as a whole doesn’t really fit inside the tools page, and I thought about adding it as an addendum episode to the end of the HTML book, but I don’t think that really makes much sense either. So I think I’ll just link from both places, and add a link to it in the top part of the left-nav menu.

1 Like

I think that makes way more sense than a random link in the main navigation, without any context for it.