4 ms·

Solid is awesome and I'm bullish on this model in the long-run, but it seems to be caught in a classic chicken/egg problem. Nobody is going to use it until ther

Solid is awesome and I'm bullish on this model in the long-run, but it seems to be caught in a classic chicken/egg problem. Nobody is going to use it until there are good apps. and nobody is going to make good apps until there is a market of users. IMO this is the same problem that kept Sandstorm and remoteStorage from getting big. I see 2 solutions currently: 1. Make an awesome storage product, that just happens to implement Solid. It might have to start out also implementing S3, which unfortunately doesn't support OAuth, which basically kills it for apps. You could try making it compatible with another proprietary protocol like Google Drive, or provide a frontend library that easily talks to all the major cloud storage providers, plus Solid... 2. Take the slow track. If developers themselves want to use it, they'll write useful open source apps over time. This can take forever though. Even after 30 years there are still large feature gaps on Linux because the market is too small to attract big app developers.

cxr 6y ago
> It might have to start out also implementing S3, which unfortunately doesn't support OAuth The expectation that Solid is backed by a smart server that's intimately aware that it's hosting a Solid pod and what exactly it takes to do so is a critical failure in Solid's design. If Solid's protocols instead better accommodated "dead" formats that can be served by static web hosts, so your $USERNAME.github.io could be the front door to your data store—at least the parts of it that you already make available to the public, anyway—then we'd have passed the chicken-and-egg stage years ago and Solid would already be a runaway success. At the end of the day, it's supposed to be about data, after all—linked data—and not about the endpoints/servers themselves. Compare to the ease of creating an RSS feed for your blog (you can get your static site generator to spit one out pretty easily) and contrast it to needing to provision and actively administer a Mastodon server, for example.
- walterbell 6y ago
  > "dead" formats that can be served by static web hosts, so your $USERNAME.github.io could be the front door to your data store—at least the parts of it that you already make available to the public Could you share some examples of such data, other than "news" feeds? FOAF, for example? http://www.foaf-project.org/ http://www.foaf-project.org/
  - cxr 6y ago
    Inline annotations[1][2], personal patch queues, project notes, bookmarks, calendars, photo galleries, reading lists, media trackers[3], anything you might think of dumping into a Gist or other pastebin-style site, anything you might think of dumping into a hosted TiddlyWiki, and so on. I.e., most of the type of data that Solid pods are already meant to handle, really (except served statically, without the POLP-violating[4] architecture that exists in Solid's current design). 1. https://hypothes.is https://hypothes.is 2. https://www.w3.org/annotation/ https://www.w3.org/annotation/ 3. https://noeldemartin.github.io/media-kraken/ https://noeldemartin.github.io/media-kraken/ 4. https://www.w3.org/2001/tag/doc/leastPower-2005-12-19.html https://www.w3.org/2001/tag/doc/leastPower-2005-12-19.html

cxr 6y ago

> It might have to start out also implementing S3, which unfortunately doesn't support OAuth The expectation that Solid is backed by a smart server that's intimately aware that it's hosting a Solid pod and what exactly it takes to do so is a critical failure in Solid's design. If Solid's protocols instead better accommodated "dead" formats that can be served by static web hosts, so your $USERNAME.github.io could be the front door to your data store—at least the parts of it that you already make available to the public, anyway—then we'd have passed the chicken-and-egg stage years ago and Solid would already be a runaway success. At the end of the day, it's supposed to be about data, after all—linked data—and not about the endpoints/servers themselves. Compare to the ease of creating an RSS feed for your blog (you can get your static site generator to spit one out pretty easily) and contrast it to needing to provision and actively administer a Mastodon server, for example.

walterbell 6y ago
> "dead" formats that can be served by static web hosts, so your $USERNAME.github.io could be the front door to your data store—at least the parts of it that you already make available to the public Could you share some examples of such data, other than "news" feeds? FOAF, for example? http://www.foaf-project.org/ http://www.foaf-project.org/
- cxr 6y ago
  Inline annotations[1][2], personal patch queues, project notes, bookmarks, calendars, photo galleries, reading lists, media trackers[3], anything you might think of dumping into a Gist or other pastebin-style site, anything you might think of dumping into a hosted TiddlyWiki, and so on. I.e., most of the type of data that Solid pods are already meant to handle, really (except served statically, without the POLP-violating[4] architecture that exists in Solid's current design). 1. https://hypothes.is https://hypothes.is 2. https://www.w3.org/annotation/ https://www.w3.org/annotation/ 3. https://noeldemartin.github.io/media-kraken/ https://noeldemartin.github.io/media-kraken/ 4. https://www.w3.org/2001/tag/doc/leastPower-2005-12-19.html https://www.w3.org/2001/tag/doc/leastPower-2005-12-19.html