Proposal: rename repo to multicodec-table

[vmx]

"Multicodec" is a really overloaded term. Some people working om multiformats started to refer to "Multicodec code" instead of just "Multicodec" to describe the idea of a global table of codes. Hence I propose renaming this repository to multicodec-table and encourage everyone proving this table in various programming languages also to name it "multicodec-table" and not just "multicodec". Each entry of the table isn't a codec, but a code.

Pinging various folks for feedback: @rvagg @Stebalien @aschmahmann @bumblefudge, but of course everyone else is welcome.

[rvagg]

I'm relatively indifferent other than introducing friction for people. As long as existing URLs continue to work then I don't think it would be a problem. I'm just not sure that it will be consistent. I'd want these two to redirect to a new repo:

• https://github.com/multiformats/multicodec/blob/master/table.csv
• https://raw.githubusercontent.com/multiformats/multicodec/master/table.csv

My hunch is that the first one will redirect but the second one may not.

[bumblefudge]

unlike Rod im more supportive than indifferent of the original idea, and will steal this idea in next version of ietf docs, but I share Rod's concern for linkrot. let me dig around in github docs and validate rods hypothesis

[ribasushi]

If your objective is to:

describe the idea of a global table of codes

It stands to reason that the name you want is multicode table.

codec, with a c, is itself way overloaded and overused term in the PL-tech space.

[vmx]

It stands to reason that the name you want is multicode table.

That's a really good point, that's even better. What do others think?

[rvagg]

Sorry, I have to disagree with "multicode table", that ship has sailed long ago and it exists as "the multicodec table" in a very large memespace. If we were starting from scratch today then that'd be great to add clarity!

Not a blocking disagreement though, if others agree then I won't stand in the way, just noting that that's a difficult to push a rock up.

[bumblefudge]

• https://github.com/multiformats/multicodec/blob/master/table.csv
• https://raw.githubusercontent.com/multiformats/multicodec/master/table.csv

My hunch is that the first one will redirect but the second one may not.

Taking inspiration from this post which tested redirect behavior of milestone/package-release artefacts post-rename, I tested your hunch from a free-tier org of my own by creating repo testing.123, uploading a PNG file, then renaming it to testing.456. this link at the pre-rename path still seems to resolve to this image without an HTTP-code 301 redirect (i.e. my browser's location bar still shows the pre-rename URL, it is not changed to 456). So maybe that's one less side-effect to worry about?

Sidenote: reading between the lines of various threads about redirect behavior, it would appear they store something kind of like symlinks permanently at old org/repo names, rather than do HTTP redirects properly speaking, but that's just a hypothesis.