remoteStorage

Zero Data App / 0data.app

After brainstorming there now exists a page for Zero Data App which aims to have a non-technical explanation of ‘unhosted’ as well as a user-friendly app directory that includes apps from the RS wiki, the Solid project, and the unhosted project. Any feedback is welcome and the source is on GitHub.

1 Like

Great stuff! :+1:

Thanks! BTW in case anyone is interested, I’ve stumbled upon quite a few PWA listings and I think most remoteStorage apps should be in them:

PWA and 0data isn’t the same thing but there is a lot of overlap.

1 Like

Nice work!

Is the list of apps available in JSON some place?

I think it’s a good idea to bring the different projects and different ways of doing things together in one place

It might be nice to have a common data standard based on JSON that unites some of the different apps in the eco systems together

Nothing really exists of that type at the moment. We have JSON-LD, but that has the disadvantage that everything is a Set, and that’s for sure not the only data structure that programmers want to use

We have schema.org as a widely use common vocab, but it doesnt cover everything, and often you’ll want to use a plain old JSON keys too

Also declarative data, associated with apps (either stored locally or remotely), is often divided into both data and meta-data, and that’s done in inconsistent ways and sometimes with an overlap so different apps will be using similar, but different data

It would be nice to create some kind of standards that would allow different apps and different data to work together. For different JSON objects to be able to be identified, altered, referenced, and linked

Something, simple, lightweight, modern and developer friendly

1 Like

Yes actually, there is a link way at the bottom of the page, perhaps I should find a better place… https://0data.app/projects.json

2 Likes

I’m more biased towards ‘transformers’ like the the Cambria project than common schemas because:

  • it seems simpler to assume multiple ‘formats’ and small translator functions to move between them. At least in JSON this should be straightforward and it’s a setup more organized for responding to change.
  • it requires no coordination between people.
  • similar apps may use similar data in differing resolutions or complexity.
  • I would say standards move slower by definition, which I tend to find limiting.

The other day I was imagining a JavaScript library that could provide a common API to remoteStorage, Fission, and perhaps SOLID as well (if it’s possible to idiomatically represent JSON objects there). Different from the issue you’re bringing up but maybe part of a solution. I think that things like schema translation and versioning should be ‘built into the library’ developers use so that it happens in a consistent way.

1 Like

Theoretically, there’s nothing preventing you from already doing that in remoteStorage.js data modules I think. At least you could easily prototype it in one or more modules to see how it would work between different apps.

Some good news! The fine folks at AlternativeTo have added 0data as a taggable ‘feature’ so it’s easier to find. I did a few: https://alternativeto.net/feature/0data/

And there’s also the ‘custom platform’ for remoteStorage https://alternativeto.net/platform/remotestorage/

I’m not usually into these centralized listings but I think it’s useful to put RS apps side by side with ‘normal’ apps wherever possible and expand beyond people who already know and use RS.

1 Like