tags: technology tracker bbnet
get in tune with the source
bbnet is something that i've been dreaming about for a long time. i started with a rlog recently after reading a bunch of discussion about log formats and some ideas about the future of secure scuttlebutt. it took me about a week to put together the proof of concept in my spare time. i've since worked on some revisions to the log format on paper.
a text-based replicated log format using concepts borrowed from secure scuttlebutt and bitcoin. each field is base58check encoded. Base58Check has the following features:
- An arbitrarily sized payload.
- A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
- One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05, rlog will use another?).
- Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
- An extra step for preservation of leading zeroes in the data.
each log entry has the following format:
- `key` is a sha256 sum of the remaining fields
- `sig` is a ed25519 signature of the remaining fields
- `ts` is a unix timestamp
- `index` is the sequence number for this log. the first entry of a logbuffer indicates its length
- `prev_key` is the sha256 key of the previous log entry
- `message` is value of arbitrary length. the first and last entry of a logbuffer is the key of the next and/or previous logbuffer.
this is the general datatype for bbnet records. TYPE is a label or schema identifier. LENGTH indicates how many bytes until the end of the record. this information is used to quickly validate the structural integrity of the database. entries are separated by a newline character `\n`, but it isn't polite to send unbounded messages.
the special log entries (256 and 1) should use TSTLV records in the message field to indicate some information about the key type used to sign the log. L1NK fields include the full public key, NOT a hash. other field types are possible, but keep in mind that rlog doesn't care about the shape of your data. these records are not very expressive, if you find yourself creating elaborate TSTLV schemas, you should consider indental or tablatal instead.
for starters, gemini uses TLS and adding anoher crypto library seems excessive. additionally, TLS is much more common and easier to stealth. most platforms (including embedded) that are capable of cryptography have at least one TLS stack available. these aren't the most elegant pices of software, but they are ubiquitous and well understood.
the next rlog iteration will use ecdsa keys to sign messages. might be neat to use ssh keys as the canonical key format. regular TLS certs are also fine. clients are free to select any signature scheme that is compatible with the TLS stacks of the intended recipients. just make sure to negotiate the record type ids out of band, reccomended schemes will have ids assigned by the spec.