@jaccarmac

Yeah, I think you're spot on. If we zoom out far enough it seems simple to say "when a new decryption scheme is added, pass the newly-decrypted messages to each view", but flume views expect to see each message once, in the order it was received, and the only option for mutability is rebuilding the whole view from scratch. This rebuild is especially painful for low-resource devices (think hours, not minutes) and it's important to me that we avoid it unless absolutely necessary.

@mikey

Yes! I think one of the big foundational changes here is that a message with the same key might be passed to a view multiple times with different content. Using the example from the thread root:

1. Scuttlebutt deploys group chats!
2. Alice upgrades her client
3. Alice starts an encrypted group chat with Bob
4. Bob's decryption view passes along the encrypted messages to the other views
5. Bob upgrades his client
6. Bob's decryption view streams all messages and passes any newly decrypted messages
7. The other views receive these messages for the second time, now decrypted, and index them
8. Bob checks his group chat view and sees the new group chat with Alice

One problem with chaining views is that the intermediate views (i.e. transforms) might need a higher since value than the log, since they might receive X messages but could send > X messages downstream to other views (in the form of updates).

The log might send:

{ key: 0, color: "red" }
{ key: 1, color: "green" }
{ key: 2, color: "blue" }
{ key: 3, color: { decryptedContent: "e2c692693217e4a2" } }
{ key: 4, color: { decryptedContent: "95fc83207e59f07f" } }
{ key: 5, color: "yellow" }
{ key: 6, color: "magenta" }
{ key: 7, decryptionKey: "1372dda6acbb8835" }

Which the decryption view would receive, and pass along to other views as:

{ key: 0, color: "red" }
{ key: 1, color: "green" }
{ key: 2, color: "blue" }
{ key: 3, color: { decryptedContent: "e2c692693217e4a2" } }
{ key: 4, color: { decryptedContent: "95fc83207e59f07f" } }
{ key: 5, color: "yellow" }
{ key: 6, color: "magenta" }
{ key: 7, decryptionKey: "1372dda6acbb8835" }
{ key: 3, color: "magenta" }
{ key: 4, color: "turquoise" }

I think the big changes here are:

• views can depend on views
• views can receive a message with the same key multiple times
• views can receive messages out-of-order (probably? important for partial replication)

cc: @noffle, forgot to cc you above but I imagine you've thought about this lots for both ssb and kappa-core