jdev - 2024-03-19


  1. nicoco

    > now im confused, so you want to send extra source attaching messages? yes, basically what the SFS XEP says in Example 7, but add the SIMS multi attachment in the first message too. I think staying backwards compatible with clients not supporting it is important. Now *you* got me confused, saying it's apparently a bad idea. I guess the "extra" messages don't need to be where the sources are, they could be in the first messages, with the other ones only being fallbacks for clients not supporting SIMS or SFS

  2. lovetox

    You can not send multiple messages otherwise all clients will display multiple messages. Nobody implements SFS so not sure for whom you do this. Simply stuff everything into one message

  3. nicoco

    Well, clients won't display multiple messages if they support the fallback XEP?

  4. nicoco

    Old clients that support neither SFS nor SIMS nor Fallback will display multiple messages, that's intended. More modern clients that do support Fallback and either SIMS or SFS will display only the first message, with multiple attachments, and ignore the following messages, since their whole body is fallback for SIMS or SFS?

  5. nicoco

    Am I missing something here?

  6. lovetox

    Yes clients supporting only sims will display all messages

  7. nicoco

    But not if the extra messages have both `<fallback for=sims>` and `<fallback for=sfs>`, or…?

  8. nicoco

    And BTW lovetox, what's your preference for gajim, SIMS or SFS?

  9. lovetox

    Both have open topics, but I will not support attaching sources to messages, it brings complexity with no real gain.

  10. nicoco

    OK thanks for the answer. Can you reply about that multifallback thing? Do you think it's a problem? Say, Example 7 but the extra messages don't attach new sources, just do oob as fallback for clients supports neither SIMS nor SFS

  11. lovetox

    this should work, didn't think about that you could sent these without adding a source

  12. singpolyma

    nicoco: so your proposal is that if a message has fallback set and nothing we understand in it we treat it as not present instead of as a blank message? hmm

  13. lovetox

    if the fallback defines that the whole body is a fallback, and nothing different is in the message, it would be like you received an empty message

  14. lovetox

    i guess this would work

  15. singpolyma

    with the way I do fallbacks right now this would result in a blank message being shown to the user. but maybe I could have a heuristic about this

  16. lovetox

    Yeah depends on if you store fallback data or not

  17. lovetox

    i just thought, while for filetransfer its not necessary to store the fallback text, because the other data is in the message

  18. lovetox

    its different for a reply, because you dont necessarily have the message the reply refers to

  19. lovetox

    in this case you could show the fall back text, until you receive the real message, if ever

  20. debacle

    On the internet, somebody asked why there is no 2FA for XMPP. I pointed them XEP-0400 and added that I'm not aware of any implementation. I wonder, why nothing exists so far?

  21. debacle

    On the internet, somebody asked why there is no 2FA for XMPP. I pointed them to XEP-0400 and added that I'm not aware of any implementation. I wonder, why nothing exists so far?

  22. singpolyma

    we only just started to get FAST rollout in the last 6 months or so, which is a prerequisite for anything in that space at least on mobile

  23. MattJ

    debacle, send them my FOSDEM talk :)

  24. MattJ

    (to send them to sleep so they stop bothering you)

  25. lovetox

    another problem is when you store the fallback body, it will be hard to filter that out if you do text search in your database

  26. lovetox

    like it will hit on stuff you later do not display to the user

  27. debacle

    singpolyma I agree, that entering six digits every some minutes were suboptimal UX ;-)

  28. debacle

    lovetox Wasn't there a message hint, that a particular message were not important enough to store? Or was that about MAM only?

  29. lovetox

    that is for mam

  30. debacle

    MattJ I'll send the link to https://archive.fosdem.org/2023/schedule/event/modern_xmpp_auth/ ;-)

  31. moparisthebest

    MattJ: once we have the concept of "devices", they can probably "register" with MUCs they want to stay in and MUCs can show them in the list and send them messages without presence/joining at all right? I'm aware I'm handwaving a ton of important details like how avatars won't work etc etc but roughly...

  32. MattJ

    We'll be able to do it one way or another, yeah

  33. MattJ

    The two options are to keep such sessions online if they are offline but have push notifications enabled (basically a better version of what Monal does), or to do something PAM-like for MUC

  34. MattJ

    The latter optionally includes just not making so much depend on presence in MUC2

  35. MattJ

    These aren't even mutually exclusive options, both could work together

  36. moparisthebest

    Then one small step from XMP 2.0 (eXtensible Messaging Protocol), no more presence

  37. MattJ

    I don't actually want that :)

  38. MattJ

    I think presence is still good for a bunch of things, and I think a lot of other systems that start without it just end up bolting it on later

  39. lovetox

    its surley useful, but it should not be somekind of base steping stone, rather something on the side which you can use if you want

  40. singpolyma

    we're trying to *add* all the features other chat systems have, not remove ones that they have we already do well ;)

  41. singpolyma

    Note that "register with MUCs and they can show them in the list" is all stuff we have already and AFAIK have always had in MUC

  42. singpolyma

    presence is mostly used to indicate "hey, please send me messages, muc" which seems correct

  43. MattJ

    Indeed. Excepting the lack of notifications, which we've solved multiple times in different ways, but it's not really used widely enough to be standard.

  44. singpolyma

    I'm not sure what good notifications do your device when it is off, but yeah

  45. moparisthebest

    I'm joking about removing presence actually, but I think in general it is true that other protocols no longer have it

  46. MattJ

    singpolyma, off/disconnected, but I suspect you know what I meant :)

  47. moparisthebest

    > I'm not sure what good notifications do your device when it is off, but yeah Because you'll get them when it comes back on, but maybe it's not off, maybe you silently left...a problem solved by the muc sending them anyway

  48. singpolyma

    > I'm joking about removing presence actually, but I think in general it is true that other protocols no longer have it I have not yet found a single one that does not have it

  49. moparisthebest

    What does have it?

  50. moparisthebest

    Signal/Molly does not appear to have it, SMS doesn't have it, I can't think of anything that does

  51. singpolyma

    Ok, yes, SMS does not (but RCS does) and I will admit I don't know about Signal. Discord has it, slack has is, facebook messenger has it

  52. moparisthebest

    Slack seems to just let you set an online status which stays whether you are online or not?

  53. moparisthebest

    I kind of guess the rest do the same

  54. MattJ

    https://matthewwild.co.uk/uploads/screenshot-20240319-1710879984-3264.png

  55. MattJ

    See the green dots

  56. moparisthebest

    I do see an advantage for a slack type thing, just not 1:1, I guess WhatsApp doesn't?

  57. MattJ

    But yes, the "status message" is not part of the presence, and we've discussed doing the same in XMPP, it makes sense

  58. MattJ

    WhatsApp also tells you when people are online/not and if not, when they were last online

  59. moparisthebest

    > See the green dots Yes but I think it's the status you set and not actually whether you are online or not, I think...

  60. Zash

    IIRC from Matrix you can include some flag in your polling to refresh your 'last active' timestamp/presence and then you go 'offline' if it's not refreshed for some time.

  61. moparisthebest

    tl;dr I don't really think it makes sense to broadcast to your contacts when your phone switches networks or you switch devices etc (XMPP presence model, and I'm only talking humans here, I could see reasons in iot or other things) I do see a need for a "last active" or similar, whether you want to call this presence or not I don't know

  62. moparisthebest

    I've never looked at the protocol but I can pretty much guarantee logging onto slack doesn't send a payload to everyone in the company

  63. MattJ

    > I don't really think it makes sense to broadcast to your contacts when your phone switches networks and we already don't do that, thanks to XEP-0198... for a long time :)

  64. moparisthebest

    What about the rest, switching devices :P

  65. MattJ

    That makes sense, because capabilities might differ between devices, etc.

  66. moparisthebest

    That's another reason presence should die, makes it tempting to use capabilities and build incorrect UIs that for example don't let you call someone

  67. lovetox

    just wanted to say that in a work env, presence is essential feature

  68. lovetox

    i honestly never cared in a non-work setting

  69. moparisthebest

    I agree, but not like XMPP does it: > I've never looked at the protocol but I can pretty much guarantee logging onto slack doesn't send a payload to everyone in the company

  70. lovetox

    i also wondererd about exactly that

  71. lovetox

    because it does not scale good, i can have thousands of people in my company, and all are in my "roster" if such thing exists in teams

  72. lovetox

    i think they must have some pubsub thing going on where you subscribe to a contacts presence, as soon as you open a chat, or have him in the chat list

  73. lovetox

    it makes 0 sense that i receive any information at all about 99% of my company i never interact with

  74. lovetox

    and we dont have that or?

  75. lovetox

    i cannot say, i dont want to receive presence from my roster contacts

  76. singpolyma

    With slack there is a concept of which 1:1 chats are pinned to the sidebar, which is more like your roster. the 999 other people in the company are in a searchable directory

  77. moparisthebest

    So I'll try to rephrase what I said, hopefully less poorly: I don't think there's a place for how XMPP does presence in modern day human-to-human communication. Does anyone agree/disagree?

  78. singpolyma

    I'd like to see a counterproposal. AFAICT what we do is pretty much what everyone does

  79. lovetox

    i just think the approach does not scale, and current xmpp is maybe in a situation where we are not hard pressed to solve this problem

  80. lovetox

    but i think we should think about solving this

  81. moparisthebest

    singpolyma: I think we should look what others do, I'm positive they don't do the broadcast we do...

  82. moparisthebest

    Off the cuff, and I know this somewhat goes against the XMPP ethos, I feel like pull is better than push here

  83. moparisthebest

    I don't need to know when my entire roster is on/offline, only the chat I have open

  84. singpolyma

    and every chat in your list of chats

  85. singpolyma

    but not archived chats probably, sure

  86. moparisthebest

    I think what MattJ alluded to works perfectly here, have pubsub/pep so the client could ask once, *or* subscribe to updates if it really wants them?

  87. moparisthebest

    I don't know about you all but my 1:1 roster is huge, and I probably haven't talked to 95% in over a year, I talk to 3 or 4 daily, and the rest once every couple weeks?

  88. moparisthebest

    They don't need my presence broadcast to them and I don't need theirs... Until we open the chat or maybe search for them

  89. moparisthebest

    Pep node could work and a server module could translate both ways for clients that support one or the other I think?

  90. lovetox

    but you still use the roster so the server knows who is allowed to get presence?

  91. lovetox

    ah is there a pubsub model "roster"

  92. lovetox

    hm you can only define a roster group which is allowed

  93. lovetox

    or the client could manage the whitelist itself, making the roster subscription state obsolete

  94. moparisthebest

    Yea either, both, whatever

  95. moparisthebest

    On a totally different subject this would also make current roster optional for people, which is another big sticking point for "privacy folk" to adopt XMPP

  96. moparisthebest

    For them, replaced by an encrypted roster the server can't read in private PEP or so... One thing at a time though lol

  97. singpolyma

    If you want to unsubscribe from their presence you can already do that

  98. moparisthebest

    Sure but that doesn't accomplish the same thing

  99. lovetox

    but when i dont subscribe to their presence, can i still get it when i want to?

  100. lovetox

    like with a presence probe?

  101. singpolyma

    It could, no?

  102. singpolyma

    I forget what the rules are for probes. Normally clients don't send them, but does the spec say they can't?

  103. MattJ

    singpolyma: they can

  104. MattJ

    I recall one server implementation used to dislike it, but I'm pretty sure it was fixed

  105. moparisthebest

    That's just polling without the ability to subscribe though, I mean it's ok I guess...

  106. singpolyma

    You have the ability to subscribe

  107. moparisthebest

    Not in remotely the same way

  108. moparisthebest

    You have the ability to subscribe or unsubscribe your entire account, you want the ability to do it on a device or more likely a per session basis

  109. theTedd

    The reason (some) other platforms omit presence is because they are mobile focused (and 'it still works' for anything else), so the assumption is "always online and available".

  110. theTedd

    I think whether a person is interested in presence depends on their usage pattern - if most of your interaction is in MUC/groupchats then it's less important, but if you're mostly in active 1:1 then knowing whether the other person is available is useful (should I expect a reply soon or later?) And there are differences in usage between desktop and mobile (at least for people who commonly use both.)

  111. theTedd

    So no single solution is ideal for everyone; it's probably best to be able to indicate your type/level of interest in presence, e.g. through pubsub, for your current device & session.

  112. moparisthebest

    Yes, I agree presence as a concept can be helpful, but the way XMPP currently does it is no longer suitable for today is all

  113. theTedd

    It's definitely unnecessary traffic overhead, particularly when much of it will be ignored; so only receiving what you're interested in would be ideal, which requires a way to indicate that

  114. moparisthebest

    💯