Re: XMPP Spaces URIs

Timothée Jaussoin <[email protected]> Tue, 16 Jun 2026 10:24:29 +0200
Newsgroups gmane.network.jabber.standards-jig
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============5933520968907209593==
Content-Type: multipart/alternative;
 boundary="------------Z11JzJG617QU1kQXU4eL4UwI"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------Z11JzJG617QU1kQXU4eL4UwI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Using the pubsub#type in the URI would be the cleanest and direct way=20
because it is actually now clearly defined in 0060 and used in many XEPs=20
already:

  * Spaces:=C2=A0urn:xmpp:spaces:0
  * Stories:=C2=A0urn:xmpp:pubsub-social-feed:stories:0
  * Social feed:=C2=A0urn:xmpp:pubsub-social-feed:1
  * ....

It is not "user-friendly" as I expected but I'll build something on top=20
of that in Movim that will resolve to this URI.

So we need to complete the XMPP Pubsub URI definition to include a new=20
`type` parameter?

Regards,

edhelas

Le 09/06/2026 =C3=A0 16:10, Goffi a =C3=A9crit=C2=A0:
> Hi Edhelas,
>
> Le mardi 9 juin 2026, 14:15:30 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99=
Europe centrale Timoth=C3=A9e Jaussoin
> a =C3=A9crit :
>> [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=3Dx56ae32
> It's a problem that we already had, and so far I think that the consens=
us was
> the query the node to check its type. However I would be happy too to h=
ave
> something in the URI which would avoid a round-trip. I would avoid some=
thing
> tied to space though, and I agree with Kev that we would need something=
 more
> generic. I see two ways:
>
> - `type=3Durn:xmpp:spaces:0`.
> The URI would be: `xmpp:spaces.server.tld?;node=3D123;type=3Durn:xmpp:s=
paces:0`
> That would work and be generic, probably the cleanest option in my opin=
ion,
> 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=3Dspaces`.
> The URI would then be: `xmpp:spaces.server.tld?;node=3D123;s=3Dspaces`
> 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 ex=
pect
> 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 bette=
r.
>
>> 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 [email protected]
> To unsubscribe send an email [email protected]
--------------Z11JzJG617QU1kQXU4eL4UwI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <p>Hi,</p>
    <p>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:</p>
    <ul>
      <li>Spaces:=C2=A0urn:<a class=3D"moz-txt-link-freetext" href=3D"xmp=
p:spaces:0">xmpp:spaces:0</a></li>
      <li>Stories:=C2=A0urn:<a class=3D"moz-txt-link-freetext" href=3D"xm=
pp:pubsub-social-feed:stories:0">xmpp:pubsub-social-feed:stories:0</a></l=
i>
      <li>Social feed:=C2=A0urn:<a class=3D"moz-txt-link-freetext" href=3D=
"xmpp:pubsub-social-feed:1">xmpp:pubsub-social-feed:1</a></li>
      <li>....</li>
    </ul>
    <p>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.</p>
    <p>So we need to complete the XMPP Pubsub URI definition to include
      a new `type` parameter?</p>
    <p>Regards,</p>
    <p>edhelas</p>
    <div class=3D"moz-cite-prefix">Le 09/06/2026 =C3=A0 16:10, Goffi a =C3=
=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:[email protected]=
g">
      <pre wrap=3D"" class=3D"moz-quote-pre">Hi Edhelas,

Le mardi 9 juin 2026, 14:15:30 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99Eu=
rope centrale Timoth=C3=A9e Jaussoin=20
a =C3=A9crit :
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"" class=3D"moz-quote-pre">[SNIP]
I'm wondering if something shorter like this is possible ? (where the=20
client is resolving the "space" parameter as the Pubsub node)

Proposal 2: <a class=3D"moz-txt-link-freetext" href=3D"xmpp:spaces.server=
.tld?;space=3Dx56ae32">xmpp:spaces.server.tld?;space=3Dx56ae32</a>
</pre>
      </blockquote>
      <pre wrap=3D"" class=3D"moz-quote-pre">
It's a problem that we already had, and so far I think that the consensus=
 was=20
the query the node to check its type. However I would be happy too to hav=
e=20
something in the URI which would avoid a round-trip. I would avoid someth=
ing=20
tied to space though, and I agree with Kev that we would need something m=
ore=20
generic. I see two ways:

- `type=3Durn:<a class=3D"moz-txt-link-freetext" href=3D"xmpp:spaces:0">x=
mpp:spaces:0</a>`.=20
The URI would be: `<a class=3D"moz-txt-link-freetext" href=3D"xmpp:spaces=
.server.tld?;node=3D123;type=3Durn:xmpp:spaces:0">xmpp:spaces.server.tld?=
;node=3D123;type=3Durn:xmpp:spaces:0</a>`
That would work and be generic, probably the cleanest option in my opinio=
n,=20
but I understand that you want something more user-friendly. Will those U=
RIs=20
be exposed easily to end-user like an HTTP URL? If not, I suspect that us=
er-
friendliness is not that important.

- we could use short name, something like `s=3Dspaces`.
The URI would then be: `<a class=3D"moz-txt-link-freetext" href=3D"xmpp:s=
paces.server.tld?;node=3D123;s=3Dspaces">xmpp:spaces.server.tld?;node=3D1=
23;s=3Dspaces</a>`
It could work in most cases and be more user friendly.

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"" class=3D"moz-quote-pre">  * to prevent non "space-=
ready" XMPP clients to open it as a Pubsub
    node by mistake
</pre>
      </blockquote>
      <pre wrap=3D"" class=3D"moz-quote-pre">
Why would this be a problem? A pubsub node is generic, a client must expe=
ct=20
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=20
consensus on that, I suspect that using it as query type would be better.

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"" class=3D"moz-quote-pre">Because this is having eff=
ect on the XMPP uris format I'm wondering if
there's some kind of rules or specific requests to follow ?
</pre>
      </blockquote>
      <pre wrap=3D"" class=3D"moz-quote-pre">
I believe that is should go trough registrar:
<a class=3D"moz-txt-link-freetext" href=3D"https://xmpp.org/registrar/que=
rytypes.html">https://xmpp.org/registrar/querytypes.html</a>


Best,
Goffi</pre>
      <br>
      <fieldset class=3D"moz-mime-attachment-header"></fieldset>
      <pre wrap=3D"" class=3D"moz-quote-pre">____________________________=
___________________
Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m=
ailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:[email protected]">[email protected]</a>
</pre>
    </blockquote>
  </body>
</html>

--------------Z11JzJG617QU1kQXU4eL4UwI--

--===============5933520968907209593==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============5933520968907209593==--