Hi! XMPP Spaces are now described in https://xmpp.org/extensions/xep-0503.html . A XMPP Space is a Pubsub node that contains bookmarks pointing to MUCs. We would like to have a proper Space URI that allow users to invite easily others to their Spaces. This will be added as a section to XEP 0503. So far a Pubsub node is described in https://xmpp.org/extensions/xep-0060.html#impl-uri I'd like to have something short and transparent so I'm proposing something like this: Proposal 1: xmpp:spaces.server.tld?;node=x56ae32&space I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node) Proposal 2: xmpp:spaces.server.tld?;space=x56ae32 The goals are * to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake * have something short and easily shareable (Discord is having something like this https://discord.gg/AP5HFj7w) If one of the proposals is okay for you I'll propose a PR on 0503 and make the changes in Movim (I'm sure nicoco will be able to do it in Slidge, the other 0503 implementation). Because this is having effect on the XMPP uris format I'm wondering if there's some kind of rules or specific requests to follow ? Regards, edhelas
On 9 Jun 2026, at 13:15, Timothée Jaussoin <edhelas@movim.eu> wrote:
Hi!
XMPP Spaces are now described in https://xmpp.org/extensions/xep-0503.html .
A XMPP Space is a Pubsub node that contains bookmarks pointing to MUCs.
We would like to have a proper Space URI that allow users to invite easily others to their Spaces. This will be added as a section to XEP 0503.
So far a Pubsub node is described in https://xmpp.org/extensions/xep-0060.html#impl-uri
I'd like to have something short and transparent so I'm proposing something like this:
Proposal 1: xmpp:spaces.server.tld?;node=x56ae32&space I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node)
Proposal 2: xmpp:spaces.server.tld?;space=x56ae32 The goals are
to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake have something short and easily shareable (Discord is having something like this https://discord.gg/AP5HFj7w) If one of the proposals is okay for you I'll propose a PR on 0503 and make the changes in Movim (I'm sure nicoco will be able to do it in Slidge, the other 0503 implementation).
We have a similar need to unambiguously reference FDP nodes in URIs, so if we can do something suitably generic here - e.g. [node_uri]payload_type=(space|fdp), that would be tremendously useful to us too. /K
Hi Edhelas, Le mardi 9 juin 2026, 14:15:30 heure d’été d’Europe centrale Timothée Jaussoin a écrit :
[SNIP] I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node)
Proposal 2: xmpp:spaces.server.tld?;space=x56ae32
It's a problem that we already had, and so far I think that the consensus was the query the node to check its type. However I would be happy too to have something in the URI which would avoid a round-trip. I would avoid something tied to space though, and I agree with Kev that we would need something more generic. I see two ways: - `type=urn:xmpp:spaces:0`. The URI would be: `xmpp:spaces.server.tld?;node=123;type=urn:xmpp:spaces:0` That would work and be generic, probably the cleanest option in my opinion, but I understand that you want something more user-friendly. Will those URIs be exposed easily to end-user like an HTTP URL? If not, I suspect that user- friendliness is not that important. - we could use short name, something like `s=spaces`. The URI would then be: `xmpp:spaces.server.tld?;node=123;s=spaces` It could work in most cases and be more user friendly.
* to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake
Why would this be a problem? A pubsub node is generic, a client must expect generic things, and it may be intended to inspect the node or whatever. I'm not keen on removing the `node` query argument, but if there is a consensus on that, I suspect that using it as query type would be better.
Because this is having effect on the XMPP uris format I'm wondering if there's some kind of rules or specific requests to follow ?
I believe that is should go trough registrar: https://xmpp.org/registrar/querytypes.html Best, Goffi
Hi, Using the pubsub#type in the URI would be the cleanest and direct way because it is actually now clearly defined in 0060 and used in many XEPs already: * Spaces: urn:xmpp:spaces:0 * Stories: urn:xmpp:pubsub-social-feed:stories:0 * Social feed: urn:xmpp:pubsub-social-feed:1 * .... It is not "user-friendly" as I expected but I'll build something on top of that in Movim that will resolve to this URI. So we need to complete the XMPP Pubsub URI definition to include a new `type` parameter? Regards, edhelas Le 09/06/2026 à 16:10, Goffi a écrit :
Hi Edhelas,
Le mardi 9 juin 2026, 14:15:30 heure d’été d’Europe centrale Timothée Jaussoin a écrit :
[SNIP] I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node)
Proposal 2:xmpp:spaces.server.tld?;space=x56ae32 It's a problem that we already had, and so far I think that the consensus was the query the node to check its type. However I would be happy too to have something in the URI which would avoid a round-trip. I would avoid something tied to space though, and I agree with Kev that we would need something more generic. I see two ways:
- `type=urn:xmpp:spaces:0`. The URI would be: `xmpp:spaces.server.tld?;node=123;type=urn:xmpp:spaces:0` That would work and be generic, probably the cleanest option in my opinion, but I understand that you want something more user-friendly. Will those URIs be exposed easily to end-user like an HTTP URL? If not, I suspect that user- friendliness is not that important.
- we could use short name, something like `s=spaces`. The URI would then be: `xmpp:spaces.server.tld?;node=123;s=spaces` It could work in most cases and be more user friendly.
* to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake Why would this be a problem? A pubsub node is generic, a client must expect generic things, and it may be intended to inspect the node or whatever.
I'm not keen on removing the `node` query argument, but if there is a consensus on that, I suspect that using it as query type would be better.
Because this is having effect on the XMPP uris format I'm wondering if there's some kind of rules or specific requests to follow ? I believe that is should go trough registrar: https://xmpp.org/registrar/querytypes.html
Best, Goffi
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
Hi edhelas, Le mardi 16 juin 2026, 10:24:29 heure d’été d’Europe centrale Timothée Jaussoin a écrit :
Hi,
Using the pubsub#type in the URI would be the cleanest and direct way because it is actually now clearly defined in 0060 and used in many XEPs already:
* Spaces: urn:xmpp:spaces:0 * Stories: urn:xmpp:pubsub-social-feed:stories:0 * Social feed: urn:xmpp:pubsub-social-feed:1 * ....
It is not "user-friendly" as I expected but I'll build something on top of that in Movim that will resolve to this URI.
Great, that's the cleanest option indeed.
So we need to complete the XMPP Pubsub URI definition to include a new `type` parameter?
I guess so. probably a PR to https://github.com/xsf/registrar/blob/master/ querytypes.xml would do it. Don't know if XEP-0060 should be updated too, that would make finding it easier. Best, Goffi
Hi, I've opened a PR with the change there: https://github.com/xsf/registrar/pull/52 Lets see where it goes. Regards, edhelas Le 16/06/2026 à 10:34, Goffi a écrit :
Hi edhelas,
Le mardi 16 juin 2026, 10:24:29 heure d’été d’Europe centrale Timothée Jaussoin a écrit :
Hi,
Using the pubsub#type in the URI would be the cleanest and direct way because it is actually now clearly defined in 0060 and used in many XEPs already:
* Spaces: urn:xmpp:spaces:0 * Stories: urn:xmpp:pubsub-social-feed:stories:0 * Social feed: urn:xmpp:pubsub-social-feed:1 * ....
It is not "user-friendly" as I expected but I'll build something on top of that in Movim that will resolve to this URI. Great, that's the cleanest option indeed.
So we need to complete the XMPP Pubsub URI definition to include a new `type` parameter? I guess so. probably a PR to https://github.com/xsf/registrar/blob/master/ querytypes.xml would do it. Don't know if XEP-0060 should be updated too, that would make finding it easier.
Best, Goffi
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (3)
-
Goffi -
Kevin Smith -
Timothée Jaussoin