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.

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.

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

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}`

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.