rom1depdo you guys know if there's anything in the pipes for XMPP that'd be akin to matrix spaces/discord servers (as in, a way to join and then discover a collection of related MUCs)?
Anton L. Šijanechas left
rom1depit is an absolute UX nightmare on matrix, IMO (and quite broken at the moment). If that's something being considered for XMPP, I'd be interested to see how it compares (I do think it's a worthy feature to have, especially when more and more communities organize themselves around multiple rooms)
ZashYes, no, maybe. We've had conference servers per project since forever, which could be described as spaces, if you squint at it. There was some sort of working group started but I haven't followed it for some time.
thomaslewisCould Gajim’s workspaces be extended and standardized into something like spaces/servers?
thomaslewisPubSub could be used for setting up the groups server-side…
lovetoxis this something people on matrix use much and like?
lovetoxpersonally i never had the need
ZashIt's of course the most critical feature, without which XMPP can never succeed.
lovetoxthe problem here would probably be, how hosts the space list, and how do you discover it✎
lovetoxthe problem here would probably be, who hosts the space list, and how do you discover it ✏
ZashHaving seen this discussion repeat, I would suggest someone write some stuff down in a ProtoXEP, or at the very least a problem statement of some sort.
ZashOr even better, write some code
lovetoxthis would be a huge xep
lovetoxdiscover spaces, invite, join, create a space, delete a space, roles within the spaces ..
lovetoxit is like a meta-muc
lovetoxand what is the gain of all that complexity? you have to send one invite instead of 4
ZashI'm pretty sure whatever it is you have in mind, it's not the same as what thomaslewis has in mind.
lovetoxor we could make it more p2p
ZashHence, problem statement. As in, agree on what the problem is.
lovetoxa user creates local in its client a space and puts 4 mucs in it, and just sends that information to another client
ZashSince I am a server developer, I will leave you to it.
lovetoxor we make the one and only global xmpp pubsub server
lovetoxwhere we can publish this information 🤤
lovetoxor we create a pubsub sync protocol s2s
lovetoxafter all these great ideas, iam tired now and im going to bed
rom1depBy the time I moved to mine there were two dozen replies :)
Zashand now back to ignoring all this for another couple of years
rom1depIt could be a pubsub node that contains a list of MUC URIs, wouldn't that make it sensible and good enough from a permissions point of view?
rom1dep(I don't think P2P is warranted, I don't think it's important that spaces are centrally discoverable, just like MUC aren't)
pulkomandyI would consider imhlementing it the other way around: tag each mesage sent to a muc with a "subroom" name. Then you have a single muc to join/leave/manage, which is probably simpler
rom1depThat would probably mess up every client out there without helping in any way with the problems of who gets to define/delete/manage those tags (which, to some extent, would need to be known to the MUC server for obvious syncability, which means messing with MUC and MAM), not sure it's simpler