23 Feb
2025
23 Feb
'25
9:23 a.m.
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
23 Feb
23 Feb
9:58 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2:20 p.m.
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
10:12 a.m.
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.
2:13 p.m.
Thank you singpolyma for a very prompt feedback.
In https://xmpp.org/extensions/xep-0045.html#disco-roomitems
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. 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
2:30 p.m.
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?
24 Feb
24 Feb
1:31 a.m.
Replying here to an email that was sent to me instead of the list.
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(a)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
4:24 a.m.
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
7:40 a.m.
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
10:25 a.m.
Nicolas, I thank you very much for your respond.
~ Schimon
On Mon, 24 Feb 2025 15:40:03 +0100
Nicolas Cedilnik <nicoco(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7
days inactive
8
days old
9 comments
4 participants
participants (4)
-
Andrew Nenakhov -
Nicolas Cedilnik -
Schimon Jehudah -
Stephen Paul Weber