XSF Discussion - 2023-01-13

> pep.: > Wasn't that one of the proposed ways to do spaces edhelas: moxxy the android client also will havn spaces in the next release. https://codeberg.org/moxxy/moxxyv2/pulls/185

there is no spaces XEP, is there?

Isn't this just Client UI?

No. But the ecosystem seems to be moving regardless :)

so gajim has spaces?

cause it does that

it's not a protocol thing, it is just ui

It has... If that means grouping contact and mucs

Yes. Its just not a xep so it cant be shared across clients ✏

Plus some other stuff

my problem is just that that means this > Isn't this just Client UI? is a yes

(not a no)

unless you were replying to jonas’

hm, an avenue where threads would make for nice disambiguation

Yeah threads are needed

cheogram has just implemented them, i think it's a reasonably decent use of the xep, although (maybe a problem for jdev) maybe it would make sense to have each unthreaded message start a thread, and have the ui render single message threads as not significant, i.e. gray or similar, until someone replies. in that way it's like the "in reply to" thing common in all newfangled chat systems, but less intrusive, and naturally more useful than the current implementation

The only sane threading system i have seen is in briar or element. It says right under the message there are replies in that message with a number. And you tap on the message to open a seperate screen where it renders the thread. Anything else is too chaotic imo

zulip was nice, too

MSavoritias (fae,ve): that's how rocket chat does it and I find it extremely annoying

how is what i propose different, though? it's the same as the matrix implementation, but less intrusive

having to tap the message to see stuff is meh when you want to follow multiple threads

the thread icon indicates that there is a parent message, but it's not loud, and you might be able to figure it out at a glance

I like zulip the best for orgs. But that needs a whole different ui paradigm than just groups

"MSavoritias (fae,ve)1> Yes. Its just not a xep so it cant be shared across clients" < It can, people agreeing on things is not uncommo. Just that there's no document on XSF servers stating more or less how things should be done :P

Yeah i meant technical way 😅

pep.: which kind of sucks

I mean whatsapp is also just xmpp with a few things not documented on XSF servers

i think the transport protocol being different is a bit more than just "a few things"

but do you really want whatsapp interop?

qy, some people do, hence bridges

jonas’: It depends, eventually maybe it sucks, but see the last list thread about the jonas’ jonas’ standardisation process

Also the WhatsApp exemple doesn't compare I feel

the jonas’ jonas’ standardisation process?

The issue with them is the whole getting users in and ensuring they stay and make money off that

Haha, sorry

Mobile being slow and latency and..

pep., I don't see how the list thread I'm thinking of is any relevant there

Experimentation, getting things out there with no constraints, seeing how they work (looks like gajim is happy with it?) Maybe yeah they could start thinking about standardizing it, even though this one is "just"(?) UI work, so not for the XSF.

modernxmpp then possibly

Maybe. Even though.. spaces aren't the most consensual topic :/

I don't see that creating a XEP with no protocol in would be problematic, if the intention is interop.

modernxmpp can deal with controversy (#kanal)

'392 also has no protocol, still is valuable as a XEP

It's not like there could be 5 different documents like there could be under the XSF. In my mind modernxmpp was settling on some of the "controversies" by making choices

Kev, that's in 0001 iirc

Informational exists for a reason.

> , that's in 0001 iirc Yes, allowing this is encoded in 1, you're right.

:)

> &gt; pep.: > &gt; Wasn't that one of the proposed ways to do spaces > edhelas: moxxy the android client also will havn spaces in the next release. > > https://codeberg.org/moxxy/moxxyv2/pulls/185 Chat grouping is NOT Spaces ↺

Those are pure UI things, just like in Gajim

See, nobody even agrees what spaces are, let alone how to implement them :)

"That's your opinion, man" :P hence the 56 different suggestions for spaces

There is no XMPP involved at all there

So?

> pep.: > Experimentation, getting things out there with no constraints, seeing how they work (looks like gajim is happy with it?) Maybe yeah they could start thinking about standardizing it, even though this one is "just"(?) UI work, so not for the XSF. Not really. If spaces are to be dones right there needs to be a way to share them across clients with just a link or have people join them. And also a permissions work. So that a person can join all the chats under a space. Or moderators can be managed per space.

Plus if you destroy a space all chats should stop existing underneath

All this logic needs xmpp standardization behind it

Ok then, call it the way you like, but i'm there to talk about XMPP stuff accross clients and synchronization between them. Drag & drop MUC in folders can be nice but it has not impact whatsoever in XMPP, unless theres a XEP or some kind of job done on the network 🤷‍♂️

MSavoritias (fae,ve), do all groups part of a space need to exist on the same server?

To me yes

edhelas: I agree. I was just pointing out how clients implement the ui part because they see it useful.

> MattJ: > MSavoritias (fae,ve), do all groups part of a space need to exist on the same server? Personally no. But it makes things more complicated

Yeah somebody(tm) really needs to get onto it if they want that to be a thing, I guess. ✏

I envisioned spaces as a lot more loosely-coupled to the rooms. More a discovery feature than anything else. That doesn't really require them to be on the same server. But you're right, with the features you're talking about it sounds like they would almost need to be (not necessarily, but you need a lot of cooperation and trust between servers otherwise)

Yeah

Personally I'd rather not put a limit on the location of rooms. And I want to allow rooms to be in more than one space

Also i would "attach"a couple of xeps there for good experience

pep.: they should be allowed to be imo

If a room can be in multiple spaces, you can't delete either space without deleting the room?

Or the room should only be deleted when the last remaining space is deleted?

MSavoritias (fae,ve): Not in some people's definition of spaces, I know this was one of the disagreements

I think at some point we need to think about how practical some of these "requirements" are

Otherwise nothing will get implemented

> MattJ: > If a room can be in multiple spaces, you can't delete either space without deleting the room? > Or the room should only be deleted when the last remaining space is deleted? Second one

Yeah true. We need an actual definition and document.

MattJ: yeah I wouldn't delete rooms anyway if a space is deleted :p

See what wurstsalat linked again

I have thoughts about this, but can't type it right now.

We all have that feeling sometimes

I mean I'm in a meeting :)

:P

In matrix the discovery feature called spaces (where an organization can couple all their channels together; for example the dev channel and the user channel) and the personal organization feature called spaces seem to be pretty tightly coupled which is horrible. Because the organizations way of organizing things might not be my way of organizing things)

heh

i think wurstsalat had it right in the doc then, differentiating between server spaces and client workspaces

Or in other words if a join the project Foo dev channel through project Foo space and the projact bar dev channel through space bar I now have two work space plus the default one in element

Even though I'm just trying to be in two channels

I wouldn't call it server space because I'm happy for my server to manage personal spaces across multiple clients

But I don't want it to be hard linked to a discovery feature

Well, I guess it depends on what you want to use spaces for in general

I think there are three aspects: organization features in the UI (client), discovery (server), administration (server)

qy: please note that is't not my document (I just dug it out)

if it's just something like grouping your channels/contacts for you personally, that's basically something that roster/bookmarks can handle

> Well, I guess it depends on what you want to use spaces for in general Yes. I guess that's what I'm trying to say. But we shouldn't mix those things

Some of the features discussed conflict with features I would prefer

For long time, many XMPP clients displayed conversations/contacts in a tree-like structure. Now, many clients don't do that anymore and suddenly people want that back...

> i think wurstsalat had it right in the doc then, differentiating between server spaces and client workspaces That sounds a nice way of differencing the two things vocabulary wise :) ↺

larma; what determined the outline?

qy, nested roster groups

I guess the reason why we stopped doing it is that it's to complex for just private chat. Complex conversation organizing only makes sense when XMPP is used for larger communities or organizations, e.g. when there are multiple channels within the same community that are used for different topics inside that community (like xsf@, council@, editor@, ... in XMPP dev community)

You don't have "Friends" and "Friends offtopic" channels, so no need to group them

Or I guess even more importantly if you are in multiple organizations

Daniel, yes

But yes that's where the two uses cases 'slack' and 'whatsapp' collide. I don't want to explain the slack mobile UI to my mum

+1, personal and organization/team messaging demand different UIs for various things

You can do both with one UI, but it's a worse experience for both use cases when you do

I like the Discord approach as well

Discord has that thing with the "personal" space that looks more like whatsapp and then you have "servers" which are about multiple channels used by the same group of people. I can imagine the same to work for XMPP clients, where you normally only have that personal space which looks exactly like Conversations/Dino/many others look like right now, and only optionally you can add a "organization space" that works like Discord/Slack and has different UI to some degree (e.g. channel list is grouped, not ordered by last message and designed around having way more channels) ✏

The advantage of this approach is that we can properly upgrade existing users/infrastructure to it, because the personal space is exactly the status quo and we're just adding something on top

larma: I really like that idea

+1

I would like , as a user, to be able to group my chats in some way, such as an XSF/Isode split on rooms. That could be done with client-only logic with data stored in PIP. I would also like to be able to manage a set of rooms as a coherent whole - being able to assign hats (or whatever - roles) across a set of rooms, and having both ACLs and room autojoin based on those.

I think that, protocol-wise, it's not a lot of work to add some glue on top so that rooms remain rooms as they are, and we define a space on top. The server would need to tie them together behind the scenes ACL-wise, of course.

Kev + having an easy discoverability for clients, for example a simple capability feature in a MUC that says "hey, there's a space above me"

edhelas: then we're already limiting a muc to one space

I'm not sure you need to go up out of a MUC to find the space it's in, but rather the opposite, no?

You need to know what's in a space that you're in.

mhh 🤔

No, I always envisioned it similar to what edhelas is saying

You join a MUC, it advertises one or more spaces, which you can look up and discover other related MUCs

In the model I envisage, which is basically the Discord/Slack model, you join (UX) a space, rather than joining a room, and then that space acts essentially like its own little garden.

These two are not incompatible

But note that (unless you're saying otherwise) you will always be able to join a MUC directly, and there should be a way to discover a space from a MUC

It will also be the easiest way to go about it on the network

Share the "main" MUC of your space, and spaces-aware clients will be able to do the right thing, and legacy clients will work just as today

Think of the MMO Guild use case, for example. You tell people "Join our Space [here]", the user tells their client to join that space, and then they're in that space, which is distinct in the UI somehow. They're probably in a '#welcome' channel at that point. A space admin notices them and gives them the 'guildie' role/hat/whatever, which opens up a handful of other channels, to which they're automatically joined by having the room. Then they can also see some other optional channels they can select, etc. Then they get promoted to a raid group, get the 'raid' hat, and they're autojoined to all the raid channels, which they can now see. That sort of stuff.

> Share the "main" MUC of your space, and spaces-aware clients will be able to do the right thing, and legacy clients will work just as today Oh, so you pin a main-space-channel MUC as your entry point, rather than a distinct 'space' entry point? I think that likely works fine.

Yes, same thing, edhelas and I are just saying that what you actually share/join is the #welcome channel

and the rest comes from there

I think that could be done as different ux yeah

so from non-main mucs, you can't presume a space?

And both of tdem can coexist

The hardest question to answer, for XMPP, is how to ensure the autojoin, I think.

MattJ, but that somehow conflicts the idea of a room being in multiple spaces

or are we introducing a strict parent-child space relation

qy, I think any MUC part of the space is going to advertise it's part of that space

larma: yeah

> MattJ, but that somehow conflicts the idea of a room being in multiple spaces It doesn't, I think. Only for the 'main space channel' being in multiple spaces.

larma, why can't a MUC advertise multiple spaces?

MattJ, it can, but how can a MUC be the entry point to multiple spaces without the UX becoming terrible?

Join our community here, then from the list of linked spaces, use X

I don't think a MUC being in multiple spaces is compatible with full-management spaces.

I don't think the UX needs to be terrible. In fact, per what Daniel said earlier, it can be better than what happens in other systems

But you could easily have full-managed and linked MUCs.

Kev, that I might not disagree with, indeed

So a MUC can only be full-managed by one space, but can be linked from several spaces.

Agreed

In my mind spaces are less about management and more about easy discovery/grouping of related channels

They are both for me

I think there can be channels fully managed by multiple spaces

slack can do this

Once you add management it becomes a *lot* more complex

I'm sure there are use cases where that's true, but there are definitely (widely used in other systems) cases where full management is needed.

Unless they are situated on the same server

> Unless they are situated on the same server They have to be, I think.

Probably seperate xeps though due to complexity yeah

That's a shame

> That's a shame I don't think so. There's nothing stopping you linking across servers. But the data for 'your' managed space are on one server.

Would mix make management easier?

> Would mix make management easier? Yes, but not groundbreakingly so.

I just added Spaces to possible Summit topics

Oh no :)

So if you want a space that's something like "Cool rooms talking about cat gifs", you can make one, and it can 'link' MUCs from across the xmppiverse.

I mean, thanks :)

If you want a space that's "My Warcraft Guild" where you manage roles of your members, etc., you host it on a particular server (but can still link out to popular cat GIF channels elsewhere).

> Kev: > Yes, but not groundbreakingly so. Thought so

Kev: how do linked mucs know they are linked to? muc components maintaining such info seems like it could go wrong

Random semi-related thought: I wish the designers of disco#items had included a "rel" attribute

I'm not pretending that other people's use cases aren't valid, or important, or whatever. Just that the case I'm describing is very widely deployed on other systems, and it would be good to be able to address that in XMPP.

> : how do linked mucs know they are linked to? muc components maintaining such info seems like it could go wrong They don't need to.

> qy, I think any MUC part of the space is going to advertise it's part of that space ?

do we then mean that only the "full-managed" space is advertised? worth noting...

that also then kinda removes the multiple space issue

if mucs only advertise one, no problem

This is one of those annoying instances where I think it's worth actually gathering different scenarios to work out what we can/can't/want to/don't/etc. address.

I've got a pretty clear picture of what addressing the Company, Guild, Twitch community requirements can look like, but other people have other things in mind and it'd be good to capture them.

Wouldn't it be reasonable to do XEP-spaces incrementally? What gajim does right now seems rather straighforward (?) to implement with some JID/workspace name mapping server-side (if a workspace is just defined by a simple string, it also works if you use multiple accounts, which is nice IMHO). Obviously that does not cover all the use cases and expectations, but better start somewhere than nowhere, maybe? Where is this someone™? Aren't they writing that already? ✏

nicoco: per user in PEP?

PEP requires no server involvement, a serverside mapping sounds more like the "server spaces" option, which is not what gajim has implemented

I was thinking per user in PEP, yes (so, not "server spaces"). I'm talking from a (egocentric) user perspective: I think gajim's workspaces are great and would love to not need to reorganize my chats in workspaces when I switch to a new computer.

Have put my name on the summit page, BTW.

On the "client grouping shared in server" side of things, cheogram Android we have implemented using bookmarks2 <extensions> feature to put roster <group/> elements inside the bookmarks. That's how we do it right now

Does not sound stupid to me.

. ✏

. (edited)

. ✏

. ✏

what would be a good way to get hold of an outbound stanza-id? put it into the stream managment ack? or would that be too weird syntactically? from a client side development perspective this would be the ideal place. but i don’t know if ack and assigning stanza-id are very different layers on the server side

Didn't we plan to squeeze that into Carbons?

Yeah are, a bit (in Prosody). But not impossible. Acks would always need to be delayed until archiving succeeds... which might not be terrible in any case.

plan maybe. but the overhead of carbons compared to the overhead of ack...

I think the two options are acks or carbons, indeed

and the magical one based on a counter and stream id

Maybe we should make a final decision at the summit

for me putting that into ack would be weird, and would not make sense if another message would already be sent..

but the magical one would mess with my storage-engine decided ids :(

Indeed

acks aren't always one to one with messages either

Putting it into the 198 acks is a terrible layering violation - and while I'm in favour of pragmatic breaking of layers, in this case it would pose serious issues to (at least some) servers that layer transports differently from stanza logic.

(I obviously mean it would be an inconvenience in M-Link ;) )

Yep, I can totally see that. That design isn't traditionally uncommon, nor do I think it should be discouraged.

I've been leaning towards carbons most recently

Carbons and MAM are already closely related (Carbons is the MAM subscription that never was)

We "just" have to include the sender in the notifications

We can also invent something entirely new

carbons may be overkill and may cause issues with MUC PMs (I think)

Carbons are already pretty large due to all the wrappers

carbons are very verbose. and I'm not sure how existing clients react if they suddently receive copys of their outbound messages

that would probably require a namespace bump if we start doing that

We'd probably have to do it as opt-in

We should probably get around to dropping carbons and just routing the core stanzas. But using carbons/reflection is at least consistent with how you get your IDs from a MUC MAM.

No namespace bump, just some element or something when enabling carbons?

> No namespace bump, just some element or something when enabling carbons? ^this

that would work too

Or a namespace bump of the enable, which is roughly equivalent.

Kev, OG carbons with <messages> and to/from in the opposite direction?

But explicit/implicit/etc.

or just <im-ng/> in your bind2 request :)

mhhh brb reading that xep again

> or just <im-ng/> in your bind2 request :) Yes, that's what I mean by "We should probably get around to dropping carbons and just routing the core stanzas"

I think that we should do just that

now that bind 2 is a thing we could actually start looking into im-ng again

If we could sort out IM-NG without boiling the ocean (which is kinda hard to do), the world would be a better place.

is this a blockchain joke?

https://en.wiktionary.org/wiki/boil_the_ocean

I mean that I (at least) keep wanting to fix all the problems related to routing in one go, and that's an impossible task.

In principle, we could make some very sensible and achievable changes to routing to start with.

Like making carbons go away, for example.

I would just send out to other resource (im-ng enagled) every message that goes to MAM

> Like making carbons go away, for example. where to o_O

Status Final

The great spec graveyard

https://xmpp.org/extensions/xep-0409.html

I think I wrote that on the Eurostar after the 2018 summit or somesuch.

everyone go read up on the earlier discussions about this xep on the list and then we have a solid base for a disussion at the summit

but in general it seems like we might have enough to start some implementations

especially now that the SASL2 stack has landed