-
Daniel
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?
-
jonas’
Daniel, talking from a server perspective?
-
jonas’
because as a client, you don’t have control over @from.
-
jonas’
also, yes, RFC 6121 e.g. §4.3.2 requires the server to send presence from all currently available resources
-
Daniel
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
-
Daniel
instead of multiple clients
-
jonas’
uh https://tools.ietf.org/html/rfc6121#section-4.2.2 this is also very strict wording
-
Daniel
so the server would just send out one bare jid presence instead of multiple full jids
-
jonas’
you’d be in direct violation of that
-
jonas’
which is a MUST
-
Zash
You probably could get away with it tho
-
Daniel
thinking this further you'd also receive PEP updates on the bare jid
-
Daniel
and so on
-
Daniel
and join mucs with your bare jid instead of full jids
-
jonas’
Daniel, and then receive @type="groupchat" to the bare JID?
-
Daniel
yes
-
jonas’
this sounds like IM-NG / MIX territory
-
jonas’
bare JID-ing the presence could be part of IM-NG
-
Daniel
it is sort of an idea to circumvent problems we are facing with upgrading to im-ng
-
Daniel
obviously my server / the way we are currently doing c2s would require a big overhaul
-
jonas’
if bare-JID-ing presence helps with that by tricking legacy deployments, it should be part of IM-NG
-
Zash
I made a thing for that, for MUC. Sorta worked
-
Daniel
but the goal is that everything s2s remains fully compatible
-
jonas’
hm, I’m not convinced that we should put the complexity in overhauling c2s
-
Daniel
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
-
Zash
I suspect this will complicate servers.
-
Daniel
obviously
-
Daniel
but it could be a way to not do mix and mix-pam
-
Zash
The thing I made was basically a bouncer.
-
Daniel
yes i guess what i have in mind can be described as a bouncer
-
Daniel
but not just for muc
-
Daniel
but also PEP and everything
-
Daniel
anything <message>
-
jonas’
Daniel, how would you know where to send IQs when you don’t get full-JID presence?
-
Daniel
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
-
Daniel
and then the receiving clients tells you the full jids for that particular session
-
Daniel
or something like that
-
jonas’
Daniel, sure, but how would you learn the full JID?
-
jonas’
uh
-
jonas’
so an extra protocol for clients to get a set of full JIDs?
-
jonas’
that sounds awful
-
Daniel
well we already have jingle message init
-
jonas’
I’m not convinced that we can or should map all IQ flows to <message/>
-
jonas’
and having an extra round-trip before initiating an IQ sounds meh
-
Zash
Brining back resource locking...?
-
Daniel
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
-
jonas’
Daniel, that’s true
-
Daniel
i mean it's obviously not a fully formed idea
-
jonas’
sure
-
Zash
Shifting PEP away from full JID subscriptions would be nice tho
-
jonas’
I’m asking critical questions to bring it closer
-
Daniel
and it will certainly create new problems
-
jonas’
abolishing a push-way for clients to learn about full JIDs would at least break things for my "IoT" use-cases
-
jonas’
while IM-NG by itself as it is currently would not
-
jonas’
(because I don’t use <message/> at all, just <presence/> and <iq/>)
-
Daniel
well if we call that XMPP-C2S-2.0 that nothing in there requires your iot devices to use that
-
Zash
Maybe we need that IM-NG discussion
-
Daniel
they can still use c2s-1.0
-
jonas’
Daniel, but can they interop with c2s-2.0 devices?
-
jonas’
if those only send bare JID?✎ -
jonas’
if those only send bare JID presence? ✏
-
Daniel
i guess c2s-2.0 can still *receive* full presences
-
Daniel
which if i'm understanding your iot problem correctly would be fine, no?
-
jonas’
Daniel, it requires both, sending and receiving full presences.
-
jonas’
because the peers learn their IQ partners from presence
-
jonas’
because I heard that hardcoding resources is not good ;)
-
Daniel
so you have human interaction with iot devices?
-
Daniel
because if it's just iot talking to iot they can all use c2s1
-
jonas’
I at least have IoT-ish things which need to talk to both worlds
-
jonas’
MUC bots which talk to the devices for a text human interface
-
jonas’
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 ....
-
jonas’
but it feels like an ugly restriction
-
Daniel
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
-
Daniel
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
-
jonas’
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.
-
Andrzej
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?
-
Daniel
it's not just muc but also all kind of message routing. PEP; errors
-
pep.
Andrzej, I'm not sure what's the matter if it's a new protocol
-
Daniel
but yes. at least that's a random idea that i've been thinking about
-
Andrzej
pep, sure start with bumpimg XMPP version to 2.0
-
Daniel
not saying it's a good idea
-
pep.
Andrzej, there's a thing called XEPs I've heard :p
-
Daniel
the question is also how many 'basic assumptions' we'd be violating if we use the bare jid to send presence or join mucs
-
Andrzej
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
-
Daniel
i mean XMPP (not IM) certainly allows you to send presence from the bare jid
-
Daniel
and 45 also doesn’t mandete you use full jids, no?
-
Andrzej
XMPP allows you to send presence with no resource, but C2S forces server to overwrite from attribute so you end up with full jid
-
Daniel
right. but as a client i think you should also be prepared to *receive* presences from a bare jid
-
jonas’
Daniel, but only type="error"
-
jonas’
(as well as type="{un,}subscribe{,d}")
-
Andrzej
I've encountered already presence from bare jid with type = unavailable :/
-
Andrzej
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
-
flow
Andrzej, I think you have to relax you 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 plentiful that it couldn't work✎ -
Andrzej
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"
-
flow
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 ✏
-
Andrzej
pepo, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid
-
Andrzej
pep, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid
-
Daniel
that's true. but a server supporting xmpp-c2s2 could lift that rule
-
Daniel
i mean that's totally up to the user’s server. as long as it doesn’t break other servers
-
flow
doesn't mix already send type='groupchat' messages to the bare JID, and we assume it's ok because it was negotiated?
-
Andrzej
true, but how about MUC with bare jid and "history sync" without MAM?
-
Andrzej
flow, yes we do
-
Daniel
c2s2 would just mandate 'something like MAM'
-
Andrzej
as I said, so many changes that it asks for XMPP 2.0
-
Daniel
yes. but only for c2s
-
Daniel
or at least that'd be the goal
-
Daniel
keep s2s and interop with the outside world
-
Daniel
and redo vast parts of c2s
-
Daniel
if you want to call that xmpp 2.0 or something else is probably for the marketing department to decide
-
Andrzej
well, it is something that marks significant change
-
Andrzej
will that work if you have 2 c2s connections? 1 old and 1 new?
-
Daniel
the idea is not fully developed yet to say. but i'd be fine with the answer being no
-
Daniel
if that gives us beneftis
-
Andrzej
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)
-
Andrzej
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)
-
Daniel
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
-
Daniel
however much we may or may not not to stretch the exact wording of the RFCs to achieve that
-
Andrzej
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)
-
Daniel
probably maybe never
-
Daniel
if you think of xmpp-c2s2 as a bouncer
-
Daniel
or your server acting as a bouncer and c2s2 being the protocol that you use to connect to said bouncer
-
Daniel
note that i'm not (just) speaking from a perspective of 'fixing muc' or 'avoiding mix' - but also about the the whole carbons mess
-
Daniel
i don’t hate MIX
-
Andrzej
I forgot about carbons, all software which I use sends message to bare JID and with MIX that works like a charm without carbons
-
Andrzej
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
-
Daniel
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
-
Daniel
From an end user perspective carbons or broadly receiving messages on all devices is 90% solved
-
Daniel
But the other 10% are an absolute nightmare
-
Andrzej
true, but it somehow I feel that the server should bounce back sent message anyway (ie. to delivery stable-id for it)
-
Andrzej
but that is a larger topic to discuss
-
Andrzej
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
-
emus
Hello everyone, the monthly XMPP Newsletter has been published! 📨☕ https://xmpp.org/2020/07/newsletter-01-july/
-
moparisthebest
nice work!
-
flow
emus, thanks!
-
emus
Thank you! That counts for all the contributors as well!