XSF Discussion - 2019-10-23

xep-0313 question: what is the best way for a client to 'sync up' with the server-sided message archive? The protocol allows to be synced up based on timestamps, but also notes that those might not be unique. It states that the client MUST NOT depend on the presence of XEP-0359 IDs. I'm thinking that RSM's 'before' and 'after' identifiers are supposed to be opaque, so clients can't depend on that to be a XEP-0359 IDs either?

Guus, yet everyone does

Which one?

Guus, assume that they’re '0359 IDs.

nevermind that it’s then undefined how that even works with RSM, but that’s a topic for a different, long-winded argument which I have on my to-do list

Hm?

'they' being the supposedly-opaque RSM before and after values?

> When a message is archived, the server MUST add an <stanza-id/> element as defined in Unique and Stable Stanza IDs (XEP-0359) [2] to the message

Guus, yes

jonas’ thanks

> which informs the recipient of where and under what ID the message is stored.

So those are clearly the before/after IDs, no?

Yes the RSM situation is a bit weird right now. Matt is working on a fix

But it works OK with rsm after for now

my last info was that Matt is disagreeing that there’s a problem.

and is waiting for a proper argument to show what’s even kaputt

What's the weirdness?

There was a discussion not so long ago on this channel

Holger : RSM says: > The responding entity may generate these UIDs in any way, as long as the UIDs are unique in the context of all possible members of the full result set. Each UID MAY be based on part of the content of its associated item, as shown below, or on an internal table index. Another possible method is to serialize the XML of the item and then hash it to generate the UID. Note: The requesting entity MUST treat all UIDs as opaque.

I've seen a draft where query itself has a after-id value

note that I don't mind using XEP-0359 IDs in RSM - but it might avoid confusion to explicitly state that.

And Matt explained the problem to me which I didn't saw myself before that

So I'd say he is aware

Holger, that things get weird when you want to request stuff between two IDs from MAM

Daniel, oh, nice

so that’s getting fixed

Guus: You mean the very last sentence?

Holger yes.

jonas': So that's about the question whether before/after can be combined?

https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj

jonas’, Daniel ^

In this room

But note that today, I'm looking for implementation guidelines, not to address potential improvements to the protocol.

> But note that today, I'm looking for implementation guidelines, not to address potential improvements to the protocol. For normal catchup just do rsm with the last stanza id

everyone uses XEP-0359 IDs in MAM2 RSM? Good enough for me.

And empty query

jonas': Isn't that unrelated to Guus' question about stanza IDs being MAM IDs? Which I think 0313 is totally clear about, which solves any opaqueness doubts I would've thought?

And when parsing the message make sure you validate the stanza id feature on the archiving entity

Guus: Yes, and as I said I'd argue that's not just common practice but clearly guaranteed by 0313.

Daniel "and empty query" ?

Yes don't limit the query with a time stamp or something

Or the mam:2 feature, as that depends on stanza-ID.

*if* you have a stanza id

Holger I'd say that it could be stated more explicitly in 313 - It wasn't obvious to me, so it won't be obvious to at least other people as bad in reading XEPs as me. 🙂

Daniel understood, thanks.

I would've thought my above quote makes this very explicit but whatever.

Holger I'm one of those people that labels his label printer with "label printer" 😉

:-)

There's also this note: > Previous versions of this protocol did not specify any interaction with stanza-id, and clients MUST NOT interpret XEP-0359 IDs in messages as archive IDs unless the server advertises support for 'urn:xmpp:mam:2' specifically.

This this only implies the identity of 0359 and 0313 IDs by inversion of the statement.

*Admittedly this ...

Doesn't hurt to make it more explicit. 🙂

Thanks people!

If I recall correctly the NS of mam wasn't bumped before stanza id mandated the cleaning

So technically you could have a combination of mam2 and stanza id that doesn't do cleaning

But whatever

Ah. That may well be true.

Daniel: This would be addressed by checking for sid:0 in addition to mam:2, right?

Holger: yes that's why I said look for the stanza id feature

Makes sense.

But I don't think it's a problem in the wild. Prosody for example deliberately limited itself to mam1 before they had proper stanza id cleaning

"stanza id cleaning" being the requirement that entities check for stanza-id's with a 'by' value of the checking entity?

Yes

Daniel: Then again some MUC MAM module announced mam:2 without injecting stanza IDs at all, IIRC.

But that's been fixed and I'd just stick to the spec if I was a client author. And blame admins running outdated servers if things go wrong.

Daniel, IIRC that requirement has always been tehre

flow: Daniel clarified the Business Rules in 0.5.0. I don't think they stated this (as clearly) before: "Stanza ID generating entities, which encounter a <stanza-id/> element where the 'by' attribute matches the 'by' attribute they would otherwise set, MUST delete that element even if they are not adding their own stanza ID."

flow: Also rule 7, i.e. the exact value of the 'by' attribute, wasn't as clear before, IIRC.

(Text was contradicting example or something, so some servers would do by=$service_jid.)

Holger, I think it was clear before, or I do not understand the issue the commit message tries to explain

But yes, it wasn't clearly defined what the by value for MUCs is (MUC service domain vs MUC (bare) JID)

Do we have any XEP explaining what to do if for example I want to start a Jingle FT (requesting a file) in a MUC with a specific user connected to the MUC from two clients with the same nickname and only one of the clients has the file?

No

then when MUC is going to be deprecated?

in favour of what?

mix

this problem isn’t fully solved for MIX either.

oh

particularly in anonymous mixes

then we still probably need some unique identifier for each connection to the muc regardless of nickname.

which is tricky

there has been a long discussion on the list about this issue for MIX

we need to stuff four identifiers (MIX domain, MIX channel, user identifier, client/connection identifier) in a thing which only has three fields (a JID)

and each solution has its own drawbacks.

channel@domain/user?uuid ?

xmpp rfc has to be fixed :)

problem with that is that bare JIDs are as it stands now very useful for asserting equal identities

i.e. if a message comes from two different full JIDs but the same bare JID (and is not of type="groupchat"), you can be fairly certain that it’s from the same entity

that would break with your proposed scheme

the obvious other solution is user?channel@domain/uuid, but I don’t recall what problem folks had with that

except that there’s no trivial way (you have to parse the localpart) to associate the user to a channel

user?channel@domain/uuid lgtm

rion, thread(s) start here: https://mail.jabber.org/pipermail/standards/2018-May/035017.html

there are about four or five threads about this topic, it was a real sprawl

jonas’: the idea with <mix channel="some-channel"/> lgtm too. I haven't started implementing MIX yet. So whatever works best :)

Looking at the CS2020 last call, I was surprised to see XEP-0392: Consistent Color Generation in there. What's the rationale for including it?

Guus, discuss! :)

Aren't I doing that? 🙂

Guus, on list is probably a better way to do that

Guus: it was added before all the nifty styling requriements were removed from 0392.

Ge0rG I noticed that XEP-0385 is mentioned both in section 1.1 "Changes since 2019", but also in section 3 "Future Development". Is that an error, or intended?

Guus: it's optional in §2.3 as well.

Guus: the issue I have is that you can't really have optional things in the compliance tables.

so I'm a bit torn on where to have it and where not to.

But the triple-listing is probably a bit too much

Still, I'd appreciate a list discussion

I'd argue that if you're including it, then there's no point of adding it also as a 'keep an eye on this one for the future'

fair

Meta: The LC template seems weird for compliance suites.

I've not followed it.

sue me.

I'm happy to see this take off before Christmas, though 🙂

thanks for that

Zash, true, saw that too right after I confirmed

yoo is there any were on here or icq i can get free ccs

beautiful

jtyntv, here you go: https://www.creditcardvalidator.org/generator

credit cards? 😮 I'm sure they merely wanted to exchange with others about planting trees to achieve Carbon Capture and Storage (CCS). But you judgemental people and your prejudice ruin everything!!