jonny (good kind)<p>OK I'm starting my <a href="https://neuromatch.social/tags/p2p" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>p2p</span></a> <a href="https://neuromatch.social/tags/LinkedData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>LinkedData</span></a> reading list to get started drafting a protocol and I'm checking out <a href="https://neuromatch.social/tags/IPLD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IPLD</span></a> - lots of really good ideas here, and plenty to learn from. It has a bit of a different focus than what I have planned, but some stuff i like and some stuff I can learn from:</p><ul><li>This <a href="https://gist.github.com/warpfork/28f93bee7184a708223274583109f31c" rel="nofollow noopener noreferrer" target="_blank">typology of complete vs incomplete codecs</a> - I'm learning that one of the major ways I differ in thinking from a lot of prior art is an explicit embrace of heterogeneity, vernacularism, and mess as desirable features of an expressive system rather than designed out by engineer types as an error. I think explicitly allowing for incomplete/imperfect translation between schema is super important for systems of expression, after all it's how language works! So I really liked seeing the "Incompleteness is Valid" section. I also love some of the terminology here, "topowild," "plane-mangling," "underkinded." </li><li><a href="https://ipld.io/docs/synthesis/how-ipfs-web-gateways-work/" rel="nofollow noopener noreferrer" target="_blank">How IPFS gateways work</a> - I have always wondered how this works, and it is a pretty concise access point to seeing why some of the ideas in IPLD are good ones. I like Protocol Labs general approach to bridging across protocols, and being able to access data in <a href="https://neuromatch.social/tags/IPFS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IPFS</span></a> from HTTP is a really important part of how IPFS gets used (eg. by libgen). I want to read more about how other protocols approach (or don't) interoperability like this.</li><li><a href="https://docs.ipfs.tech/concepts/content-addressing/" rel="nofollow noopener noreferrer" target="_blank">CIDs</a> are interesting - - but i ultimately I think they collapse too much information because of how they are intended to be used. It binds the metadata and data to a specific codec, which has attractive qualities, but it becomes clear that they had to do a lot of work around the fact that there is no division between metadata and bytestring/binary data for querying, selecting, etc. Having to expand blocks is not really desirable, and it also is related to one of the bigger problems I see with this approach, which makes data modeling pretty damned complicated having to deal with blocks, models, advanced data layouts, schemas, etc. You can also really see how the blockchain stuff starts to seep into the rest of the ecosystem design starting around here and in adjacent stuff like <a href="https://ipld.io/specs/transport/graphsync/" rel="nofollow noopener noreferrer" target="_blank">graphsync</a></li><li>The <a href="https://ipld.io/design/tricky-choices/" rel="nofollow noopener noreferrer" target="_blank">tricky-choices</a> section is extremely interesting and i wish more projects had something like it. In particular I liked the discussion on why <a href="https://ipld.io/design/tricky-choices/ordering/" rel="nofollow noopener noreferrer" target="_blank">ordering by default</a> is a good decision in graphs/maps that don't necessarily <em>need</em> order. </li><li>The <a href="https://ipld.io/docs/schemas/" rel="nofollow noopener noreferrer" target="_blank">schemas</a> docs are pretty revealing about the direction of the project, values, design priorities, etc. In particular they are "developer"-oriented interfaces, rather than something intended for any old person out there to be able to structure data with. They share some of what I'm thinking about re: structuring existing data, but the combination of the data schema with the serialization has similar points of difficulty as with CIDs. I want to read more about these and ADLs because i dont' have time rn to do but they seem p subtle and worth spending time with.</li></ul><p>I depart from a lot of their design decisions, and it's also clear that this is something that evolved in the process of developing IPFS (they say as much) to fill gaps as they were emerging, rather than a foundational part of the ecosystem. In particular I think the blockchain brain ties them to this notion of immutability, append-only stuff which (imperfectly) trades off with needs for privacy and careful scoping/permissions, valuing verifiability and structuredness above ease of expression, and etc. Regardless, interesting to see a bit of the way they think, particularly since they're a bunch of years ahead of me in dealing with the practicalities of implementation. </p><p>I'm gonna try and do this project in public, writing as I go on here rather than limiting to an end piece, so if u want to avoid future posts like this from me in the future u can mute the <a href="https://neuromatch.social/tags/Longpost" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Longpost</span></a> and <a href="https://neuromatch.social/tags/WorkingInPublic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WorkingInPublic</span></a> hashtags which will be sort of wandering like this.</p><p><a href="https://neuromatch.social/tags/Longpost" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Longpost</span></a> <a href="https://neuromatch.social/tags/Protocols" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Protocols</span></a> <a href="https://neuromatch.social/tags/WorkingInPublic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WorkingInPublic</span></a></p>