You are reading content from Scuttlebutt
@Anders %bMYC966xWTKcagqz37wQJsomz4nB8KELEUFGzo8BMMw=.sha256
Re: %o+3XFaGO6

@Aljoscha good input. Thanks

So do I have to wrap these in an bipf buffer (of tatically known length, nonetheless)

Yes. One could have just directly concatenated the bytes of the values, it would save a few bytes, but since we would like to use bipf for content anyway I wanted to keep this uniform.

Or do I still have to check that they contain the only valid - i.e., completely pointless - byte pattern?

Yes. I would like that the values makes sense on their own. This format is not designed to be as minimal as possible. #tinyssb is a good example of pursuing that.

sequence: number for this message in the feed
Which data type is this? How is it encoded? "number" is not a bipf type.

Thanks that is good input, I have clarified that now.

timestamp: integer representing the UNIX epoch timestamp of message creation
This is a bipf int (32 bit) I assume?

That was a bug in the spec. Its encoding as a double. Fixed now. Thanks

Please specify what an implementation must do with unknown tags.

Good input.

Any change that allows other starting bytes would be a breaking change, i.e., a whole new format

Or a minor update to support a new hash

The content is a free form field. When unencrypted, it SHOULD be a bipf-encoded object.
Please specify what implementation must do when it is not a bipf-encoded object.

Good input.

Join Scuttlebutt now