Contact me on Tilde.Chat to exchange banners!
SSB Log Entry 617
Pigeon Protocol Daily Update
Note to folks just tuning in: I do daily updates related to #pigeon-protocol - a project with similar goals to SSB.
Responses to Yesterday's Stuff
I like this a lot. The problem I have with
It's the whole thing, so SIGIL + LONG_STRING + ".ed25519" in this use case.
I thought this also. Very early versions of Pigeon did exactly what you are suggesting. After a while, it became unwieldy from the developer ergonomics perspective (and developer ergonomics are a big goal for the project). Next, I tried URL safe base64, much like SSB, but found that there are still some places you can't put URL safe Base64 (such as FAT16 filesystems). Next, I tried RFC4648 Base 32. It had problems, but I didn't keep a developer log back then, so I already forgot what the issue was. Needless to say, I remember it was troublesome.
Ultimately, I settled on Crockford Base32 and I think it is the best compromise between the simplicity of hex and the compactness of Base64. I've had such a good experience with it, I will probably use it on future unrelated projects. Highly underrated.
That's the use case I care about most. I was imagining a developer combing through large swathes of multihashes while debugging a live application. This falls under the umbrella of developer ergonomics. I'm sure end users will be looking at multihashes also, for example, copy/pasting and sharing. To those end users, it's going to be a long illegible pile of text regardless. It will be the responsibility of the application developer to pick the correct rendering method in those cases. On the flip side, the folks who are going to be looking at 10+ multihashes in one screen will almost certainly be doing so from a text editor or terminal, and I don't know any folks running non-monospace fonts in those environments.