In their #DataShards introduction, they mentioned reading the original Tahoe-LAFS paper. While I believe I have read it at some time in the past, I'd like to find it again.
Afterwards, I thought that they stayed too high-level. They mentioned some similar concepts, such as #IPFS and #Tahoe-LAFS, but it felt like talking to a sales person. I'd rather know a little more about how it works.
@cypnk this is *very* old news. Since that blog post was published, the AP 1.0 spec has been officially released, and @cwebber has moved on to #Spritely and #Datashards and unofficially written off MediaGoblin as a dead parrot, superceded by #PeerTube. TBH I'm surprised to see GoblinRefuge still running.
@feonixrift I think there's also an important difference between data exchanged over the net in general, and content published on the web. When things are put on the public web and not maintained, you get #linkrot, which corrodes the value of the web as a medium. The next generation of web tech really needs to build in solutions to this, like #Datashards, where links don't depend on the linked item always being available at the same address. @drskrzyk
My demo with @cwebber for RWoT is ready! It's going to be a live demo with audience interaction)showing two Datashards implementations interacting (one in Racket, one in Python), talking over a network and transmitting URIs out of band.
In the demo we're able to show that you can upload, store and retrieve secret data seemlessly between two independent implementations.
Projects like #DOI (Digital Object Identifier) and #Handle.net have created ways to permanently link to documents on the web, even if their actual URL changes. But like #Webcitation.org and #Archive.org, both are centralized systems, requiring layers of bureacracy and ongoing funding to maintain. #DataShards has been proposed as a way to automate this, in a decentralized and even offline way: https://librelounge.org/episodes/26-announcing-datashards.html
Had a good conversation with @cwebber today. We discussed some #DataShards details, which has resulted in me scaling back some code I was writing (which I guess is a good thing?)
The nice thing about working with @cwebber is that even if I don't agree with them, it feels collaborative.
I still think we have a long ways to go with #DataShards before it's ready, but it's gonna be awesome.