Mauve 👁💜 @mauve@mastodon.mauve.moe

@cblgh We're going to be starting with IPFS based apps for this iteration, but I'm hoping to get a bigger grant from FFDW afterwards to fund work on apps with other protocols like hypercore and Earthstar. Probably also do more work on Agregore Mobile as part of that too.

Also! The cool thing about this is that our apps might be compatible with @capyloon which is also incorporating IPFS protocol handlers into their stack!

@cblgh We're going to make a bunch of small #p2p web apps for @agregore and write up tutorials for how to make those apps.

We're going to do three sprints with 4 devs making apps+writeups on those apps. So potentially we'll have like 12 little apps to play with and tutorials on how to make them.

Also going to write retrospectives on what we learned about usability and needed improvements at the end of each sprint. 😁

https://github.com/ipfs/devgrants/blob/09f85b347268ad292db25872815f9701ed6ea25f/open-grants/open-proposal-agregore-web-demos.md

@yhancik@octodon.social The browser part is actually a lot less effort than my client work since the feature set is so minimal. 😅

But yeah no clue how I get any of that done. Probably borrowing form my future lifespan or something.

Honestly, I'm amazed when I'm able to get anything done. ADHD makes it so difficult to do even the most basic things like feeding myself so anything I manage above that feels like a miracle. 😅

Writing grants and getting them approved + getting everything signed is such a pain in the ass, but it feels nice to get the final bits together and to get started on the work!

@jauntywunderkind420@cybre.space have you seen the work @cblgh did on Trustnet? Subjective moderation in decentralized systems is cool af.

https://cblgh.org/trustnet/

@whoisgina god, flashback to when I finally got Chromium compiling. Build tools can take so much energy sometimes. 😭

@J12t@social.coop awesome idea, I should start doing that

@GeeksLoveDetail Vibes wise it very much feels so. 😎 Defs not an objecive statement tho

Mastodon is like if twitter was tumblr

@thisismissem Kinda, it's got its own data model, but one can certainly represent rdf data in it with jaon-ld or some more abatract encodings. That's one the things I want to work on. Making a direct bridge betwewn rdf and ipld so we can take advantage of both ecosystems

Here's a cool example I just got working.

The data here is being represented with a single array of strings, but the schema can expose it as a Map where the array is split into tuples.

Your application can say `{op: 'add', path: '/Goodbye', value: 'Cruel World'}`, and IPLD can find where in the array that keypair is, update it, and save the IPLD data back in the tuple form. That way you can avoid having to find the array index for your tuple entirely!

https://github.com/RangerMauve/js-ipld-url-resolve/blob/initial-patch/test.js#L230

@thisismissem Honestly the problem is that right now the IPLD docs suck for beginners, and the tooling is mostly around Golang and a bit in JS (almost nothing in Rust / everything else).

It's something I want to get PL to fund work on some time early next year.

So I guess messing with Go-ipld-prime and reading the docs would be a start? else I'm playing with this stuff in my repo here: https://github.com/RangerMauve/js-ipld-url-resolve/

Tl;dr IPLD lenses make it easier to work with data at the application layer while giving you hatches to optimize encoding and to use more advanced data layouts.

This is important for structured linked data in p2p systems where otherwise you'd need to manually write code to work with all these use cases. With IPLD you can think about schemas for your data, pathing over those schemas, and using patch operations on your schema'd data without needing to worry about the details.

The savings on readability grow larger and larger as your underlying data becomes more nested.

It's a lot easier to work with a path like `/foo/bar/baz/fizzbuzz/` than it is `/12/44/a/0/`.

This applies even more so for advanced data structures like HAMTs or Prolly Trees where an individual segment in the path could actually be a traversal over several nodes in the tree due to their multi-block structure.