XSF Discussion - 2020-07-07

is there anything in XMPP-IM that requires me to use full jids? or could i just send one presence coming from the bare jid of my account?

Daniel, talking from a server perspective?

because as a client, you don’t have control over @from.

also, yes, RFC 6121 e.g. §4.3.2 requires the server to send presence from all currently available resources

yes talking about s2s interop. and interop with other clients. what I have in mind is a scenario where we replace most of c2s and have the server expose just one account to the outside world

instead of multiple clients

uh https://tools.ietf.org/html/rfc6121#section-4.2.2 this is also very strict wording

so the server would just send out one bare jid presence instead of multiple full jids

you’d be in direct violation of that

which is a MUST

You probably could get away with it tho

thinking this further you'd also receive PEP updates on the bare jid

and so on

and join mucs with your bare jid instead of full jids

Daniel, and then receive @type="groupchat" to the bare JID?

yes

this sounds like IM-NG / MIX territory

bare JID-ing the presence could be part of IM-NG

it is sort of an idea to circumvent problems we are facing with upgrading to im-ng

obviously my server / the way we are currently doing c2s would require a big overhaul

if bare-JID-ing presence helps with that by tricking legacy deployments, it should be part of IM-NG

I made a thing for that, for MUC. Sorta worked

but the goal is that everything s2s remains fully compatible

hm, I’m not convinced that we should put the complexity in overhauling c2s

yeah it's just some ideas that i've been carrying around with me for a while and i'm probably not doing a good job at describing it right now

I suspect this will complicate servers.

obviously

but it could be a way to not do mix and mix-pam

The thing I made was basically a bouncer.

yes i guess what i have in mind can be described as a bouncer

but not just for muc

but also PEP and everything

anything <message>

Daniel, how would you know where to send IQs when you don’t get full-JID presence?

jonas’, we are getting into the details here. but IQs would be the only thing that is still allowed to go to full jids. and I imagine that you have to do jingle message init

and then the receiving clients tells you the full jids for that particular session

or something like that

Daniel, sure, but how would you learn the full JID?

uh

so an extra protocol for clients to get a set of full JIDs?

that sounds awful

well we already have jingle message init

I’m not convinced that we can or should map all IQ flows to <message/>

and having an extra round-trip before initiating an IQ sounds meh

Brining back resource locking...?

or at least we already have the desire of sending p2p sessions to the account and then have the receiver choose one what device they want to accept the p2p session

Daniel, that’s true

i mean it's obviously not a fully formed idea

sure

Shifting PEP away from full JID subscriptions would be nice tho

I’m asking critical questions to bring it closer

and it will certainly create new problems

abolishing a push-way for clients to learn about full JIDs would at least break things for my "IoT" use-cases

while IM-NG by itself as it is currently would not

(because I don’t use <message/> at all, just <presence/> and <iq/>)

well if we call that XMPP-C2S-2.0 that nothing in there requires your iot devices to use that

Maybe we need that IM-NG discussion

they can still use c2s-1.0

Daniel, but can they interop with c2s-2.0 devices?

if those only send bare JID presence? ✏

i guess c2s-2.0 can still *receive* full presences

which if i'm understanding your iot problem correctly would be fine, no?

Daniel, it requires both, sending and receiving full presences.

because the peers learn their IQ partners from presence

because I heard that hardcoding resources is not good ;)

so you have human interaction with iot devices?

because if it's just iot talking to iot they can all use c2s1

I at least have IoT-ish things which need to talk to both worlds

MUC bots which talk to the devices for a text human interface

those would have to learn the full-JID presence of the devices. the devices may not have to learn the full-JID presence of the bot though ....

but it feels like an ugly restriction

right. i mean the general goal is ovbisouly that anything that is exposed over s2s should remain fully compatible with the outside world. however within c2s2 i’d be fully ok with dropping some (niche) use cases in order to have nice things

the combination of my idea not being fully formed and not understanding your use case makes it impossible to say if your use case would be one of those niche cases that i'd be dropping

the use case is rather simple: the devices have a roster of peers (and they know the bare JID of peers with specific functions, i.e. IQ interfaces). They use presence to learn the full JID to send the IQs to and to learn when they go offline etc.

Daniel, do you really thing that reworking basic assumptions in c2s and presence to "fix broken MUC" just to get what MIX, MIX-PAM would allow you to do is ok?

it's not just muc but also all kind of message routing. PEP; errors

Andrzej, I'm not sure what's the matter if it's a new protocol

but yes. at least that's a random idea that i've been thinking about

pep, sure start with bumpimg XMPP version to 2.0

not saying it's a good idea

Andrzej, there's a thing called XEPs I've heard :p

the question is also how many 'basic assumptions' we'd be violating if we use the bare jid to send presence or join mucs

pep, I know, but I just disagree with changing so basic assumptions and drop a way to discover other devices full jids (presences) by forcing presence to use bare jid

i mean XMPP (not IM) certainly allows you to send presence from the bare jid

and 45 also doesn’t mandete you use full jids, no?

XMPP allows you to send presence with no resource, but C2S forces server to overwrite from attribute so you end up with full jid

right. but as a client i think you should also be prepared to *receive* presences from a bare jid

Daniel, but only type="error"

(as well as type="{un,}subscribe{,d}")

I've encountered already presence from bare jid with type = unavailable :/

Daniel, XEP0045 section 7.2.2.: > If the service is able to add the user to the room, it MUST send presence from all the existing participants' occupant JIDs to the new occupant's full JID

XEP-0045 just almost everywhere mentions sending message stanza to full jid of the occupant, so at least we "should" (?) update XEP-0045 to use "send to occupant JID"

Andrzej, I think we'd have to relax your view on xep45 if you remove full JIDs from the game, but it could be that the places where xep45 talks about full JID are not so crucial that it couldn't work ✏

pepo, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid

pep, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid

that's true. but a server supporting xmpp-c2s2 could lift that rule

i mean that's totally up to the user’s server. as long as it doesn’t break other servers

doesn't mix already send type='groupchat' messages to the bare JID, and we assume it's ok because it was negotiated?

true, but how about MUC with bare jid and "history sync" without MAM?

flow, yes we do

c2s2 would just mandate 'something like MAM'

as I said, so many changes that it asks for XMPP 2.0

yes. but only for c2s

or at least that'd be the goal

keep s2s and interop with the outside world

and redo vast parts of c2s

if you want to call that xmpp 2.0 or something else is probably for the marketing department to decide

well, it is something that marks significant change

will that work if you have 2 c2s connections? 1 old and 1 new?

the idea is not fully developed yet to say. but i'd be fine with the answer being no

if that gives us beneftis

I do not have anything against c2s2 but I would prefer not to break RFCs in many places and at least for me now, idea of MIX is far better than fixing MUC (too many issues)

also idea of having MAM of MIX channel in user MAM archive works far better than querying each MUC room MAM archive on join (or reconnect)

the goal would obviously be to still able to chat with 'pidgin' on the other and still join any kind of muc. so the RFC should only be violated to a degree where it doesn’t cause any real harm

however much we may or may not not to stretch the exact wording of the RFCs to achieve that

Daniel, for c2s2 and bare jid in presence, would it mean that presence would be sent not so often? (if so, that could lead to desynchronization between MUC room occupants list and state of your client on your own server)

probably maybe never

if you think of xmpp-c2s2 as a bouncer

or your server acting as a bouncer and c2s2 being the protocol that you use to connect to said bouncer

note that i'm not (just) speaking from a perspective of 'fixing muc' or 'avoiding mix' - but also about the the whole carbons mess

i don’t hate MIX

I forgot about carbons, all software which I use sends message to bare JID and with MIX that works like a charm without carbons

and with MUC I do appreciate a way in which I can be in some rooms on my desktop and not join on the mobile using the same account

Well even if you send messages to the bare jid. For outgoing messages as well as error bounces you still have to deal with carbons

From an end user perspective carbons or broadly receiving messages on all devices is 90% solved

But the other 10% are an absolute nightmare

true, but it somehow I feel that the server should bounce back sent message anyway (ie. to delivery stable-id for it)

but that is a larger topic to discuss

to sum up my position: I like the idea to improve message routing and deal with carbons, but I do not think that presence with bare jid is a good idea

Hello everyone, the monthly XMPP Newsletter has been published! 📨☕ https://xmpp.org/2020/07/newsletter-01-july/

nice work!

emus, thanks!

Thank you! That counts for all the contributors as well!