XSF Discussion - 2019-10-05

Ge0rG: ah ok, I didn't remember the outcome but I remembered there was something about it

lately i ran into following problem with the MUC protocol

send a presence to a MUC

Muc does not answer for 20 seconds

i give the user a option to abort this join (close the window or whatever)

only this does not reflect the truth, i have not really a possibility to abort the join

so user presses abort, and naturally tries again to join the room

another presence is sent out, now suddenly server responds to the first presence, sends stuff, then does the same for the second presence

i have no possibility to know what happend because of first presence, and what happens because of last presence

now i could send a presence unavailable on first abort

this brings me into even more trouble, now the server sends all presences, then disconnects me from the muc, then starts again to send stuff

all in all nothing i want to really deal with

maybe i should remove the abort button

there is no aborting a muc join

lovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.

And yes, there is no way to abort anything in xmpp land.

Which is why it's silly to have things end in a hard timeout.

then this muc join is in limbo and if a user complains i just tell him server should answer eventually

OTOH some network conditions may well lead to a request getting black holed.

So that the MUC doesn't even know that you tried joining.

This can be solved with s2s 0198, which nobody has ever tested.

Because you know, TCP is a reliable protocol

lovetox_, the second presence with <x/> should not screw up anything in the scenario you described

in fact, I think it should be safe to re-send join presences with exponential back off similar to how TCP sends SYNs

Kev, pinging you again regarding the hub.docker.com stuff. You seem to be the only one active who has the permissions.

jonas’: but one needs to know where the old join ends and the new one starts.

Maybe we need a unique ID on the join stanza, and the server ignoring duplicates?

> Ge0rG> jonas’: but one needs to know where the old join ends and the new one starts. do you?

Ge0rG, that’d be great

Ge0rG, flow, not in the scenario lovetox_ described, I think. You’d get (a) a full initial set of presence, (b) all presence hcanges between a and c, and (c) another full set of initial presence

there’s quite a bit of redundancy, but the state should be correct and complete

although, it will be confusing if you requested MUC history

jonas’, i'd guessed and hoped that something like that happens, but of course this could be MUC service (and client) implementation dependent. But nevertheless joining and (potentially other MUC actions) could and should get improved, and we should consider those things in groupchat-ng protocols

If only somebody thought that through for MIX

mix is at least a step forward in that regard

that we don’t have a proper solution for s2s failures yet is a problem, indeed

but that’s not a problem unique to mix or muc actually

We also need something for mobile clients that are killed after 10s in the background. A solution that doesn't involve persisting all runtime state, MUCs, and contact presence to disk

Can you really fix that with protocol design?

"WhatsApp works"

Zash: yes

With roster versioning, no presence broadcast and MAM we already have a moderately expensive solution. We now only need to replace presence with a PEP based status thing, as suggested by Kev.

BTW, what are the rules for delivering subscription requests to clients that don't send presence?

"don’t"?

Oh, and the above thing doesn't include MUC. We don't have a solution for that yet

Instead, if a subscription request requires approval then the contact's server MUST deliver that request to the contact's available resource(s) for approval or denial by the contact.

RFC 6121, 3.1.3. https://tools.ietf.org/html/rfc6121#section-3.1.3 ✏

4. Otherwise, if the contact has no available resources when the subscription request is received by the contact's server, then the contact's server MUST keep a record of the complete presence stanza comprising the subscription request, including any extended content contained therein (see Section 8.4 of [XMPP-CORE]), and then deliver the request when the contact next has an available resource.

It's XMPP, not XMP

Ge0rG, MIX would help in that regard, because it’s the user’s server which fully manages the joins

and those will be in a PEP node in the future so that you’re kept up-to-date to some extent.

SIMS xep says "The file element is the same as from Jingle File Transfer (XEP-0234) [2]. It MUST specify media-type, size, description, and one or multiple hash elements" Is "description" element really MUST?

jonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?

PEP without presence doesn't work either

Ge0rG, member list is a PubSub node ✏

jonas’: that's not an answer

and supposedly there’s a way to MAM-query PubSub nodes, although I never understood how

supposedly the MAM archive of a PubSub node would be the history of notification messages it sent ✏

in which case, yes.

Is it a one item node like old bookmarks?

I don’t think so

> Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node.

Zash: I'm sure we can figure out a way

rion, appears so

I don't think it makes much sense, though

rion, although that appears to be not in line with xep234

or, at least, I would expect that SIMS would require at least media-type, size and name (not description)

Agreed

In JFT, the <description> is the required container element, and the description text is in the optional <desc> element

So what are we talking about?

<desc>

which we may should rename to something like <description-text/>

jonas, the problem is the UI with my scenario

of course a library in itself would have the correct state after 2 joins

but having the UI display the correct state is the challenge

and yes it would be very helpful if we could add a unique join id to the presence, which is replicated on while joining on all the presences

i dont see a problem with subject and messages, you got to have message deduplication anyway

hm presences should also not be a problem, i could just update the ones i have already in my roster

the real problem for me is that i dont know when the MUC join is finished

normally i display a "joining.." label

lovetox_, you know it’s finished when you get the <subject/>

now i abort my first join, open the window again in haft of the first join, now i have half of all presences, then this join completes, i show the UI

but then the second join starts

the second join is fully deduplicated, isn’t it?

yes .. still my plan was to *not* show the groupchat UI *while* joining

so the first join signals my UI join completed, i show the UI with probably half of the users

then second join starts

but yeah think these are edge cases

still a simple IQ flow would be much better

where i get at the end a IQ join=complete

like with mam

How is that different from subject?

because the subject only tells you *a* join completed

not which one

of the 3 you send, while the server didnt answer

right

It should still be idempotent tho?

idempotent?

If you get a second join result it should just set everything to the existing values

But wouldn't you be able to identify which join is which by looking at your own presence?

would i?

does the self presence has the same id as the join presence?

as we determined before, state should be correct even on 2 joins

the problem that i have is the first join signals my UI im finished, when i reality the second is still in progress

i think this is only solveable if we would have some identifier in the join presence, which is at some point returned

i think how muc join was made is a anti-pattern, much better to make things clear with IQs

I tend to agree

It's significantly improved over GC1.0 still

Yes

ITYM Xabber Group Chat

Does anything use the 'continue' error type?

Might be nice to send some "keep calm and wait while we establish s2s"

Anyone had a chance to check my last weeks mail https://mail.jabber.org/pipermail/standards/2019-September/036495.html ?

yeah also thought this would get at least one response :/

Multi-session-nick is fairly underspecified

larma, vcards have been public, so I'd say "no" to that part

Zash i think it would be nice if prosody adds a "Dont route IQs to other participants" room config option

ejabberd has this

File an issue. I also want to be able to disable PMs.

yes

Would that be full JID routing or also break all vcards?

of course it would break vcard, and thats actually exactly the use case

:)

1. routing just is doesnt work good or is underspecified for the multi session nick thing

2. its a privacy issue

even more so now that prosody even routes it to the pubsub component

prosody just routes (some IQs) to the bare JID

or rather the pubsub component answers for the user

you mean PEP?

yes

No, it routes to the bare JID

I wouldn’t call that "pubsub component" to avoid confusion

It was ejabberd that answers vCard requests to full JIDs

iric

iirc*

which is correct if you go by the XEP isnt it?

wat

the vcard xep says server should answer it for the user

wat

otherwise how would you request a vcard of an offline user?

lovetox_, ask the bare JID?

wat

look either we want vcard in muc to work nicely, than a server should answer any vcard request for the user bare or full jid

or we dont want it in a muc (anon maybe), then the muc should not even start to route IQs

If the XEP says that the server should respond to requests to full JIDs then the XEP is wrong and diverges from how everything else in XMPP works.

no it says to respond to bare jid

and how is this ever going to work in MUC?

how can i address your bare jid in a anon room?

You can't.

Server can forward the request to your bare JID, like Prosody does

and you do this now for any IQ request

No, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.

yeah and you dont see this as a problem?

No

this is nowhere specificed, its a hack

and one that is a privacy issue on top

As was the vcard-temp routing thing.

However that's considered public data

i consider it public data to people who know my adress

Don't put it in your globally public vcard then

What is the point of the JABBERID field?

As i said its fine for people who know my adress, if i join a anon room, the point of the room is exactly to prevent people getting my real adress, but now it seems they dont even need it, because the server is happily routing to the bare jid and giving me the answer

im not saying we should prevent routing IQs, it just should be revisited for public anon rooms

and for non-anon rooms you dont have to route IQs at all

clients should just request the real bare jid

so who needs these public anon rooms that compromise the privacy of their participants? What use case do they fullfill exactly

You want Avatars, public omemo keys, other *private* data, then make your room non-anon and every user that joins knows what he gets into

this idea, i make my room anon, but still keep all features of non-anon rooms, is a bad solution

and i would argue its to the disadvantage of all users that join

I think you exaggerate the privacy impact somewhat.

I also never said I was against having this as a setting.

I don't think saying "public vcard is a privacy issue" is an eggageration :x

Don't put stuff there if you don't want it public for everyone everywhere, which is how vcard-temp works.

to be fair, I was also surprised that my avatar is exposed in anon MUCs

We got tons of complaints IIRC when we made vcards (via the PEP-conversion stuff) respect the privacy settings of the corresponding PEP nodes.

So, people have varying expectations.

Ah that reminds me I need to open an issue about that

yes Zash, thats because we did water down anon rooms, so people dont even know anymore what they are there for

Now Prosody makes those public by default, but still respects it if you change their settings.

Prosody still broadcasts my avatar hash in the presence even though I have access_model of vcard4 set to presence

in MUCs*

avatar and vcard4s are separate nodes tho

k

And you can have separate permissions. I do, in fact.

I also do have that node set to presence I think

If you query my vcard through here you only get the avatrarwavatar

And Zash, im not arguing against prosody here, this issue was raised by larma on the last sprint, and we discussed it, and now try to raise awareness in the community

so even if the discussion started with me, asking you for these settings, its more of a general discussion

Some of the problem is that there are two separate issues

in my opinion we should make the consequences clear what anon means, and follow through with it

Or more?

not try and find ways how we can water down anon

how we can bring features to anon that can not work with anon

You mean semi-anon? True anon rooms is dead afaik.

yeah of course

i would not go that route arguing true anon is not possible so also fuck semi-anon

I feel like this is a topic for a summit, rather than late saturday. :)

there is a good usecase for semi-anon

but just to be clear, there is no XEP or RFC that tells a muc to route IQs to the bare jid is it?

lovetox_, what larma quoted in his mail no?

https://xmpp.org/extensions/xep-0045.html#bizrules-iq ?

That doesn't specify bare or full though

ah its not specified

lol

yeah thats a real fail here

Nor which one if there's MSN involved.

I believe prosody picks one (probably the first) as the "primary" session and sends to that.

i mean it would be fine if you route to full jid

then the client can decide itself if he wants to reveal his data or not

although larma argued that even that isn’t good enough from a privacy perspective.

That lets yo do timeing things.

and you wouldn’t want to DoS a client which joins a busy semi-anon MUC and then has to upload its avatar a gazillion times.

(see also https://lab.louiz.org/poezio/poezio/issues/3419 )

jonas its already ddosed with disco info requests :D

avatars are an order of magnitude worse though

or a few orders actually

disco#info could be cached

if you want to do it real good, you would have to activate on your server to answer vcard requests to full jids for you

Zash avatars are also cached

lovetox_, guess what, that exists already

that’s why vcard is handled by the bare JID ;)

i mean a user configurable setting

not a server admin setting

that exists, it’s the visibility of the avatar pubsub node nowadays

at least for some implementations, and that’s even specified

https://xmpp.org/extensions/xep-0398.html#security

hm yes this could work

As I mentioned, you can fiddle with access control on the avatar and vcard4 nodes to do nice things.

so if i set it to presence, then my avatar is hidden

Maybe we need to add something like "also adjust presence broadcast if a user decides to use something else than open

I always forget whether directed presence counts for `presence` or not

jonas’: not

k

yeah fine workaround, im of the opinion we should deactivate IQ routing in anon rooms by default

lovetox_, I tend to agree with that

"presence" is an awkward name for it since it's based on roster (presence) subscriptions

The whole privacy model of vcard and public pep is based on the idea that a person still needs to know your real jid to access them. With semi-anon MUCs that's not the case anymore. Especially in prosodys now also routing pubsub IQs such that they can actually be replied by the server means that I only have two options: Not use OMEMO with non-roster contacts *or* reveal my identity in every semi-anon MUC

(I would probably opt for the first, if not every client would now by default make OMEMO pep nodes public)

Zash, whats the motiviation behind not allowing PMs?

lovetox_, ever had people join your support room and then PM you support questions?

IIRC it's also been requested by others. Don't remember their motivation. I'm sure there's use for it.

I would like to turn off PMs as a user right now.

My problem is that I can not rely in any way on IQ routing in semi-anon MUCs, because behavior is diverting between servers. That's why we should at least define the correct behavior. And IMO correct behavior is not to randomly send some IQs to bare and some to full JID

larma, I agree on the first part, but I’m not sure on the second part

although if we had to pin it down one way, I’d say "route to bare JID"

Well, if we say some IQs are routed to bare and some to full, we would need servers to somehow indicate what they are doing, because it might update...

similar to how we version carbon rules at the moment, indeed

larma, server should add a config options to muc, default to not route IQs, and advertise the setting in disco info

then the client can warn its users before joining such a anon but still routing IQs MUC

Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)

lovetox_, yes that would work

chronosx88, subject yes, name not

Does it?

And how offline user will know, that room name is changed?

jonas, i dont think subject changes are in MAM

lovetox_, oh

chronosx88, I guess you’d query that when you rejoin the room

Ehm...

chronosx88, you do a disco info to the muc before you join

and if the room name changes, the muc has to issue a status code for changed configuration

which should trigger your client to do again a disco info to get the new name

I just comparing XMPP and Matrix by technical abilities and simplicity

MAM is a message archive, it does not hold any configuration infos of MUCs

all configuration info is available via disco info to the muc jid

and all changes to the configuration are announced via message to joined and even not joined participants

(if they are in the member list of a muc=)

And... How it can synchronized when user didn't open client?

and you should disco info a muc before you join if you certain configuration fields like muc name are important to you

> And... How it can synchronized when user didn't open client? Or really is offline.

im not sure what you mean, if you are offline per definition nothing can be synced

because you are offline

Yeah

if you start your client, and join the rooms the user was in last time

before you join, the client sends a disco info to the muc, to get the current configuration

you could call that the "sync"

Ok

from that point on if you are joined, and configuration changes while you are online and joined

the muc informs you about it

Another question: how I can sync unread messages count between clients?

your best bet is XEP-0333 chat markers

And point in chat room, when I last time stopped reading

> your best bet is XEP-0333 chat markers Hm... Ok, will read it

where you stopped reading is a client UX problem, with chat markers, you can mark the messages you read on a client

and sync this info to your other clients, which can act accordingly

Did anyone have plans to make a PEP based unread message tracking thing?

Zash, why?

IIRC there was talk about something like that, or at least changing 333.

Zash, on, I'd like that

To sync reading state between clients

but you can already do that using MAM, no?

Can you?

How?

well if a 333 marker is send as a message, MAM should store it

> Clients SHOULD use Message Archiving (XEP-0136) [7] or Message Archive Management (XEP-0313) [8] to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online. from 333

Sending only 333 to myself then?

Never seen that before.

I don't especially want others to know

pep., i think this would be possible

you could send chatmarkers to yourself

its very ugly because you get a hell of duplicated messages

yeah

but i think this would work

Ah right, If you don't want the other end to know, 333 is probably not best suited

BUT only if you use unique stanza ids in every conversation

otherwise you lose the context

Yeah, makes sense, if you don't want to send to other end, PEP is better than MAM

you could do this analog to bookmarks 2

one node, with X items, and item-id = jid of contact

then add the current stanza id that you read