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.

DONE

Today was mostly spent in Regex hell as I try to figure out why my lexer is crashing on bad input.
I removed a bunch of dead code and cleaned up various parts of the codebase.

TODO

Decide on the new sigil format (Thanks for feedback @kas, @Gaffen - my responses are below)
Fix the lexer crash issue
Continue writing documentation

Responses to Yesterday's Stuff

@gaffen: Hmm, text?

I like this a lot. The problem I have with post (which is still under consideration) is that it seems a bit too focused on social apps.

Multihash, is that the part between the sigil and the extension?

It's the whole thing, so SIGIL + LONG_STRING + ".ed25519" in this use case.

@kas: does it matter? I have never quite understood why base64 was chosen over plain hex

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.

@kas: That statement is only valid when using a fixed-width font, isn’t it?

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.