Iterate on requirements/cornerstones #148
Conversation
We definitely need these concise definitions of goals (and nongoals; if anything, I think we might do well to have more of those!), but we have indeed refined a few things in the last 8 months or so. This is mostly addressing the huge batch of comments I left in the vicinity of #146 (review) . Particularly tricky is that some of our most interesting and useful ideas over the past few months *relax* some of the rules -- and so we need to carefully come up with a way to describe that: it is mostly recontextualizations consistent with the same underlying philosophies... but boy is that hard to express in text sometimes!
warpfork
force-pushed
the
renovate-requirements
branch
from
cd0aa82
to
bea80f7
Compare
There was a problem hiding this comment.
I really like where this is going, good work. Thanks @warpfork (and @Stebalien for the original doc).
|
|
||
| **Motivation:** IPLD needs to be easy to reason about. | ||
| ### Moving beyond local reasoning |
There was a problem hiding this comment.
Good idea making putting those things into a new section.
| stability now requires more: holding the Schema declaration. | ||
|
|
||
| Note that regular, core Data Model still maintains stable pathing even in these | ||
| examples of higher level systems with alternative rules. |
There was a problem hiding this comment.
The original sections all have a "Motivation" which I quite like. Here the motivation could be about different views on the data like IPFS is doing it with UnixFS.
There was a problem hiding this comment.
Good idea. I should keep that up.
| concepts, etc -- we can still have replication and hashing and DAG traversal | ||
| and all the rest of the important promises of the IPLD Data Model regardless of | ||
| that other context, meaning these systems are purely value-add and do not | ||
| compromise any of the other core promises of IPLD. |
There was a problem hiding this comment.
A possible "motivation" could be building higher level data structures (like HAMT) on top of the core IPLD Data Model.
| * Path: A paths a human readable pointer to an IPLD Node. | ||
| Many nodes can exist encoded inside one Block. | ||
| * Link: A link is a kind of IPLD Node that points to another IPLD Node. | ||
| * Path: A path is composed of segments which each specify a step across an IPLD Node. |
There was a problem hiding this comment.
I am struggling to grok a step across an IPLD Node. How does one step across a point? Would it be more accurate to say step between IPLD Node(s)?
There was a problem hiding this comment.
Actually, I think it just clicked.
A Node is:
(A)
A Link is:
(A) -> (B)
^
Link
A Path of /A/B/C represents:
(A) -> (B) -> (C)
|_____________^
^
(B) gets stepped over
So maybe step over IPLD Node(s) is a better way of saying this. @warpfork?
There was a problem hiding this comment.
Yeah, I agree, this bit of text struggled. "between" might do better.
I'm not sure about that diagram, because it's not necessary that it be a link in-between; rememeber that a whole tree of Nodes can be in a Block.
Maybe I should also break this down into bullet points for "Path" and "Path Segment", and that might help? E.g. one Path Segment moves from one Node to the next (but only can describe movement of a single stride: e.g. looking up one map key, or stepping into an list by index). A Path is just a collection of Path Segments, which we often use to describe a walk of a specific, er, well, path down a Node tree.
There was a problem hiding this comment.
Made another shot at this in: #152 -- does that one seems clearer to you?
There was a problem hiding this comment.
@warpfork Much better, made a note on a slight clarification.
| @@ -31,54 +28,89 @@ IPLD but there needs to be an immutable layer at the bottom. | |||
| **Motivation:** *Having* an immutable layer is important for a lot of analysis, | |||
| memoization, type checking, etc. | |||
|
|
|||
| ## Multicodecs Are Not Types | |||
| ## Multicodecs Are Not Meant to Act As Types | |||
There was a problem hiding this comment.
This is great. Probably the most concise text I’ve read so far on “why you don’t need to write a new codec.”
Recently, I’ve run into some areas where I legitimately did need a new block format and codec for an application specific use case. Until I read this I didn’t have great language to distinguish why this case was different (it wasn’t about types, the motivation was compactness and limiting dependencies).
There was a problem hiding this comment.
Heh... Yeah, we could almost make a "## Multicodec nonproliferation treaty" and put this motivation hunk under that. "Multicodecs are not meant to act as types" could just have a "see above" for its motivation.
This extracts some content from #148, and regards earlier review in #146 (comment) and #146 (comment) . The example is also substantially rewritten, to attempt to clarify two things: that it's a *negative* example (!!), and also to make it more obvious what we're proposing is a link (since the dag-json syntax isn't introduced anywhere in this immediate vicinity, and it can be a bit non-obvious what's going on if that wasn't in your mind's eye already as you were reading). This addresses #146 (comment) .
|
Alright, closing this one -- It's stale, and it's been broken up into smaller PRs in... well, all the other PRs that can be seen referencing this one lately. |
This extracts some content from ipld#148, and regards earlier review in ipld#146 (comment) and ipld#146 (comment) . The example is also substantially rewritten, to attempt to clarify two things: that it's a *negative* example (!!), and also to make it more obvious what we're proposing is a link (since the dag-json syntax isn't introduced anywhere in this immediate vicinity, and it can be a bit non-obvious what's going on if that wasn't in your mind's eye already as you were reading). This addresses ipld#146 (comment) .
This is mostly addressing the huge batch of comments I left in the
vicinity of #146 (review) .
Some of this text might be good; some might need more iteration. In particular I also didn't yet make any thrust at addressing the "IPLD is about (Declarative) Data" key concept, which is absolutely one of our critical cornerstones that underlies all of these other points. I would still like to try to make this more explicit, though; help wanted.