-
Ge0rG
MattJ: nice Moved 2 XEP! I'd love to have it published as new 0283, but that's not a hill to die on. However, if the server performs the move dance, clients will end up not knowing that it's the same account as the old JID, and chat history won't get merged / migrated.
-
MattJ
Yes, suggestions welcome for how to notify the clients
-
MattJ
Unfortunately it seems all they get right now is a roster push, and I was hesitant to open that can of worms (roster annotations)
-
Ge0rG
I'd like to have some sort of marker in the chat history at that place, maybe a normal message from the old JID with the moved element?
-
MattJ
But that might be the only way
-
Ge0rG
And another one from the new JID?
-
jonas’
hmm
-
Ge0rG
A dumb client could just display a link to the respective other JID in the chat, a smart one would merge histories.
-
jonas’
I think I’d prefer if the server generates that, and in a way which cannot be spoofed by remote JIDs
-
jonas’
but I think those requirements don’t go together d(✎ -
jonas’
but I think those requirements don’t go together :( ✏
-
jonas’
because what you describe requires from=oldjid and from=newjid, and then we enter spoof territory, unless the server does deep message inspection
-
jonas’
(which it has to anyway, mind, for stuff like Delayed Delivery, but it makes things harder in the "server has no support scenario")✎ -
jonas’
(which it has to anyway, mind, for stuff like Delayed Delivery and Stanza IDs, but it makes things harder in the "server has no support scenario") ✏
-
Ge0rG
jonas’: well, there is no point for spoofing from oldjid, so that part is safe.
-
Ge0rG
And the newjid message needs to be verified in some way, e.g. by checking the existence of a respective message from oldjid. My server could easily inject both, not that's not a requirement.✎ -
Ge0rG
And the newjid message needs to be verified in some way, e.g. by checking the existence of a respective message from oldjid. My server could easily inject both, but that's not a requirement. ✏
-
jonas’
Ge0rG, is there not? if you can trigger a history merge, I am sure you can do some odd things there
-
Ge0rG
Look folks, I hereby migrate into jonas@xmpp.org!
-
Ge0rG
(nothing bad has happened)
-
jonas’
or how about into xsf@muc.xmpp.org?
-
Ge0rG
Now this is fun!
-
Ge0rG
Moved doesn't prevent you from that.
-
jonas’
moved 2 does, because you cannot get xsf@muc.xmpp.org to emit the <moved/> presence… or can you
-
MattJ
The current proposal does, because you have to be able to send a subscription request + custom payload from the new JID
-
jonas’
MattJ, security_considerations:add("<moved/> in presence emitted from non-bare (i.e. full JIDs) MUST be ignored")
-
jonas’
or are subscription requests from full JIDs?
-
jonas’
they probably are, aren’t they?
-
Ge0rG
I just wondered what happens if you send a subscription request as a room presence.
-
jonas’
Ge0rG, ^ :)
-
jonas’
but you can’t, because the room won’t forward type="subscribe". you just shoot your self in the foot by having the room added to your roster
-
Ge0rG
I'm sure nobody anticipated that and weird things will happen
-
Ge0rG
jonas’: you sure?
-
jonas’
oh yes, I think conversations will start to treat it as 1:1
-
jonas’
I think people do that often enough by accident
-
Ge0rG
Gajim used to add rooms to the roster, with all sorts of weird effects, including GC1.0
-
Kev
I was deliberately putting MUCs in my roster back in 2001 or so.
-
jonas’
everyone loves gc1.0
-
jonas’
Kev, now that explains MIX ;D
-
jonas’
also, random note: that was twenty years ago
-
Kev
*shrug* Some of us have been around for a while.
-
Ge0rG
Kev: but that would confuse any sane client, right?
-
Ge0rG
Suddenly you get room traffic without explicitly having joined it.
-
Kev
Actually, it wouldn’t have been 2001, it would have been 2002+, because I did it in Psi.
-
Kev
Ge0rG: They were bookmarked too.
-
Ge0rG
Kev: race conditions?!
-
Kev
Is there? I don’t remember, the account I used back then is lost to the mists of time, and I’ve not done it in a while.
-
Kev
Actually, it would have been GC1 back then, rather than MUC, too.
-
Kev
So yes, probably race conditions.
-
Kev
Ah, no, because there’s no sub.
-
Ge0rG
Kev: yes, but even with that, all clients I know can't process room join responses without having sent a join presence first. And I'm sure they'll start with initial presence and only then query bookmarks
-
Ge0rG
Ah!
-
Kev
Yes, but the initial presence doesn’t go to the room.
-
Ge0rG
Yes. It's ugly, but not broken.
-
jonas’
so XEP-0313 is hanging in limbo because some want the archiving rules written down clearly, but nobody is there to take up the work.
-
MattJ
Does anyone know what the archiving rules are? Is there consensus that they *can* be encoded into a Draft document?
-
MattJ
It seems to me they have been evolving over the past years
-
Zash
And they are likely to continue evolving
-
MattJ
(which is why I worked on Hints, but that apparently did not suffice)
-
jonas’
I think the consensus is that the rules should evolve in a document, not in hints attached to messages
-
jonas’
it could very well be Informational for instance to have it changed more easily
-
jonas’
if a server dev wrote down the rules *they* use, put that up for discussion and other server devs compared with their implementation, that’d be very productive I think
-
MattJ
That sounds wrong (it is not merely "informative" if it's a core part of how the protocol works)
-
Zash
I may have promised to do that, and may even have a draft translation of the Prosody code somewhere
-
MattJ
It also seems wrong if it's not versioned
-
jonas’
MattJ, right, standards track + namespace versioning + feature announcement?
-
jonas’
afk now though
-
Holger
XEP-0060 says: > A node may have a large number of items associated with it, in which case it may be problematic to return all of the items in response to an items request. In this case, the service SHOULD return some of the items and note that the list of items has been truncated by including a Result Set Management (XEP-0059) notation. So PubSub clients _must_ support RSM, at least if they ever query >1 items, right? (While PubSub servers may omit RSM support.)
-
flow
fwiw, I think xep313 archiving rules can be suggestions and best practices, and hence could probably go in an extra informal XEP. In any case services could signal that they follow the rules with an extra namespace
-
Zash
carbons and csi too
-
MattJ
I still prefer the hints model, where we encode everything needed directly into the protocol (and then minimal rules into 313)
-
Ge0rG
MattJ: IM-NG?
-
MattJ
That would certainly be a big improvement, yes
-
Ge0rG
And for that, we need compatibility routing and storage rules.
-
Holger
goffi, posted my XEP-0413 questions on the list now.
-
goffi
Holger: thanks, I'll check that tomorrow
-
Holger
👍
-
flow
MattJ, yeah, I'd also like to continue exploring the hints approach
-
Sam
Hi editors, I never heard back about my request. Going to make it again, please issue a LC for https://xmpp.org/extensions/xep-0292.html. Thanks!
-
Sam
Also while we're at it, https://xmpp.org/extensions/xep-0359.html. It's deferred but also widely used and should probably either be worked on, deprecated, or moved on.
-
Zash
I take it it's expired because 2020-11-03 is over a year ago in pandemic time?
-
Sam
huh, that's odd, I didn't notice that
-
Zash
And https://xmpp.org/extensions/xep-0292.html#revision-history-v0.11 was merged recently, but the date is the date when the edit was made
-
Zash
Time is wibbly wobbly as usual.
-
Sam
https://www.youtube.com/watch?v=q2nNzNo_Xps&t=9s