XSF Discussion - 2022-03-03


  1. moparisthebest

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

  2. jonas’

    SURPRISE

  3. jonas’

    use old software, get old experience

  4. jonas’

    do we need the xmpp 20. flag day?

  5. jonas’

    do we need the xmpp 2.0 flag day?

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

  7. mathieui

    mod_tell_pidgin_users_to_upgrade

  8. 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?"

  9. 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?"

  10. mdosch

    Ah, I see.

  11. jonas’

    XMPP streams do have a version number, after all.

  12. flow

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

  13. jonas’

    not sure if everyone continues to use the old things

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

  15. jonas’

    flow, what about new people using pidgin though

  16. jonas’

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

  17. flow

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

  18. jonas’

    flow, go ahead

  19. flow

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

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

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

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

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

  24. Guus

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

  25. jonas’

    I agree

  26. jonas’

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

  27. Guus

    How?

  28. Guus

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

  29. jonas’

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

  30. jonas’

    and if it shows it reasonably prominently

  31. Guus

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

  32. jonas’

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

  33. emus

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

  34. emus

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

  35. Ge0rG

    emus: that was the goal of DOAP, right?

  36. Ge0rG

    mod_nag_pidgin_users.lua when?

  37. emus

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

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

  39. Link Mauve

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

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

  41. Zash

    so say we all

  42. emus

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

  43. emus

    Ge0rG: ah ok

  44. Guus

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

  45. jonas’

    pidgin *.

  46. jonas’

    or maybe pidgin <3, if we want to be hopeful

  47. jonas’

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

  48. Guus

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

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

  50. jonas’

    > not federated […] imfreedom.org

  51. jonas’

    ...

  52. Zash

    That one is, actually

  53. Kev

    I honestly don't see a problem with that.

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

  55. jonas’

    just a curious choice in naming

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

  57. Guus

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

  58. Kev

    Guus: Right.

  59. Guus

    Trying to figure out their server software...

  60. Guus

    Prosody

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

  62. MattJ

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

  63. Guus

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

  64. Guus

    That makes me expect great things for the near future 😉

  65. Guus

    Let's work with them, not around them.

  66. emus

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

  67. jonas’

    -EBUSY

  68. MattJ

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

  69. emus

    Any vetos?

  70. Guus

    Heh, lots of familiar names in their dev MUC

  71. emus

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

  72. jonas’

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

  73. emus

    because no interest or you dont see the point?

  74. jonas’

    because scheduling is hard with me :)

  75. Zash

    They have regular video events already

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

  77. Zash

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

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

  79. Zash

    I don't understand the question

  80. emus

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

  81. Zash

    no

  82. emus

    ok

  83. emus

    I reached out, lets see

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

  85. MattJ

    Why are you reading RFC 3921 in 2022? :)

  86. jonas’

    are you aware that 3921 has been superseded by 6121?

  87. Guus

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

  88. jonas’

    I think 6121 has dropped this behaviour

  89. jonas’

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

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

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

  92. jonas’

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

  93. jonas’

    that would break the loop

  94. jonas’

    actually, that does break the loop

  95. jonas’

    because that's the RFC 6121 wording

  96. Guus

    I must be misreading something.

  97. jonas’

    can you draw a flowchart? :)

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