@keks

The more I think about this, the more I wonder whether we should be appending changes to flumedb rather than content. For example, instead of appending msg to the flumelog, we would append { add: msg }, which would give us the option of message deletion with something like:

{
  remove: {
    id: msg.id
  }
}

If views respected these semantics, most of them could easily run a few small commands to delete individual messages, feeds, or even rebuild (with a remove and subsequent add operation). Do you think that's too naive of an approach? Or too similar to MongoDB? 🙃

I'll admit I'm not very familiar with CRDTs, if you have a learning resource you like then I'd love if you could share.