Contact me on Tilde.Chat to exchange banners!
SSB Log Entry 747
Pigeon Protocol Daily Update, June 3rd 2020
Note to folks just tuning in: I do daily updates related to #pigeon-protocol - a project with similar goals to SSB.
In attempting to write my own SSB implementation, I noticed that JSON was so flexible that it allowed a lot of room for error. It also allowed the use of arrays and nested objects, which led to things like "dot.notation.to.access.stuff", which I didn't like from an ergonomic standpoint.
The world has a lot of serialization formats. JSON is ubiquitous and well understood. Despite this, I felt that SSB's use of JSON was not a win for discoverability or comprehension. One of the things that has made JSON so popular (and basically the first choice for most projects) is its flexibility. There are no schemas, the delimiters only take up a few bytes, there's no "XML tax" to pay with opening/closing tags, stuff is infinitely nestable, etc…
For a use case like cryptographic signing, I would argue that flexibility is bad and attracts human error while increasing the difficulty of implementation for third party devs.
For those reasons, I decided it would be best to give Pigeon its own serialization format. I wanted to re-invent the wheel with the hopes of creating a round one (quote stolen, sorry not sorry).
With that being said, I think, if this idea is worth pursuing at all, the INI file format is the closest thing to what I want. TOML looked good, but I did not take into account the infinite nesting / array parts of it. It would need to be a strict subset of INI, however. I would not want to allow arbitrary use of whitespace, or the addition of comments which inevitably creeps into out-of-band schemas.
With that, I think I might not investigate third-party serialization formats. Interested to hear feedback, though. Especially if anyone knows of a format that fits the requirements and would reduce the amount of work required to author a third-party pigeon implementation :thinking_face: