New XEP proposal: Spaces
Hello everyone, I just submitted https://github.com/xsf/xeps/pull/1426 with a rendered version at https://nicoco.fr/inbox/spaces.html This is an attempt at a minimal "spaces XEP". I remember reading a document a long time ago which looked impressively complete but did not turn into a XEP proposal. I suspect this is because the document attempted to cover everything, and there are very different use-cases for spaces, with different permissions models, ranging from fully public to completely private through "some rooms are public but some require being part of a subteam" etc. I tried a different approach here, attempting to lay the foundation of what is the minimum to cluster several groupchats without relying on a dedicated MUC service just for that. The slidge-based gateways for discord, mattermost and matrix already implement listing the "servers", "teams" and "spaces" of these networks via adhoc commands. I would very much like to make this a bit more generic (and standardised!) in slidge "core", the gateway library (and also expose in the disco#info of each room which "space" it is a child of). About the name, I called it "server-side spaces" because I think what Gajim already does with its workspaces is great and should be standardized at some point too, that would be another XEP, maybe "client(or user)-side spaces", later. I already gathered a little feedback from the xsf@ room, and incorporated it in the present submission. Looking forward to reading your feedback. -- nicoco
Spaces / servers / teams are basically different ways to group users. Any implementation of some group chat (MUC, or our groups) already do that. Just take the list of members and build your additional functionality on it. On Sun, 23 Feb 2025 at 21:23, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
Hello everyone,
I just submitted https://github.com/xsf/xeps/pull/1426 with a rendered version at https://nicoco.fr/inbox/spaces.html
This is an attempt at a minimal "spaces XEP".
I remember reading a document a long time ago which looked impressively complete but did not turn into a XEP proposal. I suspect this is because the document attempted to cover everything, and there are very different use-cases for spaces, with different permissions models, ranging from fully public to completely private through "some rooms are public but some require being part of a subteam" etc. I tried a different approach here, attempting to lay the foundation of what is the minimum to cluster several groupchats without relying on a dedicated MUC service just for that.
The slidge-based gateways for discord, mattermost and matrix already implement listing the "servers", "teams" and "spaces" of these networks via adhoc commands. I would very much like to make this a bit more generic (and standardised!) in slidge "core", the gateway library (and also expose in the disco#info of each room which "space" it is a child of).
About the name, I called it "server-side spaces" because I think what Gajim already does with its workspaces is great and should be standardized at some point too, that would be another XEP, maybe "client(or user)-side spaces", later.
I already gathered a little feedback from the xsf@ room, and incorporated it in the present submission.
Looking forward to reading your feedback.
-- nicoco
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Spaces / servers / teams are basically different ways to group users. Sometimes it's just that, sometimes it's less (just a way to group rooms), sometimes it's more (more complex access control/roles/stuff). You illustrate the point that there are a lot of different expectations from spaces and definitions of them. Just take the list of members and build your additional functionality on it.
My proposal explicitly allows that. But more importantly, I'm not looking to build _my_ functionality, I view the standards process as a way to get something out there that satisfies the needs of many, and that can be used across the standard federated XMPP network. There are enough non-interoperable chat silos already IMHO. -- nicoco
I just submitted https://github.com/xsf/xeps/pull/1426 with a rendered version at https://nicoco.fr/inbox/spaces.html
Fetching the list of rooms that are children of a space is done via a disco#items directed at the JID of the space on the urn:xmpp:spaces:0 node. Using a node on top of the JID makes it possible for a space to be a room itself, which is possible but not required by this specification.
I don't think using a node is needed to fulfill this requirement. Any MUCs found as items on a MUC would be members surely? And any items on a space JID would be items in that space surely. If we decide a node *is* needed, I think the node needs a name related to what it is. Naming the node the same name you suggest for a list of spaces to list the items in a space is confusing IMO.
Thank you singpolyma for a very prompt feedback.
Fetching the list of rooms that are children of a space is done via a disco#items directed at the JID of the space on the urn:xmpp:spaces:0 node. Using a node on top of the JID makes it possible for a space to be a room itself, which is possible but not required by this specification.
I don't think using a node is needed to fulfill this requirement. Any MUCs found as items on a MUC would be members surely? And any items on a space JID would be items in that space surely.
In https://xmpp.org/extensions/xep-0045.html#disco-roomitems
An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.
So a spaces-capable public MUC room would return both its occupants and its children rooms, all mixed up together? I can see that working, since occupants have a resource part, while MUC rooms don't, so we have a (fragile?) heuristic to discriminate the two. Also, maybe MUC services actually do not implement this MAY for various reasons. I am not against removing this node and just doing the disco#items dance on the space JID without node. I put it there because I was worried mixing occupants and children rooms would be a source of trouble for clients. I wonder what other client devs think about this. Maybe no actual implementation relies on disco#items queries on a room so it does not matter?
If we decide a node *is* needed, I think the node needs a name related to what it is. Naming the node the same name you suggest for a list of spaces to list the items in a space is confusing IMO.
Maybe we won't need it at all as you, but if we do, let's make it "urn:xmpp:space" (singular) then? -- nicoco
If we decide a node *is* needed, I think the node needs a name related to what it is. Naming the node the same name you suggest for a list of spaces to list the items in a space is confusing IMO.
Maybe we won't need it at all as you, but if we do, let's make it "urn:xmpp:space" (singular) then?
or maybe spaces#items or similar?
Replying here to an email that was sent to me instead of the list.
https://nicoco.fr/inbox/spaces.html I really do not want this and think interest in this will die out as soon as the discord fad dies out. XMPP doesn't need to be a clone of the $current_popular_thing to be successful. This is not an attempt to be a clone of discord. If anything, I believe Slack was the first chat network to popularize its "workspaces". Not wanting it is fine, it's not like I or even the XSF have power to force anything onto anybody. It is a recurring demand from end-users though, mostly "power users" whom I believe often drive adoption to larger audiences. Example, this mastodon post by the maintainer of Pelican (open source static site generator) https://pouet.pas.la/@justin@ramble.space/114037448802034316 Its also made completely redundant by disco and the ability to have multiple muc hosts running on a different subdomain: Eg, specific.interest.muc.hostingprovider.tld You assume that everyone self-hosts. I'm all for a federated network of small servers, but everyone self-hosting does not seem realistic or even desirable to me. A MUC service being a space is briefly mentioned in the introduction, but I will update it to explain why this is not enough. This works for Usenet. I don't think this is how Usenet works at all. Do you need to host a Usenet server in order to create a group? Also, I don't think I made it mandatory in the spec to have a local part for the space JID, so a space JID can very well be knitting.example.org, with rooms having JIDs such as room1@knitting.example.org. This is probably more annoying to implement, except with XEP-0225 but for some reasons (maybe some are valid?) it seems it was never implemented by any server.
-- nicoco
Nicolas. Good day.
I just submitted https://github.com/xsf/xeps/pull/1426 with a rendered version at https://nicoco.fr/inbox/spaces.html
Would it be relevant to also include PubSub nodes? I think, that, in near future, PubSub nodes will be extensively utilized as feeds that would also be affiliated to group chats of choice, so I think that PubSub nodes should be considered as an (optionally) integral part of group chats. PubSub allows constant storage which would be useful to group chats in cases of: 1. A group chat of a discussion of a series of movies that can be downloaded from the affiliated PubSub node. 2. A group chat of researchers that would store documents and articles over a PubSub node. 3. etc. If this is not related. Please ignore this message. Kind regards, Schimon
Would it be relevant to also include PubSub nodes?
As stated in the introduction, I would ideally like this specification to stay narrow-scoped and short, so I would rather let it stay focused on a "collection of room", using existing mechanisms as much as possible. That said, adding another type of entities in the list returned by disco#items on a space sounds very possible, maybe with a namespaced "spaces:type" attribute for the <items>, or by running addressing disco#items directed at different node, eg, "space#pubsub-nodes". Why not, but again, I would like to avoid falling into the perfect, extensive solution that no one will implement. Having an editable collection of rooms would already be a nice addition for our MUC services IMHO. -- nicoco
Nicolas, I thank you very much for your respond. ~ Schimon On Mon, 24 Feb 2025 15:40:03 +0100 Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
Would it be relevant to also include PubSub nodes?
As stated in the introduction, I would ideally like this specification to stay narrow-scoped and short, so I would rather let it stay focused on a "collection of room", using existing mechanisms as much as possible.
That said, adding another type of entities in the list returned by disco#items on a space sounds very possible, maybe with a namespaced "spaces:type" attribute for the <items>, or by running addressing disco#items directed at different node, eg, "space#pubsub-nodes". Why not, but again, I would like to avoid falling into the perfect, extensive solution that no one will implement.
Having an editable collection of rooms would already be a nice addition for our MUC services IMHO.
-- nicoco
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Nicolas, I think having an option for Spaces makes sense. I’ll provide just some light feedback. Take this with a huge handful of salt, as I’m fairly new to this list. As both an end-user and moderator/admin, I’d like to be able to organise chats both: 1) as a moderator of e.g. a hackerspace/LUG, which I think your proposal covers well; and 2) as an end-user, group (or tag) chats (or even spacer) to have them organised by myself on how I see fit – e.g. all “fun” chats in one group/ space, all “Slovenian orgs” in another, etc. I can already do something like what 2) describes in Gajim, but I would like to keep this organisation throughout all the clients that I use. It may be 2) is outside the scope of Spaces though, in which case, I hope some other XEP covers that. Another use case that I’ve ran into before (on Matrix this time) is that sometimes a Space moderator would like to include rooms from other servers. A real-life use case would be that several rooms already exist on different servers, and now they would like to organise into a common Space. This is what happened to us when we set up a Space on Matrix for several Slovenian FOSS groups, and some were hosted on different instances.a At a quick glance it seems your proposal implies the Rooms need to be on the same server as the Space. I wonder if that could be loosened up. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: hook@campfire.wheremymonkeyis.at matrix: @silverhook:matrix.org
participants (5)
-
Andrew Nenakhov -
Matija Šuklje -
Nicolas Cedilnik -
Schimon Jehudah -
Stephen Paul Weber