jdev - 2022-07-11

I was thinking something like rom1dep described. It seemed the simplest way to implement MUC grouping server-side.

What y’all described so far is mostly a way for users to group some tabs together.

What I’ve read people request was a way for communities to have many different rooms, every participant in every one of them (except those they’re not allowed in, e.g. a staff room), with very fine permissions management (for instance you’re only allowed to speak in one of these rooms until you’ve agreed on a CoC), and with roles or affiliations shared between them all.

I don’t think we have the building blocks required for the latter, in a non-hacky way.

Yes, that's why we need a "problem statement" first as Zash said, and not jump directly into making up solutions that only cover 1% of the thing, and not the part people actually want/need.

To me I'd see this "space" thing as a MUC service on steroïds

Link Mauve: do you see something missing in MUC regarding permissions? What I see missing is something above that to cascade/sync perms between all the MUCs in the collection/space (so, just some basic automation)

rom1dep +1 👍

We had a discussion with Link Mauve and pep. last winter and we came to a similar conclusion afaik

And even that seem secondary, tbh. I wouldn't mind "unmanaged" spaces that are a shared aggregation of diverse preexisting MUCs with their own preexisting permissions

That's especially relevant when "stitching" rooms across bridges and services, where users and permissions aren't universal

(e.g. we could have a space about programming that aggregates rooms from XMPP, Libera, etc)

Meh :/

I'd prefer to have a tree where the only space is the MUC service than a graph where you can have access to the same MUC by many different path, it adds lots of confusions

I don't think it's always desirable. nor is always possible

not allowing to cross reference diverse MUCs from diverse services would be very limiting in the kind of communities you could create (that would exclude bridged rooms, that would exclude collecting rooms across diverse MUC servers, and that would insulate existing topical MUCs until a bigger server takes over and supersedes them). The only upside I see is some convenience for administrating large collections of MUCs, but this kind of convenience could already be implemented today as a server-admin feature that has nothing to do with "spaces" (like, "let me bulk edit permissions for rooms X/Y/Z in one go")

also, the confusion of having multiple ways to reach one MUC could be handled nicely client-side: "you just joined the community/space XYZ, It offers an easy access to several rooms, but some are already known to you. What do you want to do: - room X: [ ] forget bookmark [ ] keep bookmark (the room will appear in two places) - room Y: [ ] forget bookmark [ ] keep bookmark (the room will appear in two places) - or do it for all rooms: [ ] forget bookmarks [ ] keep bookmarks

xmpp:spaces@joinjabber.org?join has been started some time ago, there may be some document linked there, if anybody wants to take over, I think it's pretty much inactive though atm

And yeah the issue is to agree on the problem space

Nobody wants the same thing

Hello I amtrying use Xmpp in react native app I need to get started how please help out ?

Hello.

Why ?

> I'd prefer to have a tree where the only space is the MUC service than a graph where you can have access to the same MUC by many different path, it adds lots of confusions I agree it should be a tree. Otherwise you're not building a community, you are building an aggregator, or, if you have a community, you are possibly taking over/invading other channels that maybe didn't want to. A community works only if it has good and agreed upon moderation policies (what's allowed, where to put offtopic stuff, etc). And making this work on a single chat server is already going to be quite complicated, I don't see the point of attempting to do it with multiple servers

Big +1

Also way easier to handle in clients, if the namespace is detected you directly know that the whole service behave in a specific way

No need to discover things across multiple domains

If I did it, I'd add some option to MUC room configuration to list related and/or 'parent' (in the tree sense) rooms, and probably advertise those in some disco#items query.

> No need to discover things across multiple domains Slack once thought the same but were corrected by demand from paying customers. Now you can have channels that exist in multiple workspaces.

Probably some membership check for the parent room

well it depends on the usecase, I was thinking more of the "community" thing and Discord, but in Slack "workspace" use case it makes more sense to have something distributed (for example if you have multiple companies working on a project). But that's a completely different use case and I'm not sure if it's possible to put them both into the same spec

(and certainly not in the same user interface)

discoverability would be nice, to be fair... but i don't think i would want this feature otherwise

> I agree it should be a tree. Otherwise you're not building a community, you are building an aggregator, or, if you have a community, you are possibly taking over/invading other channels that maybe didn't want to. Call it an aggregator if you like, agregating pre-existing rooms under the same discoverable umbrella is a real and meaningful use case > A community works only if it has good and agreed upon moderation policies (what's allowed, where to put offtopic stuff, etc). And making this work on a single chat server is already going to be quite complicated, I don't see the point of attempting to do it with multiple servers I don't think it matters all that much. I have counter examples of that from Matrix (some programming communities with rooms aggregated between matrix, discord, gitter and IRC, and one hobbyists DIY space) > No need to discover things across multiple domains I don't think the disco is a challenge, a space can be a node that refers multiple MUCs, end of the story

Maybe we've found yet another feature that completely changes the way your app is going to behave / look and that's one of the features that are never going to appear as nobody will agree on a compromise -- that would please no one anyway, or so little that it's not useful?

Or multiple versions will appear and then some are going to complain about interoperability even more while not wanting to see the various use-cases

I don't have as much hindsight, but I don't see the compat and client side things to be a problem

Unless you make it into a weird and constraining hierarchy thing, at the end of the day it's just joined MUCs so old clients wouldn't see a difference

But are we talking about old clients here

Yeah, that's what I'm saying. From an old client's perspective it's be just good old bookmarks

also I'd rather say non-implementing clients

Not everybody not wanting spaces is old-fashioned ✏

Yep, and that's fine, isn't it?

Sure, that's why I prefer to use non-implementing rather than old

Client side implementation of spaces would be be little more than subscribing to lists of nodes and offer a UI listing them with a "join" button. Not all clients have to support creation either.

Are public URIs for pubsub nodes a thing?

I don't think there's a notion of public/private for URIs. It's just whether you can subscribe or not to the node itself.

K