Hi Goffi, Thanks a lot for working on this, it's indeed a very interesting endeavor and has potential to make gateways more practical. The attempt to generalize, trying to describe payload and encryption algorithm (formatter and encrypter) independently seems like it is effectively overcomplicating things. Realistically, there aren't going to be a lot of situations where formatter and encrypter are not effective paired together. Further, because the gateway server is the one to decide which formatter to use (as the client is unable to know that on its own), it can likely do shenanigans there. Basically the more formatters a client implements, the more likely it is that these formatters have partial overlap, allowing the server to modify what content is displayed in the client. Ruling out illegal formatter+encrypter combinations on the protocol level reduces this risk drastically. Some modern encryption systems, like MLS, solve this issue by specifying the content type inside the encrypted+signed part of the message. In those cases, the formatter should never be specified by the gateway as it is implied from the encryption system. I see you already made an attempt with putting PGP/MIME into this framework. You are referencing OX to base your PGP part on it, however OX requires the recipient to verify that the PGP key has a user id in the form "xmpp:<bare-jid>" (this is a MUST in XEP-0373 § 3.2). As the gateway can't add new user ids to the PGP key and the other end is not aware of XMPP being involved, this is almost impossible to work out in practice. For PGP there are two popular payloads (outside OX) that are popular: - Plain. This is already supported via XEP-0027. - PGP/MIME. This is what you basically do this for. As you can see with this example, the generalization into formatter and encrypter is already not that helpful with the PGP usecase although it's one of the few that has two popular payload formats in real world. You tried to draft a specification for a MIME GRE Formatter. However, MIME is not a payload format. The payload inside PGP/MIME is an Internet Message (RFC 822 / 2822 / 5322). IMO, the following two things would make more sense to specify as XEPs: - A XEP that describes how to process rfc822 messages as a client and how to interpret them into XMPP. This could technically be used with a message/rfc822 type XEP-0481 <content> element - yes I hate me for even suggesting that - but also other things, including: - A second XEP that describes how to do PGP/MIME over XMPP (that is transporting PGP-encrypted RFC822 messages and discovering the keys to use for this), with the obvious intent of it to be used in the context of gateways, but technically 100% valid to be used in other contexts. A note on the procedure on specifying this: I think it would have been better to first merge all of the three ProtoXEPs you proposed now in a single Experimental XEP and see from there how it develops. The XEP can still be split up in the same way as you did right now before moving to Stable, but to me it feels more natural to have them all in one, as changes to one are likely to affect the others and maybe during the development we discover that a different way to split them makes more sense. Marvin On Mon, 2025-01-13 at 21:30 +0100, Goffi wrote:

On 13/01/2025 22.53, Marvin W wrote: We could certainly modify OX to soften this restriction. When OX was written, we did not really consider PGP messages originating from outside XMPP. But this sounds like a reasonable use-case. Hence OX could simply state that recipients must verify the signature. And that only if the PGP message is supposed to originate from within XMPP it the user ID should contain the sender's XMPP address. - Flow

On 14/01/2025 15.37, Stephen Paul Weber wrote: There are two aspects here. IIRC we assumed that it would be nice that OpenPGP keys signal that the key holder can receive messages protected by OpenPGP via XMPP. After all, this is one reason why the user-id subpacket exists in OpenPGP (albeit usually used to signal OpenPGP capabilities on mail addreses). Now, XEP-0373 § 3.2 requiring a user ID could be considered as overly strict. This is a nice example where implementation and operation experience feeds back into the protocol specification. Maybe it is not required. What is certain, is that we need relax the user ID rules for the gateway case, i.e., when an OpenPGP protected messages originates outside of the XMPP ecosystem and is then feed into XMPP. Obviously we can not expect the sender's OpenPGP key to have an XMPP user id in this case. I'll give this some though and probably prepare an update to the OX suite of XEPs. - Flow