XSF Discussion - 2018-07-06

when receiving a presence subscription without a roster entry existing, the server does *not* create a roster entry as per RFC 6121 § 3.1.3: > Security Warning: Until and unless the contact approves the subscription request as described under Section 3.1.4, the contact's server MUST NOT add an item for the user to the contact's roster. To deny a subscription request, a client uses the flow described in RFC 6121 § 3.2.1+: > If a contact would like to […] deny a subscription request, it sends a presence stanza of type "unsubscribed". Later on in § 3.2.2: > The contact's server then MUST send a roster push with the updated roster item to all of the contact's interested resources, where the subscription state is now either "none" or "to" (see Appendix A). Two questions: 1. This seems inconsistent, because there is no roster item as per § 3.1.3. Am I wrong/missing something? 2. How, if at all, are other resources of the *rejecting* user informed about the fact that the subscription request was rejected?

By the roster push.

the roster push for the non-existent item?

:)

wat

this would effectively create an item

because subscription="none" is perfectly valid for a roster item

and thus be in violation of 3.1.3

and cause all kinds of funny out-of-sync stuff

(if the server doesn’t also add that item)

what do existing servers do?

https://hg.prosody.im/trunk/file/tip/plugins/mod_presence.lua#l163

"FIXME" ;)

this is about unsubscribed, not unsubscribe

Ah right

It looks like we skip the roster push then

Can haz The Great Presence State Tests

skipping the roster push is the right thing™ imo (as I said above), but this means there’s no way for resources to know when the subscription request has been denied

except by reconnecting and not receiving the type="subscribe" again

"meh"

jonasw, write a XEP that will forward the unsubscribe presence to the other resources of the client

flow, so you’d forward a stanza with @to not equal to the clients address to the client?

I think that would be the first use case where there is a presence in <forwarded/>

what would be the outer thing? message?

yep, and a special extension element

hurr-durr

cause onions and their layers are cool

so XEP-0045 apparently suggests to put full JIDs in MUC occupant <item/> info things (e.g. <presence><x><item jid=".../foo"/></x></presence>). do servers include multiple items if multiple resources are connected?

Prosody picks one at random

right

going ahead with the plan of dropping that on the client

Dropping the real JID?

no, dropping the resource

Dropping the resource?

(from the real JID)

Yeah

Resources shouldn't be seen by users anyway :)

it breaks my understanding of aioxmpp’s APIs (which is a weird thing to say as the main dev)

this is not about end-users, but about library users

*shrug* if they want that information they have to sniff the presence stanzas :)

+1

I don't expect much would break if we just made it the bare JID on the server

But not sure I can be bothered to find out

Conversations actually utilizes the full jid

Because some servers still don't include 110 and then being able to match the full jid is a nice fall back

:/

I refuse to interoperate with those servers.

*sigh*

daniel, do you have statistics how often that occurs and which software versions are affected?

Having metrics in Conversations for every time one of my many fun little work around gets triggered would be pretty cool

But my audience hates metrics

So no

do you happen to know the server which caused you to write the workaround?

I wonder whether I could add scans for such things to muclumbus

Well there is definitely more than one. Because 110 is a late addition to 45 AFAIK.

There are some servers which don't include it in all circumstances

I think ejabberd community didn't include it in error stanzas up until a while ago

Ejabberd SaaS doesn't include it in affiliation changes

nyco: about swag. I started a project called aptgetshirt.com while back where we produce (print) shirts and donate 50% of profit to projects. We use water based inks and fair trade (organic) garment as oppose to slave labor zazzle and alike. We thought of running xmpp shirt campaign somewhere around november, since you guys are looking for something we could work together on that. We also start slowly with stickers too.

muppeth, sounds great!

Thanks alot @muppeth

<number>102</number> <stanza>message</stanza> <context>Configuration change</context> <purpose> Inform occupants that room now shows unavailable members </purpose>

What

MattJ, nyco: i'll get back to you once we are properly up and running. currently we just re-launched the webshop and selling old stock, plus setting up our own silkscreen studio to cut the costs and be able to produce smaller batches on demand. My jid is muppeth@disroot.org

Am I the only one seeing 404.city stuck typing?

You are not

pep., I fell asleep by putting the phone on the key

nice

:)

I was already picturing client bug