-
jonas’
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?
-
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
-
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)?
-
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
-
MattJ
I don't think I can right now
-
jonas’
ah, meh
-
MattJ
Give me a few to try and placate this toddler
-
MattJ
and maybe I can
-
jonas’
I’ll add it and you can review
-
jonas’
MattJ, https://github.com/xsf/xeps/pull/696/files/eb87a3b0bc4aed4d1a80aa23354902a2c0001ee2..0edd42a89f5effa01434c69bbe84fa616477e1e7
-
MattJ
Looks good, thanks
-
jonas’
merged!
-
Ge0rG
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
-
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
-
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
-
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
-
jonas’
that’s a minor issue methinks
-
Ge0rG
Did I mention that I hate stanza-id? :D
-
jonas’
yesn
-
Maranda
🤔
-
Maranda
🤯