XSF Discussion - 2020-03-27

In MIX, is it impossible to unsubscribe from a node after having joined a channel, instead of leaving and rejoining with just the ones we want?

Instinctively I'd say you should be able to un/subscribe to individual nodes all you want.

I thought the join stanza was mainly a convenience thing that did a bunch of subscribes for you under the hood

Zash, the join has to be done by the user’s server, then there is the update-subscription that can be done directly by the user, but it doesn’t define an unsubscribe mechanism.

I guess I’ll propose it.

People who are using XEP-0333 in the wild, are you really using the id attribute for that?

In a MUC especially that seems like a bad idea

MattJ, it doesn't say which id to use, does it?

> The Chat Marker MUST have an 'id' which is the 'id' of the message being marked. isn't really specific

The example shows it using the id attribute

true

So those two things combined suggest that yes, it does specify

"The example shows" is not normative :x

Regardless, we have plenty of things only documented by examples in XEPs :)

the example message also isn't in a MUC, so...

Maybe someday we'll make them normative..

also the example doesn't have origin-id or stanza-id, so maybe the rule is, "Use in order: stanza-id of a MUC, origin-id, message id attribute", the examples are just not good in showing that rule and it's not written down yet 😀

Nice try :)

which is why I asked what people are doing in the wild

we don't do stanza id

(Dino)

Conversations uses orgin id for everything 184 and 333 related

larma, chat markers (and many other xeps referring to just "id") predate other xeps which introduce other IDs, so it is safe to assume that those XEPs are talking about rfc6120 IDs

Not going into the _correctness_ of that but you asked what clients are doing

We also consider origin-id the new id attribute pretty much everywhere in Dino

(if present)

Using the stanza id might be _more_ correct in mucs. But only available in mucs. And then you have different behavior for group chats and 1:1

I guess we would want different behavior here

Looks like converse.js uses the id attribute

I'm in a situation where I want the MUC to be able to track who has read what

That's why I advocated multiple times that clients setting the orgin-id must set message ID and orgin id to the same value

IMO we should finally have a XEP that rules how to use IDs properly

like all of them

Daniel, yeah, I think that makes sense

I mean, we almost dropped origin-id entirely anyway

Daniel, isn't that what all clients do that support origin-id?

(although it should be in the XEP)

and it should also be in the XEP that it shall be UUIDs

larma: maybe. It's definitely not codified in the xep and flow was against that

But that works only if muc#stable-id right?

id == origin-id

Well no

It's about expectations

I mean for MUC cases

When a client expects the reply to reference the normal ID and the replyee uses the orgin id it doesn't matter

pep., the sender can send id == origin-id, it's just not guaranteed to be the same after it passed MUC

Because both would work

larma, sure I agree

The receiver will have very different expectations if muc#stable-id is present or not

jonas’, weird revision history here? (see timestamps): https://xmpp.org/extensions/xep-0184.html#appendix-revs

1.3.0 is dated later than 1.4.0

probably a slip when writing the year

or maybe a PR which was stuck reaaaaly long

pep., I personally don't like muc#stable-id, we kind of have to work-around it everywhere with stanza-id of the MUCs MAM. It would be much more useful if MUCs would just guarantee that id is a uniquely generated random id and tell the sender the id their message got

It would..

I'm not saying I like it either

larma, that's basically exactly what I'm considering doing right now :/

Looks like we don't even advertise stable-id

sounds like MIX

But I imagine many clients will break if we just rewrite ids

(though jabber.org still does that, right?)

MattJ, I don't think so, most clients can handle it if muc#stable-id is not present

also some gateways don't support it

So I'm looking at converse.js which uses the 'id' attribute in XEP-0184 and XEP-0333

Maybe there should be both muc#stable-id and muc#random-id

we could have a new feature muc#unique-id

😀

it doesn't appear to look for origin-id or detect muc#stable-id

I think it uses origin-id only to track what messages are reflections

btw, I always wondered if muc#stable-id is a violation of RFC 6120

> It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally. None of the two is guaranteed when doing muc#stable-id

It depends what you consider the "originating entity" to be

well, the one in from

Some people argue the client is the originating entity, others argue that the MUC is originating a new message based on the one the client submitted

which is the muc

Are clients storing a map between the id assigned by the MUC and the origin id?

or what?

If Converse.js sends a 184 receipt for the id assigned by the MUC (@id), are clients going to know what it is acknowledging?

MattJ, aioxmpp relies on #stable-id for tracking of its own messages. Without that, it’ll fallback to matching the body, which is stupid.

Neither XEP says to use origin-id, so I can't argue it's a bug in Converse

jonas’, why not origin-id?

MattJ, because we don’t auto-generate origin-id

I consider that to be a different layer

Have fun with that :)

works well ;P

This is all a terrible mess

agreed

I'm just trying to get stuff done that will work with all clients

But there is a gaping hole in the specs, so it's impossible

MattJ, a MIX-style annotation in the reflection to myself would be ok too, though

Thou shallt not have nice things!

So right now it looks like I'll have to just make it work with Converse.js and likely mess up other clients

what problem does converse.js have?

It doesn't have a problem

MattJ, Dino stores for each message (when possible) two IDs: the "stanza_id" which is either origin-id or id attribute and the "server_id" which is stanza-id of MUC in MUCs or stanza-id of your bare jid (= your MAM id) in direct message. If origin-id and id attribute mismatch we have a problem 😀

if it doesn’t work with #stable-id, I consider that a problem ;) ✏

jonas’, it does work with #stable-id

then I can’t follow at all

I'm working on the server side, and I want to figure out what clients are acking (I imagine this would also apply to a client that wanted to observe what messages other occupants had received/read)

Currently it seems I need to store a map of a non-unique id (@id) to stanza-id

The non-unique part obviously makes that impossible

(or unreliable, if you prefer)

If you're in the camp with "You send a message to the MUC, which then sends its own message out", shouldn't the MUC answer receipts then?

MUC could even send receipt-requests on its messages and return a receipt to the original sender when it gets receipts from enough participants.

And read markers?

gosh

Ugh

Zash, how do you define "enough"

Implementation detail!

Usually you can cope with the non-uniqueness of @id by scoping to a particular JID, but you can't do that in MUC (because acks get sent to the MUC JID)

Guus, how up to date is your MIX server implementation?

Could it be used to proxy joins and let clients access it?

Link Mauve I have none.

I think Surevine / Dave created one once, based on Openfire, but that never was merged.

dwd ?

https://github.com/surevine/Openfire filter branches for "mix" and you'll find a couple. I do not know what their state is.

Dave and me previously discussed working on getting this merged in Openfire, but never got around doing that.

https://twitter.com/MovimNetwork/status/1243574534600626186

how can I create account for the wiki https://wiki.xmpp.org ?

jubalh, ask Guus, ↑

Or Ge0rG

Or https://wiki.xmpp.org/web/Sysops

jubalh: It's well documented on https://wiki.xmpp.org/web/Sysops - please provide your desired wiki user name in CamelCase and an email address. real name is optional ✏

holla

hola

Hola compañiero../a?

por que todos hablan español?