XSF Discussion - 2022-03-03

Guus: friend confirmed... He got that impression because he'd last experienced XMPP via pidgin

SURPRISE

use old software, get old experience

do we need the xmpp 2.0 flag day? ✏

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.

mod_tell_pidgin_users_to_upgrade

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?" ✏

Ah, I see.

XMPP streams do have a version number, after all.

I think the time and effort spend to deprecating old things is better spend by embracing and working on better things

not sure if everyone continues to use the old things

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

flow, what about new people using pidgin though

because it's e.g. still the default messenger installed on a fresh centos

jonas’, then we sould consider putting effort in changing the default xmpp messenger of centos

flow, go ahead

I've minimal centos user experience and not much insight in centos development. I assume that it means getting stuff into fedora/redhat

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

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

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

> 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

I'm with Flow here. Actively frustrating users of old/crappy clients will backfire.

I agree

hence it would be good if it showed a sensible error message (like: this is too old, try X or Y instead)

How?

I'd be happy to put those in, server-sided.

we'd have to check if pidgin for instance shows the text of a stream error

and if it shows it reasonably prominently

Openfire already queries software versions when clients connect. We can send out a message warning people when they use certain known bad versions...

or xmpp 2.0 flag day so that they don't even get to send presence or drain offline storage accidentally or somesuch

Guus, jonas’: maybe we need additional rules for the clients.json? or we generate this out of doap ^^ (no doap, no recommendation 😬😬)

jonas’: but on the other topic, where could I discuss this best?

emus: that was the goal of DOAP, right?

mod_nag_pidgin_users.lua when?

Ge0rG: Well, I see many applications. but did not see ranking as one

Link Mauve - have you had any luck/time in the meanwhile actually? that rendering of the clients would be a really really great thing

Good idea! I didn’t know what I wanted to do today, let’s be it!

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

so say we all

> Link Mauve escribió: > Good idea! I didn’t know what I wanted to do today, let’s be it! Really? 😅

Ge0rG: ah ok

Is there a list of client software version ranges that are known to have poor UX?

pidgin *.

or maybe pidgin < 3.0, if we want to be hopeful ✏

pidgin is running their own (non-federated) xmpp server: https://pidgin.im/about/pidginchat/

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

> not federated […] imfreedom.org

...

That one is, actually

I honestly don't see a problem with that.

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.

just a curious choice in naming

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...

I was merely surprised that they do use xmpp themselves. That strengthens the idea that there is drive to improve UX

Guus: Right.

Trying to figure out their server software...

Prosody

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

Their developer chatroom is on XMPP, they do use XMPP themselves

Their server seems to be based on a six-weeks-old Prosody commit.

That makes me expect great things for the near future 😉

Let's work with them, not around them.

MattJ, jonas’, Guus: Maybe we can invite them for a office hour and discuss whats their plan actually?

-EBUSY

Sounds like a great idea. The lead developer often does regular livestreaming sessions already :)

Any vetos?

Heh, lots of familiar names in their dev MUC

> jonas’ escribió: > -EBUSY = afk?

no, I'll most likely not be available for such an event

because no interest or you dont see the point?

because scheduling is hard with me :)

They have regular video events already

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

like https://pidgin.im/posts/2022-01-state-of-the-bird-q4-2021/

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?

I don't understand the question

Zash: Are you against offering to speak at Office hours?

no

ok

I reached out, lets see

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?

Why are you reading RFC 3921 in 2022? :)

are you aware that 3921 has been superseded by 6121?

I'm reading that, because that definition caused us to apply a 'fix' in Openfire that directly seems to contradict 6121.

I think 6121 has dropped this behaviour

(there is no "client processing of inbound subscription approval")

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"

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.

maybe a server should not forward a type="subscribed" to a client if the contact was already subscribed?

that would break the loop

actually, that does break the loop

because that's the RFC 6121 wording

I must be misreading something.

can you draw a flowchart? :)

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?