Redacted events: Use Any*Event enums for redacted events

[DevinR528]

Sorry if opening all these is annoying, implementing it even if it's a bit off is the best way for me to understand something and I'm hoping having something to see and talk about helps everyone.

commit 1: Add most of the logic to generate the correct AnyRedactedEvent enums.
commit 2: Add the needed event content types for the 5 state events that have a content field. Create full, stub, and stripped versions of state events and full and stub versions of message event structs. Uncomment and fix redacted event tests.

[jplatte]

implementing it even if it's a bit off is the best way for me to understand something and I'm hoping having something to see and talk about helps everyone

It definitely helps, no worries!

[jplatte]

First impressions are positive ^^

[jplatte]

I think I mentioned this before, but the (currently only) case I actually think we should have custom_redacted for (although it could be solved differently too) is m.room.aliases: its redact function actually needs a parameter for whether to redact the content or not. Thinking about this more, this also means the associated has_fields function I thought of doesn't work! We actually need a method, taking &self, to determine whether to write the content field. That shouldn't make things any more complicated, though.

[DevinR528]

We also need redact methods on the Any*Event enums and something to deal with the fact that redacted_because is only a RedactedEvent so doesn't allow stub or stripped events. I tried out what we have so far in matrix-sdk and these were the only awkward bits.

I actually think we should have custom_redacted for (although it could be solved differently too) is m.room.aliases

You have said that before but a good reminder, I was thinking that implementations could redact their own made-up events but this can't actually happen can it (a server has no way to know what a client is up to and vice-versa)? If the only reason we have custom redacted events is aliases should we maybe remove the custom and add a RedactedV1AliasesEventContent or something like that? Do we need to have a type for the old redacted aliases event, if we got sent the JSON for an old aliases event it would (de)serialize correctly? Having the catch all and semitry is nice.

I'll start working on the RedactedEventContent and see if that opens any posibillities that would make custom easier to implement.

[jplatte]

We also need redact methods on the Any*Event enums

This PR is already quite big, let's do this separately.

and something to deal with the fact that redacted_because is only a RedactedEvent so doesn't allow stub or stripped events

I don't understand what you mean, can you expand on that?

I was thinking that implementations could redact their own made-up events but this can't actually happen can it (a server has no way to know what a client is up to and vice-versa)?

Again not sure what you mean, sorry 😅

If the only reason we have custom redacted events is aliases should we maybe remove the custom and add a RedactedV1AliasesEventContent or something like that? Do we need to have a type for the old redacted aliases event, if we got sent the JSON for an old aliases event it would (de)serialize correctly? Having the catch all and semitry is nice.

I don't fully understand what your idea is here, but if you want, try it out.

[DevinR528]

and something to deal with the fact that redacted_because is only a RedactedEvent so doesn't allow stub or stripped events

According to spec the redaction event should be inserted into the redacted_because field of unsigned, what I was getting at is that we should have a way (an enum maybe see example below) that allows this to be a stub or full event (are there stripped redaction event?)

enum AnyRedactionEvent {
    Full(RedactionEvent),
    Stub(RedactionEventStub),
    // stripped if needed
}
// then
struct UnsignedData {
    redacted_because: Option<AnyRedactionEvent>,
}

I was thinking that implementations could redact their own made-up events but this can't actually happen can it (a server has no way to know what a client is up to and vice-versa)?

I see now you weren't misunderstanding I read your comment completely wrong you were just talking about the attribute not custom events in general. So disregard that paragraph.

[jplatte]

According to spec the redaction event should be inserted into the redacted_because field of unsigned, what I was getting at is that we should have a way (an enum maybe see example below) that allows this to be a stub or full event (are there stripped redaction event?)

I see! I guess the spec could be clearer about this. It definitely makes sense in my mind that redacted_because could itself contain a redacted (redaction) event. I'm not so sure about the others though. I will ask on #matrix-spec:matrix.org.

[DevinR528]

Ah sorry about that I squashed a commit the wrong way, I should have squashed the last one into the one I ended up squashing.

oldest commit
middle // I squashed this into the commit above it
new // I should have squashed this and rewrote the commit?

[jplatte]

So the only missing thing now is the aliases field for RedactedAliasesEventContent and corresponding RedactedEventContent implementation changes, right?

[jplatte]

So I did another full review and found a few more issues 😅

[jplatte]

No RedactedStrippedStateEvent?

[DevinR528]

Is there supposed to also be StrippedStateEvent? If so there is no regular event struct for this either.

[jplatte]

Oh, right. 😄

Yeah no, stripped state events are only ever received as part of the sync response ^^

[DevinR528]

So I don't need to change anything right?

[jplatte]

No ^^

[jplatte]

Maybe something for a followup PR too, but we do now need enums over AnyStateEvent | AnyRedactedStateEvent, AnyStateEventStub | AnyRedactedStateEventStub and AnyStrippedStateEventStub | AnyRedactedStrippedStateEventStub. Maybe we actually need to use a Regular prefix for the generated Message and State enums and reuse their previous named for these new enums.

[DevinR528]

I think the rename makes sense. Probably be best to do it as a new PR, and maybe after the format_ident and fixing of the brittle enum name generation (fixing this stuff ident.to_string().replace... and making the event_enum! macro only take certain name/kind: Message)?

[jplatte]

Sounds good.