I'm not sure if this changes anything. People will still use pidgin and say xmpp is broken. I don't think they'll do a research about protocol versions and the support in pidgin first.
mathieui
mod_tell_pidgin_users_to_upgrade
djorzhas joined
millesimushas left
jonas’
mdosch, "'failed to connect'", especially if done in way that the most popular legacy clients show as *useful* error message, might be better than "WHERE ARE MY MESSAGES?"✎
jonas’
mdosch, "'failed to connect'", especially if done in way that the most popular legacy clients show a *useful* error message, might be better than "WHERE ARE MY MESSAGES?" ✏
mdosch
Ah, I see.
BASSGODhas left
jonas’
XMPP streams do have a version number, after all.
BASSGODhas joined
Alexhas joined
flow
I think the time and effort spend to deprecating old things is better spend by embracing and working on better things
jonas’
not sure if everyone continues to use the old things
flow
people typically continue to use stuff they are familar with and that works for them. instead of breaking things that more or less work for them, you need to offer them an alternative that is so superior that they are incentivized to switch on their own will
xeckshas joined
jonas’
flow, what about new people using pidgin though
jonas’
because it's e.g. still the default messenger installed on a fresh centos
flow
jonas’, then we sould consider putting effort in changing the default xmpp messenger of centos
homebeachhas left
Matthewhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
marchas joined
jonas’
flow, go ahead
flow
I've minimal centos user experience and not much insight in centos development. I assume that it means getting stuff into fedora/redhat
flow
that said, I try to keep XMPP in a good shape in the distributions I am mostly familar with and that I use personally, so I wonder if I can consider myself already doing my part
Andrzejhas joined
marchas left
marc0shas left
marc0shas joined
adiaholichas left
marchas joined
djorzhas left
adiaholichas joined
millesimushas joined
xnamedhas left
adiaholichas left
xeckshas left
harry837374884has joined
djorzhas joined
Danielhas left
flow
I also note that there seems to be a revival of pidgin's development activity and the folks behind pidgin dev (imfreedom.org) seems to be very inclinded towards XMPP. so while there is appearantly valid criticism towards pidgin, we should try to avoid aliniating them by this criticism becoming unconstructive pidgin bashing
marc0shas left
marc0shas joined
adiaholichas joined
millesimushas left
marc0shas left
marc0shas joined
djorzhas left
adiaholichas left
marchas left
marchas joined
emus
jonas’, mdosch: I am Happy to celebrate and announce things on 1st of April
Another thing I wanted to talk to you and ask for suggestions: I would like to tweet about XEP dev highlights. Something interesting we should announce. not for us. but rather to tell about our core work here. Any suggestions?
Maybe sonething:
> This month XEP-123 has been publish on ABCDE. It does XYZ. It's authors are: Adam & Eve
xnamedhas joined
emus
> flow escribió:
> I also note that there seems to be a revival of pidgin's development activity and the folks behind pidgin dev (imfreedom.org) seems to be very inclinded towards XMPP. so while there is appearantly valid criticism towards pidgin, we should try to avoid aliniating them by this criticism becoming unconstructive pidgin bashing
If thats true I agree. I also agree that people using pidgin could also be a thing of not advertising alternatives correctly
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
adiaholichas joined
debaclehas joined
Fishbowlerhas left
Fishbowlerhas joined
rafasaurushas left
marchas left
marchas joined
rafasaurushas joined
mjkhas joined
Andrzejhas left
Andrzejhas joined
atomicwatchhas left
Guushas left
Guushas joined
atomicwatchhas joined
msavoritiashas left
adiaholichas left
msavoritiashas joined
xnamedhas left
Andrzejhas left
atomicwatchhas left
xnamedhas joined
ti_gj06has left
ti_gj06has joined
goffihas joined
Andrzejhas joined
Dele Olajidehas joined
adiaholichas joined
xeckshas joined
adiaholichas left
ti_gj06has left
atomicwatchhas joined
ti_gj06has joined
adiaholichas joined
homebeachhas left
Matthewhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
harry837374884has left
edhelashas left
edhelashas joined
millesimushas joined
BASSGODhas left
adiaholichas left
wladmishas left
wladmishas joined
BASSGODhas joined
Andrzejhas left
Guus
I'm with Flow here. Actively frustrating users of old/crappy clients will backfire.
jonas’
I agree
jonas’
hence it would be good if it showed a sensible error message (like: this is too old, try X or Y instead)
Guus
How?
Guus
I'd be happy to put those in, server-sided.
jonas’
we'd have to check if pidgin for instance shows the text of a stream error
jonas’
and if it shows it reasonably prominently
Guus
Openfire already queries software versions when clients connect. We can send out a message warning people when they use certain known bad versions...
jonas’
or xmpp 2.0 flag day so that they don't even get to send presence or drain offline storage accidentally or somesuch
Steve Killehas left
emus
Guus, jonas’: maybe we need additional rules for the clients.json?
or we generate this out of doap ^^ (no doap, no recommendation 😬😬)
florettahas left
emus
jonas’: but on the other topic, where could I discuss this best?
harry837374884has joined
Steve Killehas joined
Ge0rG
emus: that was the goal of DOAP, right?
Ge0rG
mod_nag_pidgin_users.lua when?
Guushas left
Guushas joined
emus
Ge0rG: Well, I see many applications. but did not see ranking as one
emus
Link Mauve - have you had any luck/time in the meanwhile actually? that rendering of the clients would be a really really great thing
Link Mauve
Good idea! I didn’t know what I wanted to do today, let’s be it!
xeckshas left
Ge0rG
emus: I wanted to have automatic compliance suite flagging as a result of DOAP, and I wanted to have compliance badges in the clients list
florettahas joined
Zash
so say we all
eevvoorhas left
Wojtekhas joined
emus
> Link Mauve escribió:
> Good idea! I didn’t know what I wanted to do today, let’s be it!
Really? 😅
emus
Ge0rG: ah ok
Guus
Is there a list of client software version ranges that are known to have poor UX?
pidgin is running their own (non-federated) xmpp server: https://pidgin.im/about/pidginchat/
emus
I think a better approach than fighting old clients would be to get a landing page here popular. This is a strength that one has the choice
adiaholichas joined
jonas’
> not federated […] imfreedom.org
jonas’
...
Zash
That one is, actually
Kev
I honestly don't see a problem with that.
Kev
Pidgin's a multi-account client, so they're not locking users in, and if it means they're better able to run their closed network because there are no concerns about external bad actors, it's still one more group that's using XMPP.
jonas’
just a curious choice in naming
eevvoorhas joined
Steve Killehas left
Danielhas left
Kev
I'd rather people were running XMPP than not, even if they're not federated. I'd rather people were running XMPP than not, even if they're using clients without features that I want my client to have. I'd rather people were running XMPP...
Guus
I was merely surprised that they do use xmpp themselves. That strengthens the idea that there is drive to improve UX
Kev
Guus: Right.
mjkhas left
Guus
Trying to figure out their server software...
Guus
Prosody
jonas’
Guus, there is; grim hangs out in prosody@ sometimes. it's just that 3.x takes a long time to be released and that 2.x isn't going anywhere soon because of LTSes
gooyahas joined
mjkhas joined
MattJ
Their developer chatroom is on XMPP, they do use XMPP themselves
Guus
Their server seems to be based on a six-weeks-old Prosody commit.
Guus
That makes me expect great things for the near future 😉
Guus
Let's work with them, not around them.
adiaholichas left
emus
MattJ, jonas’, Guus: Maybe we can invite them for a office hour and discuss whats their plan actually?
jonas’
-EBUSY
MattJ
Sounds like a great idea. The lead developer often does regular livestreaming sessions already :)
emus
Any vetos?
Guus
Heh, lots of familiar names in their dev MUC
emus
> jonas’ escribió:
> -EBUSY
= afk?
jonas’
no, I'll most likely not be available for such an event
adiaholichas joined
emus
because no interest or you dont see the point?
Andrzejhas left
jonas’
because scheduling is hard with me :)
Zash
They have regular video events already
emus
okay, I will announce and then you can see. And in the end we may record.
Zash: yes, but I think is fine to invite already and make it a XMPP focused talk
Zash
like https://pidgin.im/posts/2022-01-state-of-the-bird-q4-2021/
emus
Zash: yes I know
but do you want to argue to host this? I mean, maybe if we show that we are here they really put more efforts on this direction?
adiaholichas left
Zash
I don't understand the question
cloudedhas left
cloudedhas joined
emus
Zash: Are you against offering to speak at Office hours?
Link Mauvehas left
Zash
no
harry837374884has left
harry837374884has joined
Bignthickhas joined
Bignthickhas left
xnamedhas left
adiaholichas joined
emus
ok
xnamedhas joined
adiaholichas left
adiaholichas joined
adiaholichas left
Link Mauvehas joined
wladmishas left
wladmishas joined
stphas left
papatutuwawahas joined
Link Mauvehas left
adiaholichas joined
papatutuwawahas left
papatutuwawahas joined
Andrzejhas joined
Link Mauvehas joined
millesimushas joined
stphas joined
neshtaxmpphas left
neshtaxmpphas joined
emus
I reached out, lets see
xeckshas joined
Dele Olajidehas left
florettahas left
florettahas joined
adiaholichas left
adiaholichas joined
millesimushas left
Andrzejhas left
adiaholichas left
adiaholichas joined
Andrzejhas joined
neshtaxmpphas left
neshtaxmpphas joined
atomicwatchhas left
Wojtekhas left
ti_gj06has left
ti_gj06has joined
millesimushas joined
Maranda[x]has left
Maranda[x]has joined
louishas joined
Andrzejhas left
neshtaxmpphas left
neshtaxmpphas joined
Danielhas joined
Danielhas left
Danielhas joined
Wojtekhas joined
xeckshas left
florettahas left
Danielhas left
florettahas joined
lskdjfhas joined
Wojtekhas left
Wojtekhas joined
mjkhas left
mjkhas joined
atomicwatchhas joined
Mikaelahas joined
adiaholichas left
mjkhas left
mjkhas joined
louishas left
louishas joined
adiaholichas joined
numéro6has left
Marandahas left
Mjolnir Archonhas left
Mjolnir Archonhas joined
Marandahas joined
numéro6has joined
Dele Olajidehas joined
rafasaurushas left
rafasaurushas joined
ti_gj06has left
louishas left
louishas joined
mjkhas left
mjkhas joined
gooyahas left
gooyahas joined
mjkhas left
mjkhas joined
mjkhas left
mjkhas joined
xnamedhas left
xnamedhas joined
florettahas left
adiaholichas left
millesimushas left
neshtaxmpphas left
neshtaxmpphas joined
cloudedhas left
adiaholichas joined
Maranda[x]has left
Maranda[x]has joined
cloudedhas joined
adiaholichas left
xnamedhas left
Syndacehas left
Syndacehas joined
millesimushas joined
mjkhas left
adiaholichas joined
mjkhas joined
florettahas joined
Danielhas joined
mjkhas left
mjkhas joined
Wojtekhas left
Wojtekhas joined
xnamedhas joined
millesimushas left
florettahas left
emushas left
emushas joined
xeckshas joined
florettahas joined
millesimushas joined
ti_gj06has joined
florettahas left
andyhas left
Wojtekhas left
Wojtekhas joined
adiaholichas left
mjkhas left
harry837374884has left
harry837374884has joined
papatutuwawahas left
adiaholichas joined
mjkhas joined
govanifyhas left
govanifyhas joined
Guus
In the very last two paragraphs of Section 8.2 of RFC 3921 (https://datatracker.ietf.org/doc/html/rfc3921#section-8.2), it is suggested that upon receiving a presence stanze of type 'subscribed', a client should acknowledge receipt by sending back a 'subscribe'. How is a server supposed to distinguish between that acknowledgement, and a subscription request?
MattJ
Why are you reading RFC 3921 in 2022? :)
jonas’
are you aware that 3921 has been superseded by 6121?
Guus
I'm reading that, because that definition caused us to apply a 'fix' in Openfire that directly seems to contradict 6121.
jonas’
I think 6121 has dropped this behaviour
jonas’
(there is no "client processing of inbound subscription approval")
florettahas joined
matkorhas left
Guus
From RFC6121 § 3.1.3:
>If the contact exists and the user already has a subscription to the contact's presence, then the contact's server MUST auto-reply on behalf of the contact by sending a presence stanza of type "subscribed"
Guus
My fear is that the combination of an 3921-style approval by an old client in combination with a server that does auto-reply, leads to a loop.
jonas’
maybe a server should not forward a type="subscribed" to a client if the contact was already subscribed?
jonas’
that would break the loop
jonas’
actually, that does break the loop
jonas’
because that's the RFC 6121 wording
Guus
I must be misreading something.
jonas’
can you draw a flowchart? :)
Guus
the server _must_ auto-reply with 'subscribed' when someone sends 'subscribe' to a contact that's already been subscribed to. The initiator will receive 'subscribed'. RFC3921-style clients will send a 'subscribe' as a confirmation ... which restarts the loop?