XSF Discussion - 2022-07-07

  1. jcbrand

    Interesting, the list admin is someone from Wire

  2. Zash

    https://datatracker.ietf.org/doc/bofreq-mahy-mimi-more-im-interop/ more words

  3. MSavoritias (fae,ve)

    Does the second link means that xmpp would have to adopt MLS for groups? It sounds like a good idea since OMEMO doesnt scale that well

  4. Zash

    Means some folks want to discuss starting a working group to discuss that.

  5. emus

    dwd: ? ^

  6. emus

    I subscribed

  7. jcbrand

    I look forward to those folks writing the code as well

  8. Zash

    Rough code and running consensus is still the thing, eh?

  9. jcbrand

    It's better than endless discussions

  10. emus

    Well, I wouldn't say its an endless discussion

  11. jcbrand

    No, me neither 😇

  12. emus

    yet 😛

  13. emus

    but apart from, this, maybe it would make more sense to have our say and come up with what opportunities we have

  14. edhelas

    I'd like to know if you guys have some feedbacks regarding my (small) XEP proposal, Bookmark Pinning https://github.com/xsf/xeps/pull/1182

  15. MattJ

    SGTM, it makes it easier to move in the direction of bookmarks as a synchronization method for joined rooms instead of only those that the user has selected to bookmark

  16. Kev

    1) It's insane that we have to have a spec to bookmark bookmarks because bookmarks are used for something other than bookmarking. But that's just cosmetic and of no real consequence. 2) We need this 3) extending bookmarks means that naive clients are possibly going to overwrite the extension, but maybe that's fine. 4) We need this

  17. pep.

    3 should be covered by the spec, baring any bugs, as usual

  18. Kev

    Maybe I missed it. How's it covered by the spec?

  19. Link Mauve

    Kev, re 3), the <extensions/> element is required to be left alone by every supporting client, this warranted a namespace bump.

  20. Kev

    Oh, wait, this is bookmarks:1, obviously.

  21. Kev

    Yes, I'm being an idiot.

  22. Link Mauve

    The best kind of idiot, who brings useful criticism. :)

  23. Link Mauve

    Kev, 0402 can still be renamed “MUC join synchronisation” or something like that.

  24. Link Mauve

    I’ve heard about some proprietary chat applications using the term “bookmark” to mark messages in the history of a single chat or room.

  25. pep.

    Well yeah the term isn't proper to MUC

  26. Link Mauve

    It actually is, as currently defined in our specifications.

  27. pep.

    Sure, I mean in general

  28. Link Mauve

    But many clients did away with that term to describe the rooms to rejoin on launch.

  29. Link Mauve

    Which I think is a neat direction for user-friendliness.

  30. MattJ


  31. Link Mauve

    edhelas, a small feedback I have, from a bunch of users who requested that, is to keep a given ordering.

  32. Link Mauve

    It could be implemented with an integer defining a partial ordering.

  33. edhelas

    Like we used to have priorité in resources :p ?

  34. edhelas


  35. Link Mauve

    No, like we used to have a non-moving ordering of open tabs.

  36. Link Mauve

    Instead of the current way of open chats being reordered by last activity, which bothers many people around me.

  37. edhelas

    And how would you solve concurrency regarding the integer order ?

  38. Link Mauve

    Concurrency is a mess with PubSub anyway, you can just ignore it for now (and forever) I guess.

  39. edhelas

    Ok Movim is already implementing the Bookmark Pinning thing (with its own namespace) for those that wants to try

  40. edhelas


  41. edhelas

    Looks like this

  42. edhelas

    And the pinned room are kept on top of the list

  43. MattJ

    Question though: can you pin 1:1 chats?

  44. edhelas

    Can you bookmark 1:1 chats ?

  45. edhelas

    (and in Movim no)

  46. MattJ

    Conversations supports pinning conversations of any type

  47. MattJ

    Obviously that's not synchronized currently, but if it adopted this XEP it would be weird if only MUCs were synchronized

  48. edhelas

    0402 is only about MUC ?

  49. MattJ

    Supposedly, yes

  50. edhelas

    <conference xmlns='urn:xmpp:bookmarks:1'/>

  51. Sam

    Generally speaking (though I doubt we can/want to rewrite the world, but it's worth mentioning) it's weird to me that we have two different concepts of a roster that are basically identical and need duplicate functionality re-written for both (the actual roster and the bookmarks list).

  52. edhelas

    Maybe we should release a <bookmark xmlns='urn:xmpp:bookmarks:2'/> ?

  53. edhelas

    Sam +1

  54. MattJ

    That's something MIX actually does improve

  55. Sam

    They end up with divergent feature sets while requiring that developers basically rewrite the same functionality for both. Pretty much the worst developer experience.

  56. edhelas

    Sam do you have a proposal to solve that ?

  57. Sam

    We probably can't (or shouldn't). It's just worth keeping in mind as we add new functionality.

  58. edhelas

    Roster is about presences also, bookmarks is not

  59. Sam

    See also the wide adoption of MIX and other rewrite the world protocols.

  60. edhelas

    Sam +1

  61. edhelas

    Basically my though was "hey we have a fresh bookmark XEP, oh there is extensions, lets add a first extension :p"

  62. edhelas

    But maybe we can generalize bookmarks to any kind of uris, like 1:1 chats or even Pubsub nodes (wild !)

  63. singpolyma

    I wouldn't say "can't" we could have a new namespace element that can be put in roster. But since roster is so fundamental and bookmark already exists probably more trouble than it's worth

  64. singpolyma

    Plus with vcard4 we now have a xep to put a bunch of roster stuff in pubsub too ;)

  65. Link Mauve

    Sam, for developers it’s at the library level that a common interface could be exposed.

  66. pep.

    > But maybe we can generalize bookmarks to any kind of uris, like 1:1 chats or even Pubsub nodes (wild !) Yes please

  67. pep.


  68. pep.

    And make synchronization an extension?

  69. moparisthebest

    > At the time, different groups within IETF proposed separate protocol suites (SIMPLE, APEX, and XMPP) because the community could not come to consensus on a single protocol

  70. moparisthebest

    Lol, well seems like the community eventually did arrive at a consensus though

  71. MattJ


  72. moparisthebest

    I've never even heard of APEX

  73. Zash

    But, HTTP/0.9 or HTTP/1.0 or HTTP/1.1 or HTTP/2 or HTTP/3 ?

  74. moparisthebest

    Uh oh it doesn't seem like Wikipedia knows about the APEX protocol

  75. Zash

    Search terms "ietf apex protocol" got me https://datatracker.ietf.org/wg/apex/about/

  76. moparisthebest

    Yea https://duckduckgo.com/?q=apex+protocol is not what I expected either lol

  77. moparisthebest

    I guess that's an advantage for XMPP, the term isn't reused for a thousand unrelated things like simple, apex, and matrix

  78. Zash

    So that apex wg has some RFCs published in 2002. IIRC the XMPP WG got started around that time.

  79. Zash

    > APEX is specified, in part, as a BEEP [1] "profile". I vaguely recognize "BEEP"


    um, is jonas still here?

  81. moparisthebest

    participant list says yes, but you didn't tag him


    > moparisthebest wrote: > participant list says yes, but you didn't tag him is it the same jonas’ that used to maintain the MUC search?

  83. moparisthebest

    says right here how to contact maintainer: https://search.jabber.network/legal


    ahh thanks mate moparisthebest wanted to contact him for info about an old incident