jdev - 2024-07-29


  1. Schimon

    > https://xmpp.pimux.de/file_share/8f8cda18-33b0-45f9-b363-19264e044c2c/blasta.png MattJ. Good day! Despite your comment that `urn:xmpp` is intended for approved XEPs. Because I do not want to cause for a conflict with Movim and Libervia posts, and because I do not want tobrand a node ID, I would want to use `urn:xmpp:bibliography:0`, instead of `urn:blasta:bibliography:0`. This bookmark management software is in testing phases. Please post your objections or conditions.

  2. Schimon

    I will compromise for `urn:bibliography:0`.

  3. flow

    Schimon, did you register the urn:bibliography prefix with IANA?

  4. Schimon

    No

  5. flow

    Schimon, and, fwiw, the urn:xmpp prefix is not intended for approved XEPs, it just requires a registration request with the XSF registrar (at least, that is the theory of operation behind it)

  6. Schimon

    I have not even released the softwaare.

  7. flow

    Schimon, then please don't use the urn:bibliography prefix

  8. jonas’

    Then that is an objection. the URN namespace is for registered uses only. and you should register _before_ releasing.

  9. Schimon

    flow. What should I be using then??

  10. jonas’

    you can always use an UUID-based URN

  11. flow

    Schimon, you could try to get the XSF registrar to register a namespace under urn:xmpp

  12. jonas’

    generate a random UUID, then you can use `urn:uuid:` followed by the UUID.

  13. jonas’

    (a random UUID can be generated with `uuidgen --random` for example)

  14. jonas’

    (a random UUID can be generated on linux with `uuidgen --random` for example)

  15. jonas’

    if you want to make it more readable, I think it is valid to then follow that by :bibliography, but I'd have to look that up

  16. Schimon

    > Schimon, you could try to get the XSF registrar to register a namespace under urn:xmpp flow. Can I do so even if my system, which is based upon XEP-0472 is not yet recognized?

  17. flow

    I'd rather we not promote UUID namespaces due their opaqueness

  18. jonas’

    flow, do you know whether the XSF Registrar keeps a proper registry of urn:xmpp: namespaces outside of XEPs?

  19. Schimon

    jonas’. UUID is fine. I want a node which would be consistent between Jabber IDs, for sharing and system operation purposes.

  20. Schimon

    flow. I have the same question as jonas’

  21. flow

    besides from the registrar being understaffed, there is the registrar git where I would assume that namespace delegations are noted

  22. flow

    basically https://github.com/xsf/registrar/blob/master/namespaces.xml

  23. flow

    of course, it's outdated and unmaintained

  24. flow

    but that doesn't mean that we should try to resurface it if we can

  25. Schimon

    Would it be fine to use node ID `bibliography`, for the time being?

  26. flow

    but that doesn't mean that we should try to resurrect it if we can

  27. Schimon

    Would it be fine to use node ID `bibliography` (without `urn:`, for the time being?

  28. flow

    Schimon, probably not, but you could use urn:bibliography:mything

  29. jonas’

    flow, how is that valid?

  30. jonas’

    urn:bibliography isn't registered at all, so it cannot be used, not as prefix

  31. Schimon

    flow. I suppose that "mything" is the brand part, which I am attempting to avoid. Because if Libervia would want to interact with my system, I do not want to foist my brand on it, which is similar to WMA and WMV audio and video formats which have an unrelated brand associated to them.

  32. Schimon

    I do not know yet what would be the outcome of this discussion, which so far has influenced me to add export features to my project.

  33. flow

    jonas’, sorry, I don't follow that argument. I am not aware of a constraint that you have to register all possible prefixes first

  34. flow

    (the question if such a rule would be sensible is another one)

  35. jonas’

    https://www.rfc-editor.org/rfc/rfc8141.html#section-5

  36. flow

    I am not sure if this applies to how the holder of the urn:xmpp registration. in theory we (the XSF) could handle the registration process however they want. for example, register urn:xmpp:foo:bar in namespaces.xml, even though urn:xmpp:foo is not yet registered in namespaces.xml

  37. flow

    (again, if this is sensible is a different question)

  38. jonas’

    flow, did you miss a `:xmpp` in your statement below? 06:53:46 flow> Schimon, probably not, but you could use urn:bibliography:mything

  39. flow

    jonas’, oh, yes I did, thanks!

  40. flow

    I can see how this is causing confusion

  41. flow

    Schimon, I mean urn:xmpp:bibliography:mything

  42. flow

    Schimon, I meant urn:xmpp:bibliography:mything

  43. flow

    hmm, looking at namespaces.xml, I wonder if it is sensible to register namespaces with the version number. see for example urn:xmpp:http:upload:0

  44. Schimon

    flow. As I recall, MattJ has stated that `urn:xmpp:` is reseved to approved XEPs, or approved "something else" which I do not recall exactly.

  45. flow

    Schimon, the point is, I believe it is *not* only for approved XEPs

  46. flow

    everyone can ask the XSF registrar to register a namespace

  47. flow

    otherwise you would have to potentially switch namespaces on approval

  48. flow

    which is something we definetly want to avoid

  49. Schimon

    > Schimon, software should not use xmpp:* namespaces without a XEP Fri 07 Jun 2024 01:01:57 PM - MattJ: > Schimon, software should not use xmpp:* namespaces without a XEP

  50. jonas’

    go with an UUID and avoid that procedural mess.

  51. Schimon

    flow. What do you think of UUID? This is a temporary measure until we decide what node name to use.

  52. flow

    Schimon, themprorary namespaces are bad, don't do it

  53. flow

    Schimon, temprorary namespaces are bad, don't do it

  54. flow

    and UUIDs are opaque, which makes the protocol a lot less accessible and debuggable

  55. flow

    (as you see, I have a different opinion as jonas’ regarding UUIDs. sorry about that)

  56. flow

    if you don't want to use urn:, then simply use a https namespace with a domain you control/own

  57. jonas’

    (and which you vow to hold and own forever)

  58. jonas’

    (though you can then just also use dns: or an xmpp: (not urn:xmpp:!) URI :))

  59. jonas’

    the advantage of UUIDs is that you don't need anyones approval and you don't need to invest money to hold it

  60. flow

    sure, that's an advantage, but then again, nobody will sanction you if our lost interested in your project and give up its DNS name

  61. flow

    I think in many cases either the projects are "successful", then so will their web presence, or not

  62. pulkomandy

    If tou don't want to register something with some authority and you already have a dns domain name, you could use tag: uris https://www.rfc-editor.org/rfc/rfc4151

  63. pulkomandy

    (the uri contains the domain name but also a timestamp of when you owned that domain name, so if the domain later expires, that's not a problem)

  64. Zash

    or http:// https:// with your own domain, or even xmpp: + your domain

  65. singpolyma

    Schimon: does your thing not have any use for publishing possibly multiple collections of bookmarks? I'm really surprised it needs a "default" node at all. If it follows the history of social bookmark managers people are mostly going to browse, right?

  66. Zash

    > browse https://xmpp.org/extensions/xep-0195.html 🤔️

  67. singpolyma

    Zash: that one benefitted slightly from a default node ID because it was a real time use case

  68. nicoco__

    Slidged rooms have "muc_nonanonymous" in their disco#info which some clients display to users as "your JID is visible to everybody". In fact, it is the "bridger network user ID" that is visible to all other "bridged network users". Any thought on how to improve that? Note that _some_ bridges will expose your JID though, eg bifrost, the "~official" XMPP/Matrix bridge.

  69. singpolyma

    You *could* remove that flag Though maybe it triggers other behaviours you want

  70. nicoco__

    Slidged rooms have "muc_nonanonymous" in their disco#features which some clients display to users as "your JID is visible to everybody". In fact, it is the "bridger network user ID" that is visible to all other "bridged network users". Any thought on how to improve that? Note that _some_ bridges will expose your JID though, eg bifrost, the "~official" XMPP/Matrix bridge.

  71. nicoco__

    Maybe it has no consequences to remove, but it does not feel right. All muc participants have "puppet JIDs" and who knows, slidge might support a network where semianon rooms are a thing someday…

  72. singpolyma

    More accurate would be "any member will be able to contact you directly" but this is a UX matter if taste thing

  73. nicoco__

    That's what I wonder.

  74. singpolyma

    Well, if there was a backend where jid was exposed you could put the flag back on just for that backend

  75. nicoco__

    Should I try to convince client devs to change the wording? Or should I try to convince them to change the wording if there is a specific feature, eg "muc_nonanonymous_but_in_fact_its_not_your_jid_that_is_exposed_so_dont_make_users_worry_about_it"

  76. nicoco__

    > Well, if there was a backend where jid was exposed you could put the flag back on just for that backend I'm more worried about breaking some other "private group"-only features client might have, but maybe there are actually not any?

  77. nicoco__

    > Well, if there was a backend where jid was exposed you could put the flag back on just for that backend I don't think that will ever be a thing, I was more talking about a case where a bridged does have semianonymous rooms, but I don't even know if there are such networks outside ours.

  78. singpolyma

    IMO you're never going to get every client to do the same thing anyway, and this is kind of the whole point of a federated network, so you'll always need docs for someone doing something is your users use that client. So you can make arguments about the wording of this message and maybe some will listen but I wouldn't make anything depend on such success

  79. singpolyma

    nicoco__: if it's actually a private group usually you don't get this kind of message

  80. singpolyma

    >> Well, if there was a backend where jid was exposed you could put the flag back on just for that backend > I don't think that will ever be a thing, I was more talking about a case where a bridged does have semianonymous rooms, but I don't even know if there are such networks outside ours. I'm confident no one else has or ever will have semi-anon

  81. nicoco__

    > nicoco__: if it's actually a private group usually you don't get this kind of message Hmmmmmm, gajim says "your XMPP address will be visible to everyone in this group" for instance, even if the room is members-only I believe

  82. nicoco__

    But you have a point, the user report that triggered my question today is a telegram channel, and I think it would actually be more accurate to note have this disco#feature here, since (at least some) telegram channels don't allow listing the users. Meh

  83. nicoco__

    But you have a point, the user report that triggered my question today is a telegram channel, and I think it would actually be more accurate to not have this disco#feature here, since (at least some) telegram channels don't allow listing the users. Meh

  84. nicoco__

    > IMO you're never going to get every client to do the same thing anyway, and this is kind of the whole point of a federated network, so you'll always need docs for someone doing something is your users use that client. So you can make arguments about the wording of this message and maybe some will listen but I wouldn't make anything depend on such success Right. XEP-0045 says this feature means "Non-anonymous room in Multi-User Chat (MUC)", which is a ill-defined in a bridge context anyway. This is probably yak-shaving anyway…

  85. singpolyma

    The non anon feature means client can assume it can see a jid for every participant I guess, but not sure how many clients do anything with that assumption

  86. nicoco__

    I'll live with explaining that to curious users who ask about it till I solved some more pressing issues I guess :)

  87. edhelas

    https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2

    ❤ 1
  88. cal0pteryx

    Great news! :)

  89. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/urDqShfd9K1B/image.png

  90. meson

    edhelas: congrats :) That means it will become compatible to current clients supporting 1:1 conferences only too? Does Movim support omemo (yet)?

  91. menel

    It does.

  92. meson

    Thanmk, then https://xmpp.org/software/-comparison/ Isn't up-to-date :)

  93. meson

    Thanks, then https://xmpp.org/software/-comparison/ Isn't up-to-date :)

  94. Schimon

    > Schimon: does your thing not have any use for publishing possibly multiple collections of bookmarks? I'm really surprised it needs a "default" node at all. If it follows the history of social bookmark managers people are mostly going to browse, right? singpolyma. > Does your thing not have any use for publishing possibly multiple collections of bookmarks? No. Blasta is only for URL/URI sharing. Hence I refer to it as bibliography, rather than journal or blog. > I'm really surprised it needs a "default" node at all. If it follows the history of social bookmark managers people are mostly going to browse, right? While viewing node items from Libervia and Movim instances, with Rivista, I have noticed that they have slightly different rules, albeit the format is the same (Atom Syndication Format). So, the fashion by which Blasta makes use and also views of items, differs than Movim and probably Libervia too. I am lesser worried of Libervia, because goffi has implied of his willingness to interoperate with my proposed system, which is not done yet.. What do you mean by browse?

  95. Schimon

    > https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2 Congratulations, edhelas!

  96. singpolyma

    I mean that I expect users are not wanting to subscribe to all the bookmarks of all their contacts, but rather might want to on demand do look at some of the bookmarks of some person or group

  97. Schimon

    singpolyma. Yes, this is a planned feature.

  98. Schimon

    https://xmpp.pimux.de/file_share/487227fb-c9db-4ffd-ae4b-f275dcee8bc4/syndication.xhtml

  99. Schimon

    singpolyma. This is how it would be. And it is still subjected to changes.

  100. singpolyma

    So if they are not subscribing to all bookmarks using +notify style then I'm not sure what having a well-known node name is useful for vs everyone just using whatever nide name they like (eg "singpolyma personal links")

  101. singpolyma

    So if they are not subscribing to all bookmarks using +notify style then I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links")

  102. Schimon

    urn:xmpp:bibliography:0

  103. Schimon

    If you are subscribing directly to a JID, hten you will see all the links. The Blasta system will offer pseudo nodes that would behave similarly to URLs with parameters.

  104. Schimon

    If you are subscribing directly to a JID, then you will see all the links. The Blasta system will offer pseudo nodes that would behave similarly to URLs with parameters.

  105. Schimon

    If you are subscribing directly to a JID, then you will see all the links of that JID. The Blasta system will offer pseudo nodes that would behave similarly to URLs with parameters, to subscribe to a specific set of tags etc..

  106. Schimon

    Pardon. I have read your message again. > I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links") 1) For the Blasta system and other future XMPP bookmark managers and vrowsers to detect the proper node. (I am aware of "type" which goffi has proposed). 2) For the Blasta system to aggregate the relevant node, instead of aggregating a journal which does not fit to the niche of the system.

  107. Schimon

    Pardon. I have read your message again. > I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links") 1) For the Blasta system and other future XMPP bookmark managers and vrowsers to detect the proper node. (I am aware of "type" "XEP-0462: PubSub Type Filtering" which edhelas has proposed). 2) For the Blasta system to aggregate the relevant node, instead of aggregating a journal which does not fit to the niche of the system.

  108. Schimon

    Pardon. I have read your message again. > I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links") 1) For the Blasta system and other future XMPP bookmark managers and vrowsers to detect the proper node. (I am aware of "type" "XEP-0462: PubSub Type Filtering" which edhelas has proposed). 2) For the Blasta system to aggregate the relevant node, instead of aggregating a journal which does not fit to the niche of the system. 3) A uniform node name would save processing power.

  109. Schimon

    s/vrowsers/viewers (readers)

  110. debacle

    > https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2 Custom emojis! How cool is that?

  111. Schimon

    It is cool and important too. Now we can have XMPP and Atom/RSS icons ⚛

  112. Schimon

    I think it is cool and important too. Now we can have XMPP and Atom/RSS icons ⚛

  113. edhelas

    > Custom emojis! How cool is that? Yes

  114. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/aCI0U6QHU7am/image.png

  115. edhelas

    And I have no clue how we'll be able to handle them in reactions, because I have the feeling that it will be the next step and requests from the users :D

  116. singpolyma

    > Pardon. I have read your message again. >> I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links") > 1) For the Blasta system and other future XMPP bookmark managers and vrowsers to detect the proper node. (I am aware of "type" "XEP-0462: PubSub Type Filtering" which edhelas has proposed). > 2) For the Blasta system to aggregate the relevant node, instead of aggregating a journal which does not fit to the niche of the system. > 3) A uniform node name would save processing power. This is exactly what I mean. Using a well known name isn't a great way to filter by type of contents. If for some reason existing metadata fields are not sufficient we can spec a new metadata field

  117. singpolyma

    > And I have no clue how we'll be able to handle them in reactions, because I have the feeling that it will be the next step and requests from the users :D edhelas: I have most of an implementation of this going. My plan is to use reply xep. If a reply is only containing exactly one inline image I consider it a reaction with that custom emoji

  118. Schimon

    Yje existing metadata fields are more than enough. I might want to add link "rel" which is also already available in Atom Stndication Format.

  119. Schimon

    > This is exactly what I mean. Using a well known name isn't a great way to filter by type of contents. If for some reason existing metadata fields are not sufficient we can spec a new metadata field The existing metadata fields are more than enough. I might want to add link "rel" which is also already available in Atom Stndication Format.

  120. singpolyma

    If existing metadata is sufficient then you can avoid having a well known node ID altogether

  121. edhelas

    > edhelas: I have most of an implementation of this going. My plan is to use reply xep. If a reply is only containing exactly one inline image I consider it a reaction with that custom emoji I'd prefer to have a clarification with the Reactions XEP

  122. edhelas

    Because I'd prefer to not have one feature spread across different XEP

  123. singpolyma

    Reactions xep is basically an optimization for a common case IMO

  124. edhelas

    Also your solution doesn't fix the remove/update/several emojis case that Reactions handle really well

  125. edhelas

    If you go this way there's lots of chances that i'll not follow you

  126. singpolyma

    You can remove/update easily with message correction. You're right it's not as optimized for changing many at once, though I've not yet seen a client actually make use of that yet anyway

  127. Schimon

    > Pardon. I have read your message again. > > I'm not sure what having a well-known node name is useful for vs everyone just using whatever node name they like (eg "singpolyma personal links") > 1) For the Blasta system and other future XMPP bookmark managers and vrowsers to detect the proper node. (I am aware of "type" "XEP-0462: PubSub Type Filtering" which edhelas has proposed). > 2) For the Blasta system to aggregate the relevant node, instead of aggregating a journal which does not fit to the niche of the system. > 3) A uniform node name would save processing power. 4) I also fear that using `urn:xmpp:microblog:0` might lead to mixing of porposes and consequently sabotage Movim and Libervia, so a different node for a different purpose should be good.

  128. singpolyma

    Schimon: no one is suggesting using the microblog ID. That would be wrong

  129. Schimon

    Pardon. I thought someone did suggest this, because I use XEP-0472

  130. Schimon

    Pardon. I thought someone did suggest this, because I use XEP-0472.

  131. singpolyma

    I'm suggesting not caring what the node ID is and letting it be any string the publisher wants

  132. singpolyma

    But not reusing unrelated node ids

  133. Schimon

    I understand.