-
moparisthebest
Guus: friend confirmed... He got that impression because he'd last experienced XMPP via pidgin
-
jonas’
SURPRISE
-
jonas’
use old software, get old experience
-
jonas’
do we need the xmpp 20. flag day?✎ -
jonas’
do we need the xmpp 2.0 flag day? ✏
-
mdosch
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
-
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.
-
jonas’
XMPP streams do have a version number, after all.
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
emus
Guus, jonas’: maybe we need additional rules for the clients.json? or we generate this out of doap ^^ (no doap, no recommendation 😬😬)
-
emus
jonas’: but on the other topic, where could I discuss this best?
-
Ge0rG
emus: that was the goal of DOAP, right?
-
Ge0rG
mod_nag_pidgin_users.lua when?
-
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!
-
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
-
Zash
so say we all
-
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?
-
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 ✏
-
Guus
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
-
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
-
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.
-
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
-
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.
-
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
-
emus
because no interest or you dont see the point?
-
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?
-
Zash
I don't understand the question
-
emus
Zash: Are you against offering to speak at Office hours?
-
Zash
no
-
emus
ok
-
emus
I reached out, lets see
-
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")
-
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?