pep.To what <message/> should <origin-id/> be added? All?
pep.Now that is was ruled out that LMC must refer to the original message, does it make sense to include an origin-id tag in it? As it will most likely not be referenced. (Same applies for other payloads I guess)
adityaborikarhas joined
alacerhas left
alacerhas joined
XSFhas left
balu_der_baerhas left
edhelashas left
nycohas left
madhur.garghas left
edhelashas joined
nycohas joined
matlaghas left
matlaghas joined
DebXWoodyhas left
DebXWoodyhas joined
eevvoorhas left
pdurbinhas joined
pdurbinhas left
DebXWoodyhas left
DebXWoodyhas joined
rionhas left
rionhas joined
Lancehas left
waqashas joined
dele2has joined
typikolhas joined
Lancehas joined
dele2has left
dele2has joined
DebXWoodyhas left
DebXWoodyhas joined
dele2has left
typikolhas left
Lancehas left
lovetoxpep. you need origin-id not for lmc
lovetoxyou need it to deduplicate your own mam messages
lovetoxhm ah i remember now
pep.hmm, because I don't get reflected messages in 1:1, I keep the origin-id and netx time I fetch MAM I can see where I stopped?
pep.hmm, because I don't get reflected messages in 1:1, I keep the origin-id and next time I fetch MAM I can see where I stopped?
lovetoxit was because in the MUC xep was a sentence that MUCs dont have to keep the ids that clients set
lovetoxso message-id was overwritten by muc service, so you had no chance to deduplicate with it
pep.Well in MUC it wouldn't apply right? As there is stanza-ids? Well, when the MUC does MAM
pep.Otherwise yeah I can use origin-id
lovetoxno you are joined in a MUC, you set a message id
lovetoxyou send the message
lovetoxdamn, you are right
lovetoxi forgot why we added this
lovetoxmaybe i remember later, im sure there was a reason
pep.Maybe the XEP could be clarified and add a clear motivation
lovetoxbut yeah that reason is maybe gone, maybe ask Daniel i think he remembers
pep.I have an implementation in slix, I'll wait for feedback a bit more I guess
Ge0rGToo many ids, too much confusion.
pdurbinhas joined
Lancehas joined
andyhas left
andyhas joined
Lanceorigin-id was a way to stamp without leaking your jid
Lancesince stanza-id requires a by
curenhas joined
pdurbinhas left
Nekithas left
DebXWoodyhas left
DebXWoodyhas joined
waqashas left
waqashas joined
kokonoehas left
kokonoehas joined
adityaborikarIs this site down, or is there anywhere else I could read this white paper
https://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html
adityaborikarThe link is on
https://xmpp.org/about/myths.html
ralphmI think they replaced it with https://www.isode.com/whitepapers/low-bandwidth-xmpp.html
ZashCool URLs don't change!
adityaborikarhas joined
ralphmBut it would sure be nice if they kept URLs working.
ralphmFWIW it seems to be a different article
ralphmAs in newer.
ralphmI'm sure Tobias knows.
moparisthebesthas left
moparisthebesthas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
frainzhas left
frainzhas joined
adityaborikarhas left
lovetoxpep. i think i remember again
lovetoxfirst everything previous to mam:2 did not inject stanza-id
pep.yeah I assumed there was something something mam and stanza-id
lovetoxsecond many clients used message-ids which were not uuids
lovetoxlike 1, 2, 3, 4
lovetoxso yeah if we live now in a world where most clients use uuids as message-ids, and almost every server uses mam:2
lovetoxi think you dont need origin-id
alacerhas left
alacerhas joined
andrey.ghas left
bennehas joined
patrickhas left
larmamessage id and origin-id have different uniqueness guarantees.
- XEP-0359 origin-id MUST BE globally unique (at least that's the common understanding of XEP-0359), so if everyone plays by the rules it is globally unique, otherwise it's unique per user if at least that user plays by the rules.
- RFC 6120 stanza id attribute on messages can be unique within that stream or globally unique (per RFC 6120 § 8.1.3). There is no MUST in there, so one may argue that no uniquness guarantee is provided, but explicitly no global uniqueness. Interestingly in XEP-0045 v1.31+, there is a rule that MUCs SHOULD reflect the original message stanza id on reflected messages, which implies that there is not even a by-stream uniqueness guarantee on the message id as other MUC occupants can reuse prior message ids and thus cause a collision of message stanza id on a stream (and still be fully standards compliant).
igoosehas joined
moparisthebesthas left
moparisthebesthas joined
larmaTechnically there is no uniqueness guarantees on <origin-id> whatsoever, only <stanza-id> are unique per generating entity (as specified in their by attribute)
Yagizahas left
Yagizahas joined
Yagizahas left
Yagizahas joined
lovetoxyes larma, but all you need is unique within an archive
lovetoxand this is guaranted by mam
Nekithas joined
larmafor mam that's guaranteed through <stanza-id>, not message id or <origin-id>
larmabut there are many other use cases that use a message id (or origin/stanza id)
lovetox_has joined
ralphmhas left
igoosehas left
lovetoxyeah but they are not as important as message deduplication
lovetoxso i always thought if a client does not use unique ids, then this feature will just not work good
larmaLMC changing the wrong message?
igoosehas joined
lovetoxyes, of course you can implement LMC badly, then this results in very bad stuff
lovetoxbut normally you have a timeframe where correction is allowed
lovetoxand even if you decide not, then you should always give the user the chance to see all corrections and original messages
lovetoxso worst is, the user sees weird stuff
lovetox_has left
lovetoxbut most clients use uuids
lovetoxand if you implement some timeframe, like message is only allowed to be corrected within 5 minutes
lovetoxthe chance of weird stuff happening is almost zero
lovetoxeven with clients who dont use uuids
larmaI feel I don't agree with most of what you wrote...
larma"user sees weird stuff" is literally the worst thing that can happen, after all MAM is only one utility to help not doing this
ralphmhas joined
larma"message is only allowed to be corrected within 5 minutes" I'd prefer that LMC was not only for the last message and also allow very old messages (up to days are acceptable for me)
larmaAnd even if you allow the user to display corrections, usually users won't do that anyway...
lovetoxhey i like it to, but this would depend on a uniqunes guarantee that can never exist
lovetoxyou can always only trust the other client
lovetoxand if you trust message-id
lovetoxor some other made up element
lovetoxi mean if you feel better, trust origin-id :)
lovetoxi think this is the downside of a federated protocol
lovetoxmake up for it by reducing the damage wrong IDs could make
lovetox1. timeframe, 2. give user the chance to deactivate lmc for bad contacts
lovetox3. give full transparancy, dont hide or replace messages
lovetoxthats how i deal with this
lovetoxif you got a better idea, im very interested
frainzhas left
larmaorigin-id should be unique at least by origin, easiest way to guarantee is to use a proper UUIDv4. If an attacker uses the same origin-id for multiple messages, the later ones can just be ignored completely, nothing to worry about as it is not possible to happen if it's not an attack and attackers are allowed to suffer from their wrongdoings.
frainzhas joined
larmaBut, you can't do the same for message ids as they are not unique by origin, so duplicate message ids are allowed to happen
lovetoxim not following, so you plan that i can correct ANY message i ever sent you whenever i want
lovetoxwhat is there to attack?!
lovetoxi can already replace any message
lovetoxand just in case we are not talking about the same thing, IDs should always every matched in the database with a (jid, id) tuple
frainzhas left
frainzhas joined
lovetoxthere is zero abuse potential other then your contact abuses his own messages he sent you, in that case just stop talking with this dude
Yagizahas left
larmaMaybe the name "attacker" was misleading here, I meant an entity that does not correctly implement origin-id and generates the same origin-id twice. Those would suffer from degraded usability (easiest is to ignore the messages with duplicated origin-id). However a user sending the same message id twice should not suffer from degraded usability (i.e. the message should be displayed as usual) as this is perfectly standards compliant behavior
lovetoxare we still talking about LMC?
lovetoxif someone sends 2 messages with the same id, and afterwards a correction for that id
lovetoxjust take the more recent one
lovetoxi dont need origin-id for that and i dont need to ignore a message
larmaThere is no reason why message correction should always reference the latest instance of a message id, the user might have intended to do something different. Message correction might be a bad example as those always originate from the sender and usually the same client (though this is not necessarily the case). However if you pick other usages of ids, you'll even get more problems. Like message attaching might attach to the wrong message or something
valohas left
valohas joined
larmaIf you use the message id for message attaching (as suggested as a fallback when there is no origin-id in the XEP) you have the risk of this happening, as a client might not be able to know where to attach that message. So best would be to not allow attaching to messages that don't have an origin-id. But now apparently everyone for some reason tries to not implement origin-id
kokonoehas left
lovetoxthe reason is easy, there are already 2 other ids we manage
kokonoehas joined
lovetoxso if we need a third one, it should be a damn good reason
larmaThere is your reason 😉
larmaAnd: if you don't want to support it on the receving end, at least support it as a sender for those clients that want to use it on the receiving end
larmaIf your message id is already generated using UUIDv4, you'd just have to send the origin-id as well and be done with all the work on the sending side (I assume you already store your message id, so you will be able to handle any usages of the origin-id automatically if it is the same)
lovetoxthe scenarios you think up seem unrealistic
lovetoxyou talk to a contact, that has a client who sends the same message id over and over
lovetoxbut for some reason its still so advanced that it supports message attaching
lovetoxso the client should now add origin-id instead of just making his message-id a uuid
lovetoxwhy cant the XEP not just say, clients who want to support message attaching should generate unique message-id
larmaThe client sending the message and the client being able to display the message attaching must not necessarily be the same
pep.lovetox, yeah I guess that would have the same effect? (mandating that clients generate unique @id)
larmaHow do you mandate legacy clients?
larmaThey are already out there, we can't change it afterwards.
pep.If they want to implement XEP-foobar, this XEP can say "if you implement me you need to do X"
pep.In practice it's a similar solution to origin-id
pep.I guess XEP-foobar could say "you need to implement origin-id"
lovetoxlarma, i dont have a problem with legacy clients having degraded experience
pep.Same here
lovetoxbut yeah message attaching is a bit unique, i have to look into it more
lovetoxLMC is really not a problem at all, with clients that use the same ids over and over
lovetoxi wonder how i would display message attaching on the sender side
lovetoxwould i also only link in my own database to the id
lovetoxor would i copy the message im attaching and adding it in some other database column
zachhas left
zachhas joined
lovetoxi think i would just copy the message into some "attached_data" column
lovetoxthat way i dont even have to care about if the other client uses unique ids
lovetoxif he uses unique ids he sees the correct stuff, if not, he doesnt implement message attaching anyway and will not see it
larmaOK, completely realistic scenario:
- On my desktop I am using some legacy client that does reuse message ids and does not support message attaching
- On my phone I use a modern client that does support message attaching
I send a message from my desktop, the recipient attaches a message to my message, I send another message from my desktop that happenns to have the same message id. I open my phone, the message attachment is attached to the wrong message. Even if the XEP of message attaching would require a unique message id, that would not apply to the legacy client, because it doesn't implement the XEP and the recipient does not know if the message id is unique, so can only guess. If the XEP would require origin-id, it would be missing from the legacy client and thus the recipient would be unable to attach to their message
lovetoxlarma i agree origin-id would solve this case
larmaWe could also replace origin-id by an empty <origin-id /> to signal that the message id was unique, but we need this information to be transported in the message.
lovetoxjust upgrading your desktop client would also
lovetoxhm actually i like that idea, to add an empty element
larmaThe desktop client is allowed to not send a unique id as long as they don't implement a XEP that does require them to. And I am pretty certain there are still a lot of clients that don't do unique ids
larmaMaybe we want to add this as on option to XEP-0359
larmaMake 'id' optional on <origin-id> if the id of the surrounding stanza already provides the uniqueness guarantees for <origin-id>
Lanceempty element would reintroduce the problem the origin-id is there to mitigate: MUCs rewriting the message ids. you'd lose the original id iagain n that case
lovetoxLance, but this was fixed in the MUC XEP
larmaLance, true for MUCs, but for non-MUCs the 'id' could still be optional
larmalovetox, it's an optional feature of MUCs
larmato keep the ID when reflecting
Lancelet me know when the jdev follows the latest MUC XEP
Lancelet me know when the jdev room follows the latest MUC XEP
Lanceunfortunately :/
lovetoxIm not sure what your argument is, we have to stay compatible with old outdated software only because it is compliant with some XEP
larmaIntroducing new requirements in a MUC is not really possible, there will always be legacy servers, only way would be to not connect to those anymore
lovetoxi couldnt care less about jabber.org
lovetoxif users tell me Gajim doesnt work with jabber.org, i tell them, go use another server
lovetoxnot rewrite Gajim
larmalovetox,
> The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]).
alacerhas left
lovetoxim fine with indicating with origin-id that a client uses a unique id
lovetoxi think thats a fine use for origin-id
lovetoxif you want to change your behavior on that, fine, i think would not have the motiviation
lovetoxand fyi Gajim sets origin-id since forever :)
larmaI wasn't talking about Gajim, I was talking about you suggesting pep. not to do it
lovetoxyes, message attaching is to new, i didnt look into it
lovetoxi stand by my opinion that for all other XEPs, like LMC you dont really need this
lovetoxand i think, all clients who support mam, support unique ids
lovetoxand you would never use a client without mam in a multi client setup
larmaYou don't need it for LMC, but need it as soon as it becomes MC without L
lovetoxso yeah i agree there are edge cases like the one you told, but im not sure we should put to much effort into supporting these
lovetoxbut adding <origin-id/> to indicate unique ids, is not that much effort :)
larmaI doubt pep. intention was to actually use a different ID for message @id and <origin-id>
lovetoxwhat i really would like to prevent is adding another db column "origin-id"
larmaI understand your point from a dev perspective 😉
lovetoxomg, jabber.ru does not send the muc subject on join
XSF Discussion - 2019-07-20