jdev - 2021-06-12

homebeachm, Diego, you could make a wildcard dns record e.g. *.communities.myserver.tld pointing to communities.myserver.tld and configure your server (i.e. write your own module – I never heard of any servers that can do this) to handle each muc host in that namespace as a separate entity. I believe that doesn't require any new XEPs.

However, that's just the tip of an iceberg. This is not a complete solution to get communities / spaces (Matrix/Element uses this term) / guilds (an old Discord term, still used in their developer docs) / "servers" (screw Discord for using that term for end users) working as desired, since how do you

a) handle who can and cannot join the particular space? Even if you manage to make use of something like ejabberd ACLs, there is no way to configure that on client side. You could use something "really simple", like a bot, for handling that, but see my point below.

b) make user-friendly invitations to non-public spaces? For public ones it is easier since you can simply use an xmpp uri pointing to any room, just like with any regular MUC. This would also work with XEP-0249 invitations. For private spaces, this would not work with current XEPs, unless you use another "really simple" solution like setting your module to have an auto-generated special password-protected room (like welcome@1312.spaces.myserver.tld) that you can invite people to, and if they join with a correct password (supplied in XEP-0249 invitation or in XMPP URI, e.g. xmpp:welcome@1312.spaces.myserver.tld?join;password=tmppwd25519 ), the server would allow them to discover and join all other rooms in that space.

c) etc. These are just two most obvious points that I got off the top of my head.

The "really simple" solutons I mentioned may be simple, but they are not conforming to any standard and would lead to server-specific implementations. At least having a "best practice" XEP would solve most, if not all, possible discrepancies.

Even if you manage to stick to the currently avaliable XEPs and not invent any new ones, there still would be obvious UX issues. It would be usable, yes, but the UX would be, well, not utterly terrible, but much, much worse than what Element or Discord can offer. For instance: d) If a user joins a channel, they would simply not know that the channel is a part of a bigger space they can join and that there are other channels around. I don't see any solution for this other than a XEP that would state how can a server indicate that info and how the client is supposed to use it. e) There would be no ways to make temporary invitations, unless your server can handle that on its own as described in b). But, again, server-specific stuff is undesirable. f) etc.

rom1dep, that new feature of Gajim is very interesting indeed – they went with a time-tested solution similar to ones used in Slack, Discord, Element, Wire, etc. – but AFAIK, it's purely local and client-only. That said, if XMPP will have communities some day, they would fit nicely into it, just like in other IMs I mentioned.

» d) If a user joins a channel, they would simply not know that the channel is a part of a bigger space they can join and that there are other channels around. I don't see any solution for this other than a XEP that would state how can a server indicate that info and how the client is supposed to use it. selurvedu: some sort of tie-in to service discovery?

can you make the channel be "invitation only" (does that exist in XMPP?) and then have some other thing ("the group" / "the community") send invitations to join it?

pulkomandy: yes, kinda

In XMPP it's less about "was this person invited" and more "is this person on thr member list"

And servers will automatically add people to the members list when you invite them, if the room is configured that way

And if you use "mediated invites" (where you ask the room to send the invite)

So that's how you achieve what you want.... whatever it is. Just have something to manage the member list, which could be a bot or something built into the server.

Diego, yeah, you can already use the service discovery manually, so a client will just need to do that automatically and display it somehow

selurvedu: perfect, so in theory we don't even need anything clientside for it to function

side note though

it does seem kind of unnecessary

this whole 'communities' thing

because I mean

Diego, this is disputable and a matter of taste

just look at the XSF itself

it just uses some website to list the chatrooms ✏

Well, yeah

selurvedu: and what about the management of these communities? with adhoc commands ran on e.g. communities.server.org?

Diego, if a goal is to have a guilds / spaces clone, we do need some convention about how the conforming clients have to perform discovery and indicate the availability of such spaces

yeah

so just a best practices XEP i guess

same with the management via ad-hoc

yep

Yeah, I mentioned that in my long post :)

yep you did

it's probably the best way to do it like that

so then there's graceful degradation

if clients already support disco

but hey that is obvious

thanks though selurvedu

i'm not so sure whether to try to implement this or not

I'll see