E2EE: event model lacks olm payload class

[brevilo]

When an event is encrypted using m.olm.v1.curve25519-aes-sha2 it needs to be augmented by a few additional attributes (see second code sample) prior encryption.

For example: to start a new outbound group session one needs to exchange the megolm session details with the room's devices, using a m.room_key event. Before it is encrypted and subsequently packaged as the ciphertext payload of a m.room.encrypted event (see first code sample above), it needs to be augmented like this:

{
    "content": {
        "algorithm": "m.megolm.v1.aes-sha2",
        "room_id": "!Cuyf34gef24t:localhost",
        "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
        "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8LlfJL7qNBEY..."
    },
    "type": "m.room_key",
    "sender": "<sender_user_id>",
    "recipient": "<recipient_user_id>",
    "recipient_keys": {
        "ed25519": "<their_ed25519_key>"
    },
    "keys": {
        "ed25519": "<our_ed25519_key>"
    }
}

Unfortunately the spec isn't as precise about this as it could be. I'm not sure how to implement this in the given event model, and I don't know which payload events (besides m.room_key) should be covered. I presume all of them. Thus I'd argue that we need a kind of OlmPayloadEvent that wraps any other Event, augmenting it with the keys "sender", "recipient", "recipient_keys" and "keys" as illustrated above.

FYI, my current workaround uses a RoomKey instance, serializes it to JSON, adds the "missing" properties and passes the final string to libolm's olm_encrypt() (via my upcoming bindings library).

Thanks

[ma1uta]

Done in 1f1fcd7

[brevilo]

Hm, 1f1fcd7 fixed the issue specifically for m.room_key only. As far as I understand the client-server spec these attributes are needed for any encrypted event sent using the m.olm.v1.curve25519-aes-sha2 algorithm. This should mean all encrypted to-device events, m.room_key being only one example. Looking through the spec I also found (at least) the following: m.forwarded_room_key, m.dummy and m.secret.send.

Instead of augmenting the individual events it should be better to use a dedicated (abstract) event type that the events in question are derived from. That's what I meant above with OlmPayloadEvent. The name was just an idea, feel free to rename it or use your *Content class generics concept.

What do you think?