XSF Discussion - 2019-01-13

Kev, https://github.com/xsf/xeps/pull/718 ping again :)

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.

(Not to mention that I disagree with it on the technical level)

Let's start with - what do you disagree with?

btw, "nobody has tried to ping the author" -> actually I discussed it with Sam before I did the work and made the PR

but Sam isn’t the author

He isn't?

ohh

I only saw the <author/> block, I missed the &sam;

right, that works then

(he also added a LGTM)

Right

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)?

but that’s not a blocker for the merge anyways

stable_id doesn't help anything in this case

what am I missing?

because two occupants can still legally use the same id

I see

unique (full jid, id)

MattJ, add a sender attribute to the <attach-to/> thing? I feel we discussed this at some point already…

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

occupants changing nicknames is irrelevant

MattJ: nyeh

ah, no it’s not

meh

jonas’, yes, there were multiple options we discussed, this one came out as the (unclear) winner

MattJ, then I’d still see the need for a feature on the MUC to discover that it will add a <stanza-id/>

hm, no

Client devs I polled preferred this one, because they are storing the stanza-id anyway

because message attaching happens afterwards

so it’s probably ok

and it's a lot easier than implementing any other sender-matching logic

't

so I'm totally open to other approaches, but we didn't find any that everyone liked

Except this one, which seemed the least worst

the missing not is still not fixed though

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)

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

I don't think I can right now

ah, meh

Give me a few to try and placate this toddler

and maybe I can

I’ll add it and you can review

MattJ, https://github.com/xsf/xeps/pull/696/files/eb87a3b0bc4aed4d1a80aa23354902a2c0001ee2..0edd42a89f5effa01434c69bbe84fa616477e1e7

Looks good, thanks

merged!

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.

Ge0rG, is that a problem?

in practice.

jonas’: yes. A good client should allow writing messages while offline, and deliver those once reconnected.

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

Aren't you already doing that for LMC?

pep.: no, LMC is based on @id, which I generate when sending

I'm not saying it's the right thing™, but it works independently of the server.

Ge0rG, I don’t see a better solution though, given that you cannot rely on @id at all here...

although I think it was also argued that we might not have to care at all

and attaching to your own messages wasn't really the intention of the XEP, if that matters

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.

oh no :(

Ge0rG, not even remotely?

(pun not intended)

I *might* dial into the webex, but no promises yet.

I should see if I use one or two days off to attend remotely

MattJ: I think we need to solve message referencing in the same way for all protocols, if possible.

sgtm

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.

Ge0rG, I agree

Which is why I'm insisting on using @id for those purposes

but we need to figure out a way to do that which is safe against malicious clients

And which is why I oppose origin-id.

it’s "meh" when an attacker can duplicate your @id and then nobody can react or attach to your message anymore

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?

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.

Ge0rG, then the sending participant won’t be able to match attachments correctly

which is fine for malicious entities obviously

jonas’: and for clients that don't support attaching.

a malicious MUC server is obviously an issue, but that’s a given

Ge0rG, also true. But this requires a bunch of memory or CPU resoures on the MUC server to keep track of used IDs.

jonas’: yes, and some kind of agreement about the history size...

which brings me back to my suggestion of using cryptographic counters for messages and sync them on MUC join

which is of course massively overengineered

This is a bottomless pit, right? Can we please have a pragmatic solution?

Blockchain? :P

the pragmatic solution is to use <stanza-id/> in group chats.

Also one where the complexity is in the server, not in the client?

which simply means you cannot react-to your unsent message

that’s a minor issue methinks

Did I mention that I hate stanza-id? :D

yesn

🤔

🤯