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?
emushas joined
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
krauqhas left
archas left
archas joined
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
archas left
archas joined
marchas joined
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
marchas left
jonas’
Daniel, and then receive @type="groupchat" to the bare JID?
marchas joined
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
mukt2has joined
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
marchas left
Daniel
but also PEP and everything
Daniel
anything <message>
marchas joined
jonas’
Daniel, how would you know where to send IQs when you don’t get full-JID presence?
krauqhas joined
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?
i guess c2s-2.0 can still *receive* full presences
Daniel
which if i'm understanding your iot problem correctly would be fine, no?
dwdhas left
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 ;)
mukt2has left
Andrzejhas joined
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
mukt2has joined
krauqhas left
marchas left
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.
APachhas left
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?
mukt2has left
mukt2has joined
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?
debaclehas left
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
mukt2has left
mukt2has joined
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
robertooohas joined
jcbrandhas joined
andrey.ghas joined
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)
Shellhas joined
APachhas joined
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
lskdjfhas joined
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)
mukt2has left
Andrzej
but that is a larger topic to discuss
mukt2has joined
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
karoshihas joined
mukt2has left
mukt2has joined
archas left
archas joined
andrey.ghas left
mukt2has left
mukt2has joined
Andrzejhas left
Andrzejhas joined
archas left
archas joined
archas left
archas joined
Shellhas left
Shellhas joined
debaclehas joined
Andrzejhas left
Dele Olajidehas joined
Steve Killehas left
krauqhas joined
tomhas left
Steve Killehas joined
mukt2has left
Alexhas left
Alexhas joined
mukt2has joined
neshtaxmpphas joined
Alexhas left
Alexhas joined
LNJhas joined
archas left
archas joined
Alexhas left
Alexhas joined
sonnyhas left
sonnyhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
sonnyhas left
govanifyhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
neshtaxmpphas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
DebXWoodyhas left
DebXWoodyhas joined
DebXWoodyhas left
DebXWoodyhas joined
Shellhas left
Shellhas joined
sonnyhas left
sonnyhas joined
nycohas left
nycohas joined
adiaholic_has left
adiaholic_has joined
mukt2has left
Shellhas left
Shellhas joined
mukt2has joined
nycohas left
nycohas joined
Shellhas left
Shellhas joined
Shellhas left
Shellhas joined
marchas joined
govanifyhas left
govanifyhas joined
archas left
archas joined
sonnyhas left
sonnyhas joined
nycohas left
sonnyhas left
sonnyhas joined
nycohas joined
sonnyhas left
sonnyhas joined
govanifyhas left
govanifyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
stpeterhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
adiaholic_has left
adiaholic_has joined
Shellhas left
Shellhas joined
stpeterhas left
sonnyhas left
sonnyhas joined
Andrzejhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
Andrzejhas left
sonnyhas left
sonnyhas joined
Steve Killehas left
govanifyhas left
govanifyhas joined
lobodelrayohas left
lobodelrayohas joined
Steve Killehas joined
sonnyhas left
sonnyhas joined
Jeybehas left
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
mukt2has left
mukt2has joined
sonnyhas left
sonnyhas joined
flowhas left
flowhas joined
flowhas left
flowhas joined
lobodelrayohas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
flowhas left
flowhas joined
govanifyhas left
govanifyhas joined
flowhas left
flowhas joined
Andrzejhas joined
mukt2has left
sonnyhas left
sonnyhas joined
Jeybehas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
govanifyhas left
govanifyhas joined
mukt2has joined
sonnyhas left
sonnyhas joined
Jeybehas left
sonnyhas left
sonnyhas joined
sonnyhas left
j.rhas left
DebXWoodyhas left
DebXWoodyhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
j.rhas joined
Steve Killehas left
sonnyhas left
sonnyhas joined
DebXWoodyhas left
Steve Killehas joined
sonnyhas left
sonnyhas joined
sonnyhas left
citizenzibbhas left
citizenzibbhas joined
sonnyhas joined
citizenzibbhas left
citizenzibbhas joined
sonnyhas left
mukt2has left
sonnyhas joined
citizenzibbhas left
citizenzibbhas joined
j.rhas left
j.rhas joined
lovetoxhas joined
mukt2has joined
marchas left
citizenzibbhas left
citizenzibbhas joined
Shellhas left
Shellhas joined
Shellhas left
Shellhas joined
sonnyhas left
j.rhas left
sonnyhas joined
lovetoxhas left
j.rhas joined
krauqhas left
Shellhas left
Shellhas joined
citizenzibbhas left
citizenzibbhas joined
sonnyhas left
sonnyhas joined
krauqhas joined
karoshihas left
emus
Hello everyone,
the monthly XMPP Newsletter has been published! 📨☕
https://xmpp.org/2020/07/newsletter-01-july/
stpeterhas joined
waqashas joined
moparisthebest
nice work!
Shellhas left
Shellhas joined
sonnyhas left
sonnyhas joined
Jeybehas joined
flow
emus, thanks!
Andrzejhas left
Andrzejhas joined
Marandahas left
Marandahas joined
sonnyhas left
sonnyhas joined
emus
Thank you! That counts for all the contributors as well!