SSB Log Entry 610
Pigeon Protocol Daily Update
Done
- Fixed a mistake I made in the Lipmaa link implementation
TODO
- Fix a bug where a message containing
\n in a key causes StringScanner to hang indefinitely.
- Re-order header fields to be more readable
- Cleanup and documentation
IDEAS WELCOME (Naming Things)
Yesterday I talked about how I want to get rid of SSB-style sigils in favor of ones that are URL-safe and human readable. The idea was well received, but there's some disagreement as to what we should use instead of the current sigils.
Right now, we use @ , % , & sigils to represent identities, messages and blobs, respectively.
I had originally proposed changing them to the following:
- Change
@ to feed.
- Change
& to blob.
- Change
% to mesg.
The first two seem to work. The last one was not as popular, mostly based on the feedback that people don't like abbreviating words for various reasons. Eg: makes it harder for non-native English speakers to look it up in a dictionary, and it will act funny in screen readers (though I think the Base32 that follows a sigil would do the same anyway).
I'm not sure what I should use instead of mesg. .
- I don't want to use
message. because pigeon multihashes are already longer than SSB multihashes (52 characters, last time I checked).
- It would be nice if the new sigil is exactly 4 letters long because you can perform string indexing more easily when writing lexers or working in constrained environments / languages with minimal string support. It is also a lot easier on the eyes when multihashes all line up neatly.
- @kas suggested using
post. This is probably what I will use if I can't find a better alternative.
Does anyone have any other ideas? Another alternative I've considered is using single character sigils, such as F for feeds, B for blob, M for message. It's not as readable, but it is more URL safe and only slightly less anglocentric than the current sigils.
I'm open to more ideas. I will probably just go with post. otherwise.
pigeon-protocol
|