draft notes
timestamp commit-id -> change-type element-id data mtime -> last-commit-id
change-type: 00/create 01/delete 10/update
write, read, inactive, proposal
decay: integer
if they receive similar ni, they decide for similar purposes
ni serialisation, is cached
one btree per record type or all types in one btree
leaders and followers, leaders can themselves be followers to at most one leader
too big. duplicate id generation should not be catastrophical