@keks

You could hack flumelog-offset to add a field of bits per message (e.g. 1-8 bytes) and use one of these bits to say "this message was deleted".

Do you think that would remain backward-compatible with the current flumelog, or would that require a migration between the old format and the new format? I was a bit surprised by some behavior that I found which I think is the current implementation, where if you request an incorrect offset (e.g. 42, if the valid ones are 30 and 48) then it will return a message without validating that it also has the same length appended after the message ends.

I'm having the same feelings about the fact that a list of operations rather than data might be useful. It's true that Scuttlebutt has that semantic, where each message is a type, but it might be really nice for flumedb items to have this capability. I'm still bummed that we don't have rebuilds on all flumeviews, but I suppose that will come with time.