A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5 年之前
1234567891011121314151617181920212223242526
  1. title: What do you think about Solid? · Issue #36 · staltz/ama · GitHub
  2. url: https://github.com/staltz/ama/issues/36
  3. hash_url: 20ad52f89821eb819dd6dc8ef022f6e7
  4. <p><em>Hi <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=594955" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/DavidMihola">@DavidMihola</a>! Thanks for asking. I'll aggregate a few other answers I've given in other occasions and then make this post my main answer to that question.</em></p>
  5. <p>I think that the more decentralized protocols we have, the better. One of them will work out in one specific way. I don't think there is supposed to be competitors at this point, and because they are <em>open</em> protocols for decentralization, it means we can build interoperability between them.</p>
  6. <p>About Solid itself, I think it is a <strong>spec-first</strong> approach. They took 15 years to write the spec, and now they're saying the community can begin building the apps. The approach in Scuttlebutt is the hacker way, it's a <strong>hack-first</strong> approach. It began in Node.js, and many of its modules were proof of concepts that had to evolve to become more production-ready, and only now that it's validated, we are spec'ing it on paper. It has worked well to make things happen, and see if people are actually going to use it. I would prefer the hack-first spec-later approach, while Solid is doing the opposite. It could work either way.</p>
  7. <p>That said, 15 years in spec is a <em>very long time</em>, the world back then barely had social networks and mobile phones were Nokia phones. People were giggling about the prospect of 1 megapixel cameras on their phones. If you look at the seminal article from 2003 that inspired Solid, they mention the <a href="https://readwrite.com/2003/04/19/the_readwrite_w/" rel="nofollow">the read-write web</a>. In my opinion, the read-write web is already perfectly embodied in the Beaker Browser. And Beaker is working software, with a self-growing community.</p>
  8. <p>But Solid is very different to Beaker. It's centered around this pods concept that you install on some server to you hold your data. What about easily writing on the web? How does Solid answer that? The answer seems to be through apps that access my pod data, but it's not justified why is that a good idea to begin with. And the approach to identity is in my opinion outdated. Nowadays with cryptocurrencies and p2p protocols (like Dat or IPFS or Scuttlebutt), identity is a cryptographic keypair, yet that's not the case in Solid:</p>
  9. <blockquote>
  10. <p>This uses OpenID Connect to give you a WebID. It involves signing in with a password at your chosen identity provider, such as (2018/2) solid.community, or solidtest.space.<br/>
  11. – <a href="https://github.com/solid/solid">from the Solid readme</a></p>
  12. </blockquote>
  13. <p>So you need to <em>sign up</em> with an identity provider, using an old-fashioned username+email+password flow. Typically one of these few cloud providers hold that responsibility <a href="https://solid.github.io/solid-idps/" rel="nofollow">https://solid.github.io/solid-idps/</a> As such, I don't believe Solid is thinking correctly about offline decentralization (like Scuttlebutt) or interplanetary decentralization (like IPFS). The cloud requirement doesn't end there, it continues with storage:</p>
  14. <blockquote>
  15. <p>Solid infrastructure, including the solid.community pod provider, to a safer and more reliable cloud infrastructure on AWS.<br/>
  16. <a href="https://solid.mit.edu/" rel="nofollow">– from the MIT homepage</a></p>
  17. </blockquote>
  18. <p>So having both identity and storage in these cloud providers is an assignment of heavy responsibilities to those. It's looking much more like federation and less like full decentralization. In other words, federation is closer to centralization, and in the long run easier to centralize (think how Gmail took over email, a federated system).</p>
  19. <p>And the apps, where are they, beyond just the prototypes? 15 years in development, maybe they have one app by now? Not really, they seem to be asking the community to do it.</p>
  20. <p>And the project isn't that well run. You would think that the <a href="https://solid.mit.edu/" rel="nofollow">MIT homepage</a> is the official one since it's been running longer, but they now just announced their <a href="https://solid.inrupt.com/" rel="nofollow">new official homepage</a>, which is not an MIT thing anymore, but run by a new company. The link between these two pages is not obvious and not clearly communicated.</p>
  21. <p>And their value proposition on the new website is honestly weak. It's not about the protocol itself, it's about Sir TBL, 15 years in spec, and the promise of apps in the future.</p>
  22. <blockquote>
  23. <p><strong>Welcome to Solid</strong><br/>
  24. Solid was created by the inventor of the World Wide Web, <strong>Sir Tim Berners-Lee</strong>. Its mission is to reshape the web as we know it. <strong>Solid will foster a new breed of applications</strong> with capabilities above and beyond anything that exists today.</p>
  25. </blockquote>