gemini://sunshinegardens.org/

rlog

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.

concept

a text-based replicated log format using concepts borrowed from secure scuttlebutt and bitcoin. each field is base58check encoded. Base58Check has the following features:

base58check

each log entry has the following format:

<key>\t<sig>\t<ts>\t<index>t\<prev_key>\t<message>\n
<key>\t<sig>\t<ts>\t<index>t\<prev_key>\t<message>
       <sig>\t<ts>\t<index>t\<prev_key>\t<message>
              <ts>\t<index>t\<prev_key>\t<message>

REVISION 1

(TAB-SEPARATED-)TYPE-LENGTH-VALUE

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.

<key>\t<sig>\t<ts>\t<index>t\<prev_key>\t<message>\n
RLOG\t<LENGTH>\t<key>\t<sig>\t<ts>\t<index>t\<prev_key>\t<message>\n
<log_key>\n
L1NK\t<LENGTH>\t<log_key>\n

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.

TLS over NaCl (libsodium)

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.

related voice logs

../log/voice-memo/