mdoschI'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.
mathieuimod_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?" ✏
mdoschAh, I see.
BASSGODhas left
jonas’XMPP streams do have a version number, after all.
BASSGODhas joined
Alexhas joined
flowI 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
flowpeople 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
flowjonas’, 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
flowI've minimal centos user experience and not much insight in centos development. I assume that it means getting stuff into fedora/redhat
flowthat 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
flowI 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
emusjonas’, 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
GuusI'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)
GuusHow?
GuusI'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
GuusOpenfire 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
emusGuus, jonas’: maybe we need additional rules for the clients.json?
or we generate this out of doap ^^ (no doap, no recommendation 😬😬)
florettahas left
emusjonas’: but on the other topic, where could I discuss this best?
harry837374884has joined
Steve Killehas joined
Ge0rGemus: that was the goal of DOAP, right?
Ge0rGmod_nag_pidgin_users.lua when?
Guushas left
Guushas joined
emusGe0rG: Well, I see many applications. but did not see ranking as one
emusLink Mauve - have you had any luck/time in the meanwhile actually? that rendering of the clients would be a really really great thing
Link MauveGood idea! I didn’t know what I wanted to do today, let’s be it!
xeckshas left
Ge0rGemus: 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
Zashso 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? 😅
emusGe0rG: ah ok
GuusIs there a list of client software version ranges that are known to have poor UX?
jonas’pidgin *.
jonas’or maybe pidgin <3, if we want to be hopeful✎
jonas’or maybe pidgin < 3.0, if we want to be hopeful ✏
Danielhas joined
millesimushas left
Andrzejhas joined
Guuspidgin is running their own (non-federated) xmpp server: https://pidgin.im/about/pidginchat/
emusI 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’...
ZashThat one is, actually
KevI honestly don't see a problem with that.
KevPidgin'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
KevI'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...
GuusI was merely surprised that they do use xmpp themselves. That strengthens the idea that there is drive to improve UX
KevGuus: Right.
mjkhas left
GuusTrying to figure out their server software...
GuusProsody
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
MattJTheir developer chatroom is on XMPP, they do use XMPP themselves
GuusTheir server seems to be based on a six-weeks-old Prosody commit.
GuusThat makes me expect great things for the near future 😉
GuusLet's work with them, not around them.
adiaholichas left
emusMattJ, jonas’, Guus: Maybe we can invite them for a office hour and discuss whats their plan actually?
jonas’-EBUSY
MattJSounds like a great idea. The lead developer often does regular livestreaming sessions already :)
emusAny vetos?
GuusHeh, 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
emusbecause no interest or you dont see the point?
Andrzejhas left
jonas’because scheduling is hard with me :)
ZashThey have regular video events already
emusokay, 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
emusZash: 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
ZashI don't understand the question
cloudedhas left
cloudedhas joined
emusZash: Are you against offering to speak at Office hours?
Link Mauvehas left
Zashno
harry837374884has left
harry837374884has joined
Bignthickhas joined
Bignthickhas left
xnamedhas left
adiaholichas joined
emusok
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
emusI 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
GuusIn 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?
MattJWhy are you reading RFC 3921 in 2022? :)
jonas’are you aware that 3921 has been superseded by 6121?
GuusI'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
GuusFrom 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"
GuusMy 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
GuusI must be misreading something.
jonas’can you draw a flowchart? :)
Guusthe 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?