@SoapDog

Maybe a message should carry a field detailing the transforms that were applied to it so that at least a client could infer if it could support it or not.

I think this is a great idea, but in the current architecture I don't think it would help for the database to know that it can't support a transform. It would say "oops, I don't know how to handle this message" and pass it to the views, and we'd be in the same place where we need to do a full rebuild.

@mix

I'm super down with SQL, but I'm not sure how we'd be able to solve this particular problem with it without rewriting the majority of the stack. The problem is between the log and the view, so it seems like the only way to use SQL here would be to scrap or rewrite flumedb. The simplest way forward today seems to be baking off-chain content into the protocol (just like private-box decryption), but long-term it seems like the value of msg.value.content should be an application-level concern.

@Rabble

Yeah! I'd like to look into client-specific views, it should be pretty straightforward.