-
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. ↺
-
Schimon
I will compromise for `urn:bibliography:0`.
-
flow
Schimon, did you register the urn:bibliography prefix with IANA?
-
Schimon
No
-
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)
-
Schimon
I have not even released the softwaare.
-
flow
Schimon, then please don't use the urn:bibliography prefix
-
jonas’
Then that is an objection. the URN namespace is for registered uses only. and you should register _before_ releasing.
-
Schimon
flow. What should I be using then??
-
jonas’
you can always use an UUID-based URN
-
flow
Schimon, you could try to get the XSF registrar to register a namespace under urn:xmpp
-
jonas’
generate a random UUID, then you can use `urn:uuid:` followed by the UUID.
-
jonas’
(a random UUID can be generated with `uuidgen --random` for example)✎ -
jonas’
(a random UUID can be generated on linux with `uuidgen --random` for example) ✏
-
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
-
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? ↺
-
flow
I'd rather we not promote UUID namespaces due their opaqueness
-
jonas’
flow, do you know whether the XSF Registrar keeps a proper registry of urn:xmpp: namespaces outside of XEPs?
-
Schimon
jonas’. UUID is fine. I want a node which would be consistent between Jabber IDs, for sharing and system operation purposes.
-
Schimon
flow. I have the same question as jonas’
-
flow
besides from the registrar being understaffed, there is the registrar git where I would assume that namespace delegations are noted
-
flow
basically https://github.com/xsf/registrar/blob/master/namespaces.xml
-
flow
of course, it's outdated and unmaintained
-
flow
but that doesn't mean that we should try to resurface it if we can✎ -
Schimon
Would it be fine to use node ID `bibliography`, for the time being?✎ -
flow
but that doesn't mean that we should try to resurrect it if we can ✏
-
Schimon
Would it be fine to use node ID `bibliography` (without `urn:`, for the time being? ✏
-
flow
Schimon, probably not, but you could use urn:bibliography:mything
-
jonas’
flow, how is that valid?
-
jonas’
urn:bibliography isn't registered at all, so it cannot be used, not as prefix
-
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.
-
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.
-
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
-
flow
(the question if such a rule would be sensible is another one)
-
jonas’
https://www.rfc-editor.org/rfc/rfc8141.html#section-5
-
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
-
flow
(again, if this is sensible is a different question)
-
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
-
flow
jonas’, oh, yes I did, thanks!
-
flow
I can see how this is causing confusion
-
flow
Schimon, I mean urn:xmpp:bibliography:mything✎ -
flow
Schimon, I meant urn:xmpp:bibliography:mything ✏
-
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
-
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.
-
flow
Schimon, the point is, I believe it is *not* only for approved XEPs
-
flow
everyone can ask the XSF registrar to register a namespace
-
flow
otherwise you would have to potentially switch namespaces on approval
-
flow
which is something we definetly want to avoid
-
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 ↺
-
jonas’
go with an UUID and avoid that procedural mess.
-
Schimon
flow. What do you think of UUID? This is a temporary measure until we decide what node name to use.
-
flow
Schimon, themprorary namespaces are bad, don't do it✎ -
flow
Schimon, temprorary namespaces are bad, don't do it ✏
-
flow
and UUIDs are opaque, which makes the protocol a lot less accessible and debuggable
-
flow
(as you see, I have a different opinion as jonas’ regarding UUIDs. sorry about that)
-
flow
if you don't want to use urn:, then simply use a https namespace with a domain you control/own
-
jonas’
(and which you vow to hold and own forever)
-
jonas’
(though you can then just also use dns: or an xmpp: (not urn:xmpp:!) URI :))
-
jonas’
the advantage of UUIDs is that you don't need anyones approval and you don't need to invest money to hold it
-
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
-
flow
I think in many cases either the projects are "successful", then so will their web presence, or not
-
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
-
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)
-
Zash
or http:// https:// with your own domain, or even xmpp: + your domain
-
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?
-
Zash
> browse https://xmpp.org/extensions/xep-0195.html 🤔️
-
singpolyma
Zash: that one benefitted slightly from a default node ID because it was a real time use case
-
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.✎ -
singpolyma
You *could* remove that flag Though maybe it triggers other behaviours you want
-
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. ✏
-
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…
-
singpolyma
More accurate would be "any member will be able to contact you directly" but this is a UX matter if taste thing
-
nicoco__
That's what I wonder.
-
singpolyma
Well, if there was a backend where jid was exposed you could put the flag back on just for that backend
-
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"
-
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? ↺
-
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. ↺
-
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
-
singpolyma
nicoco__: if it's actually a private group usually you don't get this kind of message
-
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 ↺
-
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 ↺
-
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✎ -
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 ✏
-
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… ↺
-
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
-
nicoco__
I'll live with explaining that to curious users who ask about it till I solved some more pressing issues I guess :)
-
edhelas
https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2
❤ 1 -
cal0pteryx
Great news! :)
-
edhelas
https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/urDqShfd9K1B/image.png
-
meson
edhelas: congrats :) That means it will become compatible to current clients supporting 1:1 conferences only too? Does Movim support omemo (yet)?
-
menel
It does.
-
meson
Thanmk, then https://xmpp.org/software/-comparison/ Isn't up-to-date :)✎ -
meson
Thanks, then https://xmpp.org/software/-comparison/ Isn't up-to-date :) ✏
-
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? ↺
-
Schimon
> https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2 Congratulations, edhelas! ↺
-
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
-
Schimon
singpolyma. Yes, this is a planned feature.
-
Schimon
https://xmpp.pimux.de/file_share/487227fb-c9db-4ffd-ae4b-f275dcee8bc4/syndication.xhtml
-
Schimon
singpolyma. This is how it would be. And it is still subjected to changes.
-
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")✎ -
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") ✏
-
Schimon
urn:xmpp:bibliography:0
-
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.✎ -
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. ✏
-
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.. ✏
-
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.✎ -
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. ✏
-
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. ✏
-
Schimon
s/vrowsers/viewers (readers)
-
debacle
> https://mov.im/node/pubsub.movim.eu/Movim/f619c49c-ccd3-4487-8c2e-20b6d3555da2 Custom emojis! How cool is that? ↺
-
Schimon
It is cool and important too. Now we can have XMPP and Atom/RSS icons ⚛✎ -
Schimon
I think it is cool and important too. Now we can have XMPP and Atom/RSS icons ⚛ ✏
-
edhelas
> Custom emojis! How cool is that? Yes ↺
-
edhelas
https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/aCI0U6QHU7am/image.png
-
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
-
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 ↺
-
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 ↺
-
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.✎ -
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. ✏ ↺
-
singpolyma
If existing metadata is sufficient then you can avoid having a well known node ID altogether
-
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 ↺
-
edhelas
Because I'd prefer to not have one feature spread across different XEP
-
singpolyma
Reactions xep is basically an optimization for a common case IMO
-
edhelas
Also your solution doesn't fix the remove/update/several emojis case that Reactions handle really well
-
edhelas
If you go this way there's lots of chances that i'll not follow you
-
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
-
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. ↺
-
singpolyma
Schimon: no one is suggesting using the microblog ID. That would be wrong
-
Schimon
Pardon. I thought someone did suggest this, because I use XEP-0472✎ -
Schimon
Pardon. I thought someone did suggest this, because I use XEP-0472. ✏
-
singpolyma
I'm suggesting not caring what the node ID is and letting it be any string the publisher wants
-
singpolyma
But not reusing unrelated node ids
-
Schimon
I understand.