feat: add base256emoji

[Jorropo]

I think this should be merged because :

• It's fun and allows us have an almost endless of fun in docs and trolling opportunities.
• Most of the NFT community likes useless differentiation features, why not giving what they want ?
• It's a good test for unicode based encodings in current implementations.
• It makes for a great education tool about what the spirit of multiformats is about (I found that some new people over sacralise what a CID is, if we allows dumb stuff like that I think it will be helpfull to explain to people that things are really extensible and you can make whatever you want on top of it).
• It's not taking valuable prefix space (the 🚀 preffix is very unlikely to ever be used by anything else).
• Implementations that doesn't support unicode will just error with codec not found (since the first byte of 🚀 is not valid ascii nor unicode it would be wrong from us to use as a prefix).

TL;DR:

I think it has a very slight positive impact and no negative impact, let's merge this. :)

[Stebalien]

Hm. My first thought is that the readme needs some pithy examples.

Other than that ✔️.

[ribasushi]

I love this! A note: you use 🚀 both as "multibase prefix" and as "digit 0", perhaps disambiguating the two is worthwhile 🤷

[Jorropo]

@ribasushi

you use rocket both as "multibase prefix" and as "digit 0", perhaps disambiguating the two is worthwhile

I don't really get why that an issue, whats the rational behind this ?
I believe the only thing we was trying to do is:

• we should attempt to use prefixes that doesn't encode in smaller / alternative bases (which I'm certain to have covered)
• the prefix should be in the alphabet (which is)

Would swapping 🚀 (0) and 🪐 (5) in the table by enough of a fix ?

[ribasushi]

No, I meant have 🚀 mean exclusively "this string is a mojibase encoding" and use 256 other distinct emojis used for the encoding. So all in all you will have 257 defined "atoms". I do not have a solid rationale for this, just feels "cleaner", given you character set is virtually unconstrained.

[Jorropo]

I have two counter arguments :

• I like rockets, the more rockets there is the happier I am. (It's not like it's taking the place of an other valuable emoji that could be represented, see the go impl code comments for emoji rational (btw if anyone has ideas for important emojies to include send it pls))
• Other bases don't do that, most of them use their biggest glyph as prefix. (Here I'm doing the reverse so inlined blocks have at least two rockets (key + identity multihash) because cid inlining is very cool and because all of the collision with smaller base thing is not an issue this time).

[Stebalien]

General emoji choice comments. I'd also consider trying to make emoji's as unique as possible.

(I mean, if we're going to paint the bikeshed, we might as well paint it well)

[Jorropo]

(I mean, if we're going to paint the bikeshed, we might as well paint it well)

The only real usecase I see is NFT artists bruteforcing cool emoji patern for their collection.

So I belive we need rockets and moons.
Then for the rest I've figurated that nft artists likely like the same emojies as the average peoples so I took a top list from unicode's popularity count.

But if anyone has thought thru propositions I'm for it.

[vmx]

I'm also in favour of using an emoji as prefix which is in the set of the 256 emojis

because cid inlining is very cool

It is not and I hope it's used less and less. It causes more trouble then good. The only use case I see is for data where the hash is bigger than the actual data. Though even then you're probably better off with other solutions, e.g. combining some of your data into bigger chunks.

[BigLep]

@Jorropo : are you able to incorporate the input here, particularly around not supported emojis?

[Jorropo]

@BigLep

are you able to incorporate the input here, particularly around not supported emojis?

Yes, at first I didn't really wanted to, but since it seems that everyone think emojies that work is an important thing yes.
It's just really unimportant and havn't attempted to give me time to work on this yet.

[Jorropo]

New fixed version pushed.

Pls could you merge with git merge (not rebase) so the commit hash wont change and go-multibase's submodule wont need yet an other push.

[rvagg]

the most triggering thing about this is the fact that the emoji breaks the fixed-width table:

[Jorropo]

I know sorry (no I love that).

JuST GeT A PROper monO SPaCE FONt.

[Jorropo]

actually I'm one space to short

[Jorropo]

Now actually monospace correct (if you had a monospace emoji it wouldn't break).

[rvagg]

cool, got an implementation for this yet?

[Jorropo]

yes multiformats/go-multibase#46
I'm just cleaning it up and also applying the requested changes, I'll push there soon

[Jorropo]

multiformats/go-multibase#46 is now ready for review too.

On my side it's RFM

[rvagg]

Merge commits really grind my gears .. but since you insist and there's recent precedent in this repo I'll hold my nose

multiformats/js-multiformats#187 for JS impl