Yes, we are aware of them, but found them insufficient, and went with our own implementation. I'll try to briefly explain the difference in approach:

Basically, there are two types of trust information you need to share: your own devices and those of your contacts whom you trust. Own devices are published on PEP with signature (so that if one of your devices, or contact's devices, sees that an already trusted device signed yet another device, it starts trusting it automatically. With contact's devices trusted by your own devices we opted for trust messages, but exchange it via special notifications service. (after many experiments of sending messages to your own xmpp id and implementations of it in various servers, we decided that a service is a more reliable option).

Oh, and we added a third state: trust/distrust/revoked and timestamps.

Eventually we'll publish it all some time after we're happy with how everything works (this particular section works well, but some others aren't, yet) and we release our apps.

On Tue, 16 Jul 2024 at 14:45, MSavoritias <email@msavoritias.me> wrote:

To solve the keys problem you may also be interested in

- XEP-0434: Trust Messages (TM)
- XEP-0450: Automatic Trust Management (ATM)

Which Kaidan has implemented here -> https://www.kaidan.im/2022/08/31/e2ee-trust-management/

It serves as a nice solution to the problem.

Andrew Nenakhov kirjoitti 16.7.2024 klo 12.40:
It is actually not necessary.

On Tue, 16 Jul 2024 at 14:15, Tim Henkes <syndace@web.de> wrote:

I think this can be compared to calls or A/V in that both devices are expected to be actively used while the transfer is happening. I think this should be possible even on aggressive platforms like iOS.

Aggressive or not, it might actually be unnecessary, at least according to our vision of multi-device encryption.

We have discovered that whenever there are encryption session that are encrypted for one of your devices, and not the other, this leads to a horrible user experience that can't be recovered in no way. Grabbing the wrong device and seeing 'unable to decrypt message' which is decryptable on another of your devices is really, really bad and inconvenient, and we treat such incidents as a severe error.

So our solution is to require the sender to encrypt messages for all valid devices of the message recipient, warning the user really aggressively if one of those devices is not trusted (via fingerprint matching or our other method of verification via code), nudging the user to perform device trust procedure. This way, the only history you need to synchronize conversations that happened prior to addition of this new device just once, at device initialization. For this, you don't need to create some complex protocols that would continuously sync history.
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org