Mauve 👁💜 @mauve@mastodon.mauve.moe

@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.

E.g. you can have a struct that looks like this:

```
type Foo struct {
foo String
bar Int
} representation tuple
```

Note the "representation tuple" bit.

In your application you can refer to this data using something like `{foo: 'hello', bar: 1337}`, and then on disk it can be encoded to `['hello', 1337]`. (saving you some precious bytes).

This also means you can have a patch that looks like `{op: "replace", path: "bar", value: 666}` instead of `{op: "replace", path: "1", value: 666}`

This is really interesting when you combine it with other IPLD tooling like pathing and patch.

You can use schemas to transform data as you're pathing over it so you can use human readable names for path segments while keeping the lower level data compact.

On top of that you can use the more human readable structures and paths for patching data in a schema'd node. So instead of saying "change the properly deep in this mess of nested lists like" you can say "set foo/bar to 123".

This is really useful with for example IPLD Schemas where you can have "representations" of data use more compact encodings like tuples where you can omit any property names, but have the schema "wrap" over the underlying data to add properties. Then you can "unwrap" the schema'd data to get the "substrate" to encode back into bytes and link to.

IPLD lenses are really underappreciated.

At it's core, IPLD gives you a way to turn data in memory into determenistic encodings in bytes, and then convert that to a Content IDentifier which you can use as links from other IPLD data.

However, on top of that is the concept of "lenses" where you can wrap an IPLD tree in some sort of code that transforms how it looks to code, while still having the same substrate.

@codepo8 I use my own which can detect and display links to IPFS when loading IPLD URLs. 👀

https://github.com/AgregoreWeb/extension-agregore-renderer

Been reading Gideon the Ninth and it's spooky fun

One of the interesting things (derogatory) about chatgpt is that a lot of people don't seem to get that it's function is to predict text tokens. Often they end up assuming it has some sort of rich reality that it inhabits when you're not asking it things.

E.g. a lot of folks in the comments of this thread are having trouble grasping that it's making up the HTTP responses based on training data and assuming that it's actually making requests.

https://www.engraved.blog/building-a-virtual-machine-inside/

@thisismissem Yeah! I've tried doing it for things in the past. Glad to hear react-router is taking it seriously, that should yield benefits to loads of apps without extra dev thought put into it. 🙇

@makeworld Yeah, the three column thing is cool, but I personally prefer to use smaller windows with a bunch of windows open at once.

That way I can arrange stuff spatially on my "ultrawide" display. I generally just like mobile view sized windows for that reason, and it also irks me that a lot of sites aren't responsive for that form factor. 😅