Initial process upgrades for Multiformats registry group and org #65
Conversation
bumblefudge
changed the title
|
(Please squash before merging, the repo does not need my 10 ugly commits in here for posterity) |
|
Thanks for raising @bumblefudge . The lack of response here is more just timing related than lack of interest in seeing this move forward. I have this on my list to look at, but please don't block on me if I don't get to it. |
|
Thanks for saying that! As a European I'm entirely accustomed to my July PRs getting discussed in September, so perhaps I'm to blame for not having a new internet-draft in time for IETF 117 😅 . I'll prepare one anyways and host it personally, for discussion purposes if anyone wants to see progress at IETF, but I am thinking it would not be fair to Rod and Volker to deploy it in IETF's version tracker on behalf of PL for lack of definitive consensus. |
README.md
Outdated
|
|
||
| - [multiaddr](https://github.com/multiformats/multiaddr): network addresses | ||
| - [multibase](https://github.com/multiformats/multibase): base encodings | ||
| - [multicodec](https://github.com/multiformats/multicodec): serialization codes | ||
| - [multigram](https://github.com/multiformats/multigram): protocol negotiation and multiplexing over datagrams | ||
| - [multigram](https://github.com/multiformats/multigram): protocol negotiation |
There was a problem hiding this comment.
💭 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.
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/
README.md
Outdated
| Several of the multiformats are stable, and we're working on the others. We are trying to prioritize their usage as soon as possible. What they offer -- protocol interoperability and future-proofing -- would have real-world consequences. | ||
|
|
||
| Towards that end, we are encouraging implementations of these protocols; if you know of any, please link them here (or add them to the organization!). | ||
| - [multistream-select](https://github.com/multiformats/multistream-select): |
There was a problem hiding this comment.
Should we include this as a "standard" here, since there is wip to supersede it?
libp2p/specs#349
cc @mxinden / @marten-seemann for thoughts:
- if we should include "multistream-select" on this "multiformats" list at all? my intuition is it is libp2p-specific and just happens to have "multi" in name.
- if it is generic enough to include here, should we also include "protocol-select" also/instead, since it aims to supersede the former?
There was a problem hiding this comment.
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.
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.
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
There was a problem hiding this comment.
I've also a general note. I saw that the text was reformatted from one line paragraphs to wrapping them. I personally prefer having one paragraph per line as it makes diffing easier. I find it's also easier to contribute as you don't need to pay attention at which magical number the lines need to be wrapped. It's likely that people get it wrong, so you either end up with inconsistencies or you annoy people by such details.
README.md
Outdated
| ## Current Registries | ||
|
|
||
| Currently, we have the following formats, each of which corresponds to a | ||
| specification and a registry. More formats are being discussed and worked on. |
There was a problem hiding this comment.
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.
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.
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 there
There was a problem hiding this comment.
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?
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.
It might also be good as part of this clean-up to enumerate the values available for the
tagcolumn, if the process for new registries moves into an IANA-friendly spec here... I'm having trouble understanding what is what there
Yes it's totally unclear. The tags grew organically, some things even have the wrong tag/some tags don't even make sense.
Co-authored-by: Volker Mische <volker.mische@gmail.com>
Co-authored-by: Volker Mische <volker.mische@gmail.com>
Can fix this going forward, to facilitate easier diffing here. I may have misunderstood hard line breaks to be a requirement of, rather than an artefact of, IETF spec editorial process... |
I've no idea about the IETF spec editorial process. So it could well be a requirement. Though even then it could then perhaps be made as a last step? :) |
done now apologies for the inconvenience! |
|
I followed the pattern put forward in Multibase of moving noisier convos to Discussions (in a separate PR). This is ready to merge now! |
| - [multihash](https://github.com/multiformats/multihash): cryptographic hashes | ||
| - [multikey](https://github.com/ipfs/specs/issues/58): cryptographic keys and artifacts | ||
| - [multistream](https://github.com/multiformats/multistream): stream wire protocols | ||
| - [multistream-select](https://github.com/multiformats/multistream-select): Friendly protocol multiplexing. |
There was a problem hiding this comment.
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.
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.
| Multiformats is the name for the organization, but it can also be used to refer to protocols; for instance, in the sentence "Use one of the multiformats". Formats is interchangeable with protocols, here. We try to capitalize Multiformats when it refers to the organization, on GitHub. | ||
| `Multiformats` is the name for the community (and the "organization" in GitHub's access control model), but `multiformats` can also be used to refer to protocols; for instance, in the sentence "Use one of the multiformats". | ||
| Formats is interchangeable with protocols, here, as each format is designed in tandem with one or more protocols which handle those self-describing values centrally. | ||
| We try to capitalize Multiformats when it refers to the organization. |
There was a problem hiding this comment.
FYI: I didn't know that. I usually capitalize Multiformats in any case as I treat it as a proper noun. But that might only be me. I'd just remove that sentence.
There was a problem hiding this comment.
This note dates back to 2016 according to github "blame"/commit-tracing view. I don't mind either way if we remove it or keep it but I have noticed it was at least internally consistent in the other readmes in this org?
There was a problem hiding this comment.
don't care enough to have an opinion, I'm more triggered by using ` two sentences up around the words, but not enough to object either
| If you want to implement a multiformat in a new language or in a new architecture, open an issue in the main repository for the relevant multiformat: for instance, if you want to write `rust-multibase`, then [open an issue](https://github.com/multiformats/multibase/issues/new?assignees=&labels=implementation&projects=&template=IMPLEMENTATION-ANNOUNCEMENT.yml) in the `multiformats/multibase` repository. | ||
| This will allow others to know that you're working on it, and potentially join in the effort. |
There was a problem hiding this comment.
It should be opened on the corresponding repos, not this one.
There was a problem hiding this comment.
we removed that proposed template; this should just recommend they open a pull request to add their implementation to the README of the project I think
|
ok @vmx finally ready for re-review. sorry for the confusion. the only pending comment is about whether to cut the |
|
sorry for losing so much of the history in the squash merge but there's a bit too much detail and churn in the commits to let them all go in as is; but this is done, well done @bumblefudge and thanks for persisting! |
|
no it's better if posterity doesn't see how bad at git I am 😅 |
Step 1: Process described better here
(Forgive the unverified commits, those were me signing commits before updating my GPG/github setup)
In multibase#109:
base256emojiandproquestto experimental, since the former didn't have a well-documented use-case or adoption documented in threads, and the latter is still lacking test vectors.In CCG repos where IETF RFC Drafts get compiled in XML
draft PRcreated repo that needs to be moved into CCG org later) and previewPossible gameplan for post-merge: