Kev, https://github.com/xsf/xeps/pull/718 ping again :)
jonas’
MattJ, I’m going to need context on this one: https://github.com/xsf/xeps/pull/696
These are non-editorial changes to a XEP which isn’t originally yours, which may well be fine, but I lack context which makes it obvious that it’s fine. Nobody has tried to ping the author either. And it has the [question] label. It is a very confusing thing.
jonas’
(Not to mention that I disagree with it on the technical level)
MattJ
Let's start with - what do you disagree with?
genofirehas left
MattJ
btw, "nobody has tried to ping the author" -> actually I discussed it with Sam before I did the work and made the PR
jonas’
but Sam isn’t the author
MattJ
He isn't?
jonas’
ohh
jonas’
I only saw the <author/> block, I missed the &sam;
jonas’
right, that works then
jonas’
(he also added a LGTM)
MattJ
Right
nycohas left
jonas’
I disagree with the requirement of <stanza-id/>. Where is it even written down that a MUC adds one, barring MAM support from the MUC (which may be disabled for lots of reasons)? Why not use @id and require the #stable_id feature (nowadays at least)?
genofirehas left
genofirehas joined
jonas’
but that’s not a blocker for the merge anyways
MattJ
stable_id doesn't help anything in this case
jonas’
what am I missing?
MattJ
because two occupants can still legally use the same id
jonas’
I see
Zash
unique (full jid, id)
jonas’
MattJ, add a sender attribute to the <attach-to/> thing? I feel we discussed this at some point already…
MattJ
Zash, except you don't always see the real JID, and occupants can change nicks, and all the issues we always have with referring unambiguously to messages in MUCs
jonas’
occupants changing nicknames is irrelevant
Zash
MattJ: nyeh
jonas’
ah, no it’s not
jonas’
meh
MattJ
jonas’, yes, there were multiple options we discussed, this one came out as the (unclear) winner
jonas’
MattJ, then I’d still see the need for a feature on the MUC to discover that it will add a <stanza-id/>
jonas’
hm, no
MattJ
Client devs I polled preferred this one, because they are storing the stanza-id anyway
jonas’
because message attaching happens afterwards
jonas’
so it’s probably ok
MattJ
and it's a lot easier than implementing any other sender-matching logic
jonas’
't
MattJ
so I'm totally open to other approaches, but we didn't find any that everyone liked
MattJ
Except this one, which seemed the least worst
jonas’
the missing not is still not fixed though
MattJ
Yes, I/someone can fix that, and also clarify that obviously the MUC will need to add stanza-id for this to work (if that's not already in there)
jonas’
I’m in the process of merging a few PRs, so if you fix that missing 'not' now I can hit the merge button on that one
Using stanza id from the MAM also means you can't attach to a message of your own if it's not round trip reflected yet.
jonas’
Ge0rG, is that a problem?
jonas’
in practice.
Ge0rG
jonas’: yes. A good client should allow writing messages while offline, and deliver those once reconnected.
Ge0rG
So now I need to remember the local reference, have a queue of messages waiting for an event, and not mess it up if 0198 happens in the middle
pep.
Aren't you already doing that for LMC?
Ge0rG
pep.: no, LMC is based on @id, which I generate when sending
Ge0rG
I'm not saying it's the right thing™, but it works independently of the server.
jonas’
Ge0rG, I don’t see a better solution though, given that you cannot rely on @id at all here...
jonas’
although I think it was also argued that we might not have to care at all
MattJ
and attaching to your own messages wasn't really the intention of the XEP, if that matters
Ge0rG
I think the topic of unambiguous message references is something that warrants a session at Summit, and it's a huge pity that I won't be able to attend.
MattJ
oh no :(
jonas’
Ge0rG, not even remotely?
jonas’
(pun not intended)
Ge0rG
I *might* dial into the webex, but no promises yet.
jonas’
I should see if I use one or two days off to attend remotely
Ge0rG
MattJ: I think we need to solve message referencing in the same way for all protocols, if possible.
MattJ
sgtm
Ge0rG
And IMVHO it is a viable thing to demand that modern clients create strongly unique ids, and to degrade service quality for clients that violate that.
jonas’
Ge0rG, I agree
Ge0rG
Which is why I'm insisting on using @id for those purposes
jonas’
but we need to figure out a way to do that which is safe against malicious clients
Ge0rG
And which is why I oppose origin-id.
jonas’
it’s "meh" when an attacker can duplicate your @id and then nobody can react or attach to your message anymore
Ge0rG
jonas’: the only solution I see for that is for a server to become the authority on message ids... Except what if there is a malicious server?
Ge0rG
A MUC could reject a message without @id, or with a duplicate @id, or even assign a new @id to that message for all but the sending participant.
jonas’
Ge0rG, then the sending participant won’t be able to match attachments correctly
genofirehas left
jonas’
which is fine for malicious entities obviously
Ge0rG
jonas’: and for clients that don't support attaching.
jonas’
a malicious MUC server is obviously an issue, but that’s a given
genofirehas joined
jonas’
Ge0rG, also true. But this requires a bunch of memory or CPU resoures on the MUC server to keep track of used IDs.
Ge0rG
jonas’: yes, and some kind of agreement about the history size...
jonas’
which brings me back to my suggestion of using cryptographic counters for messages and sync them on MUC join
jonas’
which is of course massively overengineered
alacerhas joined
Ge0rG
This is a bottomless pit, right? Can we please have a pragmatic solution?
Zash
Blockchain? :P
jonas’
the pragmatic solution is to use <stanza-id/> in group chats.
Ge0rG
Also one where the complexity is in the server, not in the client?
jonas’
which simply means you cannot react-to your unsent message