Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial process upgrades for Multiformats registry group and org #65
Initial process upgrades for Multiformats registry group and org #65
Changes from 12 commits
bf8c973
77007bb
5a365ef
5eab8d0
6a703d7
924721b
fc4f4e8
8b00470
9e53696
05887e9
f322d3e
ff1f407
6c19228
1ab4da9
2ea1271
87d1427
0d5ccdc
f8b38ef
f37b62e
dab4d59
f75eb98
e4064af
40bff07
edecea2
4644edd
8e6d769
9bd83ec
963024d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The table below is badly outdated, it even refers to things that were renamed a long time ago. Also "captain" was used in early Protocol Labs days. I think only multiaddr, multibase and mutlihash should be listed here. multicodec these days it just the "multicodec table".
This might be out of scope for this PR, but I thought I mention it though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: would it make sense to just MOVE the multicodec table into this repo and call it the multiformats table or call it the Registry Group table, since that's the IETF term for that kind of meta-registry? I'm not sure there should even be a "multicodec" repo or spec if the multiformats WG manages all the repos/registries and the multiforamts spec is the meta-registry spec...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might also be good as part of this clean-up to enumerate the values available for the
tag
column, if the process for new registries moves into an IANA-friendly spec here... I'm having trouble understanding what is what thereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the "multicodec table" would be a huge change. Many people would need to be asked if they think it's a good idea. In case we do that, we would need a new name for the concept the multicodec table represents. Would it then be "Multiformats identifier"?
I'd say such a change is outside of this PE (as this is more of a cleanup) and should be discussed in a separate issue/PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's totally unclear. The tags grew organically, some things even have the wrong tag/some tags don't even make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💭 this is the first time I hear about this 😅
the linked repository is archived and ipfs/specs#123 (comment) suggests we should not include it here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd be +1 to removing this if no one speaks up soon. note that the IETF WG proposal does NOT include any mention of it, and it has an explicit clause that "no new multiformats" can be added at least until re-chartering...
https://datatracker.ietf.org/wg/multi/about/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
multistream-select might still be a thing, so it might make sense to keep it here. @marten-seemann or @mxinden might know more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the ping. I suggest not standardizing multistream-select. I think it is very libp2p specific. If one would want to standardize a protocol negotiation protocol, I suggest starting from scratch similar to libp2p/specs#349.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we include this as a "standard" here, since there is wip to supersede it?
libp2p/specs#349
cc @mxinden / @marten-seemann for thoughts:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that "multistream" and "multistream-select" are NOT named in the charter and could NOT be added later without a re-charter if the current WG charter draft is ratified next month as currently written:
https://datatracker.ietf.org/wg/multi/about/
I hope someone speaks up if multistream should be put back in scope, or if any other multi- project that I don't know about needs to be in-scope for the WG to protect its range of values in the mega-table. If there is no protocol spec BUT there are multistream-select entries in multicodec, we gotta put our heads together and figure out how to keep them there with a minimally-viable spec or placeholder for one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing some context. I don't think
multistream-select
should get standardized through the IETF. I don't think it is worth the effort, both given that it is very libp2p specific and given that its design is dated and worth a complete redesign.