ssbc / bendy-butt-spec Goto Github PK

Quote:

Why a new feed format, when we already have gabby grove and bamboo?

Because we would want to offer a feed format that is simple and easy to implement in any programming language by reusing an established format (bencode) with existing encoder libraries.

There are so many "encoding religious wars" that it seems wise to separate this at the text level from the discussion of the (logical data structure) format needed for new feeds, instead of glossing over it in one sentence.

I note that the CBOR standard easily fulfills and probably exceeds the claims made for bencode ("established", "existing libraries"), so more arguments would be needed here, because bencode has shortcomings for sure.

Adding with SSB-BFE yet another binary encoding (instead of re-using CBOR or bencode for the structured ID data) also needs some hard justification - especially as falling back to fixed-width fields is exactly what above encodings wanted to overcome ...

It would be good (and best practice) to explicitly encode the signing algorithm into the payload to be signed. See JOSE or COSE

I also suggest to spell out , in your description of BendyButt, the signing algorithm, ideally using an established name and format from the RFC world, and avoid referring to a specific implementation as a way of defining it.

Update TFK with new feed format + box encoding.

Item 4 in the specification mentions:

timestamp, a 32 bit integer representing the UNIX epoch timestamp of message creation.

If the integer is signed, this allows only a further ~16 years until UNIX epoch timestamp wraparound, which for a purposely long-term format I assume is an issue. (If it's an unsigned integer, it extends it until 2106, which may give "sufficient" additional time for the life of the format.)

Bendy butt spec specifies content as:

content an array of a dictionary encoding the data relevant to the meta feed and a signature. The signature is the concatenation of the string 'metafeeds' encoded as bytes and the bytes of the content payload, signed using the private key of the sub feed. If content is encrypted this will also be encrypted as a binary SSB-BFE encoded box2 message

Content is written as Bencoded list of dictionaries but, the example on the page makes it look like a JS object. This can lead to the misunderstanding that the content is JSON inside a Bencoded message. It might be beneficial to add a word or two clarifying that that is not the case.

1. define sequence as varint (the one we already use in bipf, i'd say)
2. define that previous for seq:0 is an empty message tfk (so zero bytes instead of nothing)
3. i'd move timestamp inside message content, if possible
4. content is encoded as bipf, too, i guess?
5. signature and content signature? why?

Now that we moved away from bipf as the encoding, this needs a new name. bipfy badger will be way to confusing if it's not using bipf.

Personally, I like boring butt. It also abbreviates nicely to bb. It follows the lineage of boring ssb (using existing tech).

since we use a binary format now, does the nonce really need to be base64 encoded?

We only have a happy path vector file. To make it easier for implementations to harden their verification rules we should also make some with broken/invalid messages.

These might include:

• invalid author formatting
• invalid previous formatting (type, length, ...)
• wrong previous hashes
• broken signature(s)
• wrong sequence numbers
• too long messages
• given that this format is supposed to be just for metafeed managment, broken content

I'd also wager it's better to have these as a seperate file to keep the "good" vector file less complicated.