XSF Discussion - 2023-06-30

  1. goffi

    Hi, first search result on duckduckgo for "XMPP client" is the old list (curiously named "new"): https://new.xmpp.org/software/clients.html, and once you are there, all links stay there. Is there any reason to keep it, and would not is be better to redirect it the new website (the one without "new" in the URL :) ) ? And BTW thanks to the people involved, it's really neat (and I really need to do this DOAP thing).

  2. cal0pteryx

    TIL about new.xmpp.org Surely this should be redirected goffi: ping me if you need help re DOAP :)

  3. goffi

    cal0pteryx: thank you, but I mostly need time :). I have most of data already set in the code, I need to make a script to generate automatically the DOAP file.

  4. goffi

    I'll open a ticket for that

  5. goffi

    (the xmpp.org redirection)

  6. cal0pteryx

    No, I already posted it in infrastructure@

  7. goffi

    oh, so an issue is not needed?

  8. goffi

    right, thanks

  9. MattJ


  10. MattJ

    Confirmed that searching on DDG and clicking that link now takes you to the right place

  11. MattJ

    Thanks for noticing :)

  12. goffi

    great, thanks MattJ

  13. Trung

    RSS/Atom have `<email>` but not `</xmpp>` does it :\

  14. Zash

    https://datatracker.ietf.org/doc/html/rfc4287#section-3.2.2 `<uri>xmpp:trung@example.net</uri>` ought to be fine

  15. Trung

    oh is that legal? cool (abit messy but ok)

  16. Zash

    Mentally rewrite <email> to <uri>mailto: ;)

  17. Trung


  18. goffi

    edhelas: could XEP-0469: Bookmark Pinning be used for individual contacts? I feel that it would make sense to use it for important contacts so they appear first.

  19. Seve

    specially between different clients ๐Ÿ˜•

  20. lovetox

    This XEP makes not much sense, i think this was recognized

  21. lovetox

    This XEP makes not much sense, i think this was recognized earlier

  22. goffi

    lovetox: why?

  23. lovetox

    exactly because of what you say

  24. lovetox

    its written as an extension of the Bookmarks XEP

  25. lovetox

    meaning it only applies to MUC Bookmarks

  26. lovetox

    but every client that allows Pinning, allows Pinning Conversations, and not only MUCs

  27. Zash

    Unified bookmarks + roster?

  28. Zash

    (time for?)

  29. lovetox

    i would probably add a new pubsub node `xmpp:conversation:metadata:1` or something

  30. lovetox

    and define there a <pinning>

  31. lovetox

    and the item id = jid or somethng

  32. goffi

    wait PEP bookmark is only for chatrooms? I have not yes implementing it, and was assuming it was more general than that

  33. Zash

    roster in PEP? ๐Ÿคฃ๏ธ

  34. Zash

    goffi, correct

  35. goffi

    I want to be able to bookmark pubsub nodes too.

  36. MattJ

    Time for unified roster + group bookmarks + pubsub bookmarks!

  37. lovetox

    its a storage to discover which MUCs you are joined, and what nick you use there, and nothing else

  38. goffi

    now that we have pubsub encryption, I'm thinking about having roster metadata on pubsub for a while actually (everything but the JID and presence subscription that are useful to server)

  39. Zash

    encrypted messaging over pubsub?

  40. goffi

    OK so now, how can I do pubsub bookmark, write yet another bookmark extension (this time it's *really* serious), or PEP Native Bookmark can be extended to handle pubsub items?

  41. singpolyma

    There's no reason bookmarks has to be used only for MUC. The spec does imply it's for group chats / chatrooms but is intentionally silent in what protocol the room speak IIRC

  42. goffi

    singpolyma: but it's a room, not a pubsub node.

  43. singpolyma

    I've been thinking to use pep vcard4 for extended roster data

  44. singpolyma

    goffi: what is a room? What is a pusbsub node?

  45. singpolyma

    These are just ideas

  46. lovetox

    what is xmpp? am i even alive?

  47. MattJ

    IIRC the original spec explicitly said bookmarks were for anything (allowing URLs, etc.), but this was hardly ever used in 20 years, and just complicates clients (most would probably choke on discovering a https:// or pubsub URI)

  48. Seve


  49. Seve

    > what is xmpp? am i even alive? ๐Ÿ˜‚๏ธ

  50. MattJ

    I didn't know the newer spec narrowed the scope, but I think that was sensible

  51. Zash

    Rename it MUC Roster? :)

  52. goffi

    MattJ: yeah in the old time, but nowadays some clients are doing a bit more that chat.

  53. goffi

    there is an extension field though

  54. goffi

    and no attribute is mandatory

  55. MattJ

    XMPP has been used for more than chat for a long time :)

  56. MattJ

    Things have definitely put non-MUCs in bookmarks before

  57. goffi

    so beside the unadapted name `conference`, I guess that we can bookmark anything with extensions.

  58. lovetox

    > Each item SHALL have, as item id, the Room JID of the chatroom

  59. singpolyma

    Right, it says that, but "chatroom" is explicitly not the same as "MUC" per the xep

  60. goffi

    It explicitely says that `<conference xmlns='urn:xmpp:bookmarks:1'/>` is valid

  61. goffi

    (not very useful though)

  62. singpolyma

    Yeah, extensions-only seems silly just use another pep node in sun a case imo

  63. singpolyma

    I think the spec is written not do require muc in order to allow for mix

  64. singpolyma

    But in practise that means one ought to be prepared to find things which are not a MUC and which one might not understand there

  65. goffi

    singpolyma: so you suggest an other bookmark XEP?

  66. goffi

    for anything but chat rooms?

  67. lovetox

    why not Pubsub nodes?

  68. MSavoritias fae.ve

    we need more bookmark systems \o/

  69. lovetox

    why do we need one node storage for *Everything*

  70. singpolyma

    goffi: no. I was just saying if you're adding things that are only extensions then that's a sign you're just making stuff up anyway. I'm fine to take a broad view on "chat room" and there's no real difference between a pubsub node and a MUC for most purposes. But it may depend what you want

  71. MattJ

    lovetox, I agree

  72. goffi

    It's not the point of having a node for everything, it's to have a well-defined feature (bookmark here), with all we need (name, pinning, whatever), and usable for various use cases (MUC, MIX, single entities, pubsub nodes, etc).

  73. goffi

    otherwise, it's reinventing the wheel for a very similar feature.

  74. lovetox

    the xep is about Groupchat Bookmarks

  75. goffi

    the XEP is named `PEP Native Bookmark` not `groupchat bookmark`

  76. goffi

    bookmarks* actually

  77. lovetox

    yeah and ? as i posted before the item id must be a jid of a groupchat protocol entity

  78. lovetox

    that makes it pretty clear for what this is

  79. singpolyma

    If we wanted it to be explicitly for other things we can edit that line

  80. goffi

    yeah, the use case was just not anticipated

  81. singpolyma

    Bookmarks only exist because roster implies presence subscription stuff you sometimes don't want

  82. singpolyma

    Otherwise we'd use roster

  83. lovetox

    this is already a stable XEP implemented by many clients

  84. lovetox

    you would need to show some real gain from adding stuff to this XEP that had nothing to do with its initial state

  85. singpolyma

    Bookmarks2? Are there many clients implementing? I thought only 2 or 3

  86. lovetox

    i would say this will be very hard, and its much easier to simply write a new XEP with your use case

  87. goffi

    oh right I've missed the "stable" thing, great. So I guess the way to go is yet another XEP.

  88. singpolyma

    Stable doesn't mean final :P

  89. lovetox

    and just my opinion, its very hard to write XEPs for future use cases which you cannot define, have no examples for

  90. lovetox

    especially my experience with XEPs in XMPP is

  91. lovetox

    the more narrow they are, the easier you get them implemented and used

  92. singpolyma

    For sure. A XEP should only be written after there is experience with deployed implemention IMO

  93. Zash


  94. Zash

    Write the code or the spec first, the age old question :)

  95. singpolyma

    Why not both? But write the spec on your wiki until the code is ready

  96. Zash

    That's what Experimental is for, I would think

  97. goffi

    so to answer my initial question, XEP-0469: Bookmark Pinning can't be used for individual entities due to the use of XEP-0402

  98. singpolyma

    For after you've got at least one implementation but not two or three yet I guess

  99. singpolyma

    goffi: can't is strong. But if you do Weird Thingsโ„ข may happen in some clients

  100. singpolyma

    New pep node just to list pinned things?

  101. goffi

    new XEP to handle bookmark like use case for single entities, pubsub nodes, URLs, or whatever with pinning built-in.

  102. singpolyma

    Call it Roster 3.0 (now with bookmarks!)

  103. goffi

    and explicitely exclude group chat to redirect to 402 avoid more mess with that.

  104. goffi


  105. lovetox

    how many things do you really have to bookmark?

  106. singpolyma

    goffi: for individual entities vcard4 xep is also a good choice imo

  107. lovetox

    sounded to me you just want to bookmark pubsub ndoes

  108. goffi

    I want to pin inididual entities, bookmark pubsub nodes, and may need other stuff in the futur.

  109. goffi

    for instance, I need to know which calendar events I'm following.

  110. singpolyma

    Oh right. I now realize why were talking about pubsub nodes. They don't have JIDs

  111. singpolyma

    I forgot that for this whole conversation

  112. edhelas

    > edhelas: could XEP-0469: Bookmark Pinning be used for individual contacts? I feel that it would make sense to use it for important contacts so they appear first. I guess so :)

  113. edhelas

    Can you bookmark contacts ? ๐Ÿค”

  114. singpolyma

    edhelas: no-ish see above

  115. singpolyma

    I'm suggesting use some vcard4 property for this

  116. singpolyma

    I need to look at vcard4 spec to make a more concrete suggestion but I think there is a priority and if not there is definitely category

  117. Zash

    Wouldn't surprise me if the vcard* spec has some favorite property

  118. Zash

    Wouldn't surprise me if the vcard* spec has some 'favorite' property

  119. goffi

    singpolyma: they do have a JID, but it is associated with a node.

  120. singpolyma

    goffi: the pubsub service has a jidz and then that + node is the node. But you can't write the node are part of a JID only an xmpp uri

  121. singpolyma

    Zash: right. I have to look

  122. goffi

    singpolyma: indeed

  123. Zash

    Does anything do https://xmpp.org/extensions/xep-0292.html#contacts yet?

  124. goffi

    it may make more sense to use several node as mentioned above, otherwise it may be inefficient to filter if we have a high number of things to bookmark.

  125. singpolyma

    Zash: that's the vcard4 xep? I think so but I'm adding it soon

  126. singpolyma

    Zash: that's the vcard4 xep? I think no but I'm adding it soon

  127. Zash

    singpolyma, the part of the vcard4 xep about storing contacts details

  128. singpolyma

    Zash: yes. That's what I meant

  129. lovetox

    no lets load everything into one node, i love to download stuff i never need on every connect

  130. goffi

    lovetox: pubsub is made to not download the whole stuff each time.

  131. lovetox

    Yeah how would that work for bookmarks?

  132. lovetox

    How do I get only items which changed while I was offline ?