On Tue, Jan 29, 2019, at 15:31, Georg Lukas wrote: > However, there are multiple issues I see with [XEP-0367's] rules: > > - they are rather complex
I tend to agree; having to do any sort of logic just to get an ID isn't ideal, nor is having different IDs being used between group chats and regular chats. Unfortunately, I'm not sure this is avoidable with the current situation. To avoid this complexity, we probably need XMPP 2.0. > - they require 0359+MAM support in a MUC (and 0359 in the client) It requires 0359, which I think is reasonable (since we don't have any other way of guaranteeing consistent IDs, naturally if we updated RFC6120 to have better ID support, this requirement could go away). I don't think using the stanza-id implies MAM though, does it? > - they don't cover MIX yet (but the change should be trivial) MIX is too complicated and keeps changing; let's wait until it stabilizes and starts to gain adoption (though we may be waiting a very long time). > - you can not reference a message that wasn't yet reflected(*) > > (*) I see this as problematic in offline/high-latency situations: if you > want to send a message and a reference to it back-to-back, you need to > delay the second one until the first one was reflected. If you want to > prepare a message and a reference-message while offline (writing a > message for later delivery is a useful feature in a mobile client), you > need to keep a local reference (based on @id presumably), then to not > send the second message until the first one is reflected, and then to > rewrite the reference to the server-mandated one. > > The last one is a nasty, but not unsolvable problem. Maybe somebody can > come up with a more elegant solution that is not prone to the problem of > attacker-sends-id-duplicates, in which case I'd like to make this set of > rules into the official way to reference messages (maybe it should be > put into an Informational XEP and referenced from all the others?) I don't think this is a problem. You can't know where the message appeared in the conversation or that it was successfully delivered until it's reflected, so in my mind clients shouldn't be marking messages as delivered and actionable until they've been reflected. That being said, if people think clients being able to use attachments while offline is an important feature, I could see this being fixed in two ways: either use origin-id on the client and let the server manage the security implications (eg. by refusing duplicates), or use origin-id between the client and the server and let the server rewrite the attachment to use stanza-id. Neither makes me particularly happy though, it would be nice to keep this a client only feature. I think I personally prefer just saying that sending attachments isn't supported until the message is delivered (and if clients want to manage that themselves for offline messages, that's their concern). —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
