!WBhcGXTDMlzyTPWoJv:matrix.org

Decentralized Web Summit: General

862 Members
Discussion of and around the Decentralized Web Summit conference in SF | https://decentralizedweb.net41 Servers

Load older messages


Timestamp Message
24 Aug 2019
21:15:49@benhylau:tomesh.netbenhylau

Hey Our Networks is happening this September in Toronto -> ournetworks.ca we will also announce a call for zines shortly!

25 Aug 2019
09:16:26@stoically:matrix.orgstoic set a profile picture.
11:53:45@stoically:matrix.orgstoic changed their display name from stoically to stoic.
20:47:15@mwarning42:matrix.orgmwarning42zines?
28 Aug 2019
07:43:20@mamtaya:matrix.orgmamtaya changed their profile picture.
15:46:53@matthew:matrix.orgMatthewhttps://en.wikipedia.org/wiki/Online_magazine :)
15:47:12@matthew:matrix.orgMatthewor https://en.wikipedia.org/wiki/Zine
15:47:17@matthew:matrix.orgMatthewmore accurately
15:57:12@benhylau:tomesh.netbenhylauHere are some examples! https://github.com/ournetworks/2019/issues/52
29 Aug 2019
21:56:20@benhylau:tomesh.netbenhylauAnd here is the official call for zines! https://ournetworks.ca/zine-library/
30 Aug 2019
04:46:04@strypey:matrix.orgstrypey @chrisgebhardt:matrix.org: et al, have any of you looked at Datashards? It's a recent proposal for persistently and reliably addressing both mutable and immutable data, on the web and even offline (eg sneakernet)? Here's the creators introducing it:
https://librelounge.org/episodes/26-announcing-datashards.html
06:05:56@chrisgebhardt:matrix.orgChris Gebhardt strypey I read this doc.. it seems to be their most formal technical paper: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/datashards-rationale.md
06:06:17@chrisgebhardt:matrix.orgChris Gebhardt* strypey I read this doc.. it seems to be their most formal technical paper: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/datashards-rationale.md
06:08:54@chrisgebhardt:matrix.orgChris Gebhardt * @strypey I read this doc.. it seems to be their most formal technical paper: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/datashards-rationale.md
06:09:11@chrisgebhardt:matrix.orgChris Gebhardt * strypey I read this doc.. it seems to be their most formal technical paper: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/datashards-rationale.md
06:11:45@chrisgebhardt:matrix.orgChris GebhardtAs with almost every other project, they've punted on the metadata model, which is a huge mistake. It's the key to handling versioning properly, aka. "mutability" among a system that otherwise uses immutable, hash-referenced data -- as well as the key to making the whole system evolvable. Without an (extensible) metadata model, they've had to design a baked-in versioning scheme that misses a lot of use cases.
06:12:07@chrisgebhardt:matrix.orgChris Gebhardt * As with almost every other project, they've punted on the metadata model, which is a huge mistake. It's the key to handling versioning, aka. "mutability" among a system that otherwise uses immutable, hash-referenced data -- as well as the key to making the whole system evolvable.
06:12:28@chrisgebhardt:matrix.orgChris Gebhardt * As with almost every other project, they've punted on the metadata model, which is a huge mistake. It's the key to handling versioning properly, aka. "mutability" among a system that otherwise uses immutable, hash-referenced data -- as well as the key to making the whole system evolvable.
06:16:32@chrisgebhardt:matrix.orgChris GebhardtThe whole sharding / self-encrypting thing is similar to MaidSafe. This approach is fine as an optimization strategy for a P2P backend implementation, but it isn't a good general data model to bake into the core designs. It doesn't really solve anything anyhow. The rationale of trying to hide the existence of identifiable bad content from hosts is kinda strange. And if you just need privacy, just encrypt your data entities and don't bother with sharding them. (or only shard behind the scenes as a network optimization for large data..)
06:28:14@chrisgebhardt:matrix.orgChris Gebhardt * As with almost every other project, they've punted on the metadata model, which is a huge mistake. It's the key to handling versioning properly, aka. "mutability" among a system that otherwise uses immutable, hash-referenced data -- as well as the key to making the whole system evolvable. Without an (extensible) metadata model, they've had to design a baked versioning scheme that misses a lot of use cases.
06:37:32@chrisgebhardt:matrix.orgChris Gebhardt

I give them credit for not pursuing named or public-key-rooted pointers/paths to mutable data, which I will continue to argue is a horrid anti-pattern. In DataShards, you can still ultimately only reference data by hash. I also give them credit for being the only other project, besides mine afaik, to use a gossipable reference collection strategy to propagate knowledge of versions. OTOH, this are still using the "publisher" model of a distributed registry of authorized versions, protected by a complicated OCAP scheme. This is better than the single publisher scheme of Dat / IPFS PK paths but it doesn't serve open collaboration use cases or support layering of 3rd party data/metadata. And, again, a proper metadata model would have solved all of this in the process. In the InfoCentral model, generalized reference collection is used to discover all sorts of metadata surrounding data entities, not just versioning related and not just from an authorized set of editors.

06:38:09@chrisgebhardt:matrix.orgChris Gebhardt * As with almost every other project, they've punted on the metadata model, which is a huge mistake. It's the key to handling versioning properly, aka. "mutability" among a system that otherwise uses immutable, hash-referenced data -- as well as the key to making the whole system evolvable. Without an (extensible) metadata model, they've had to design a baked-in versioning scheme that misses a lot of use cases.
06:40:20@chrisgebhardt:matrix.orgChris Gebhardt * I give them credit for not pursuing named or public-key-rooted pointers/paths to mutable data, which I will continue to argue is a horrid anti-pattern. In DataShards, you can still ultimately only reference data by hash. I also give them credit for being the only other project, besides mine, to use gossipable metadata strategy for propagating versioning data, whereby there is no singular source of truth in the network. OTOH, they are still using the "publisher" model of a distributed registry of authorized versions, protected by a complicated OCAP scheme. This doesn't serve open collaboration use cases or support layering of data/metadata. And, again, a proper metadata model would have solved all of this in the process. In the InfoCentral model, generalized reference collection is used to discover all sorts of metadata surrounding data entities, not just versioning related and not just from an authorized set of editors.
06:41:46@chrisgebhardt:matrix.orgChris Gebhardt(Sorry about all the edits.. hopefully people's Matrix clients handle this properly. RiotX mobile or the Riot web client seem to work..)
06:43:14@chrisgebhardt:matrix.orgChris Gebhardt * The whole sharding / self-encrypting thing is similar to MaidSafe. This approach is fine as an optimization strategy for a P2P backend implementation, but it isn't a good general data model to bake into the core designs. It doesn't really solve anything anyhow. The rationale of trying to hide the existence of identifiable bad content from hosts is kinda strange. And if you just need privacy, just encrypt your data entities and don't bother with sharding them. (or only shard behind the scenes as a network optimization for large data..)
07:06:12@chrisgebhardt:matrix.orgChris Gebhardt* I give them credit for not pursuing named or public-key-rooted pointers/paths to mutable data, which I will continue to argue is a horrid anti-pattern. In DataShards, you can still ultimately only reference data by hash. I also give them credit for being the only other project, besides mine afaik, to use a gossipable reference collection strategy to propagate knowledge of versions. OTOH, this are still using the "publisher" model of a distributed registry of authorized versions, protected by a complicated OCAP scheme. This is better than the single publisher scheme of Dat / IPFS PK paths but it doesn't serve open collaboration use cases or support layering of 3rd party data/metadata. And, again, a proper metadata model would have solved all of this in the process. In the InfoCentral model, generalized reference collection is used to discover all sorts of metadata surrounding data entities, not just versioning related and not just from an authorized set of editors.
15:09:07@strypey:matrix.orgstrypeyRedacted or Malformed Event
15:09:54@strypey:matrix.orgstrypey @chrisgebhardt:matrix.org:
You have a lot to say on this topic, and you seem to know it well. Maybe putting up a blog post and linking it here might be a better workflow? For you and for anyone (like me) whose Matrix client doesn't handle edits yet ;)
15:11:04@strypey:matrix.orgstrypeyIt would make your detailed comments more discoverable as well eg I could send a link to the Datashards authors on the fediverse.
16:03:23@chrisgebhardt:matrix.orgChris Gebhardt

Yeah, I've been in the distributed systems space since about 2005 or so. Most things look pretty transparent at this point. ("Seen it all before..") I've thought of doing a comprehensive comparison of all these projects, but it's difficult to keep up with them all and some of the differences are subtle enough to warrant long explanations vs a comparison grid, etc.


Show newer messages


Back to Room List