remoteStorage

Describing Solid on the Unhosted website

#1

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.

#2

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
#3

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
#4

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