jdev - 2023-09-03

Anyone here hosts a mailserver? I need some help

this is not the place for mailserver, or indeed any server, support

sagaracharya: yes, move to xmpp:selfhost@chat.moparisthe.best?join

> this is not the place for mailserver, or indeed any server, support Shut up

No one is asking you

None of my messages are for you

this kind of behavior is not welcome here.

sagaracharya: please come into my MUC so i can ban you and add your jid to the RTBL.

xmpp:alltopic@hall.trung.fun?join

Trung: I'm not sure "being rude" counts for RTBL 😛 but someone should definitely ban them here

Nevermind I don't wish to help people like this, banned from my chat

Damn, this must be the biggest accomplishment of your lives

You all will live to tell this story!

I congratulate you all

:D

soulcaramel: https://xmpp.org/extensions/xep-0313.html#filter-time is how you would query just a given time window. but as singpolyma mentioned, this would have you missing people mentioning you in groupchats, etc. ✏

sagaracharya: our accomplishment can't possibly match your bid for the speedrun of getting banned from all MUCs 🏁

It certainly takes less effort to just be nice

Even less to just be silent

One feature I miss from the matrix universe are 'spaces': you join a space, e.g. 'Dino', which consists of several Channels, e.g 'Support English', 'Support German', 'Development', etc. grouped together so that all related channels are easily discovered. Is there something equivalent as an XEP? Something client devs would see as useful enough to implement in the future?

there are some ideas. but nothing has been written

there was an idea over at the xmpp platform development room to seperate moderation and sharing of groups of rooms seperately

because moderation is harder to do

and the groups of rooms could be entirely client side too

but nothing concrete yet. i agree it would be nice to actually standardize it

bear in mind also that the roster has a concept of "groups" aka tags. but nothing is being done with. and somebody said pep would be better for roster also 😛

there is also -> XEP-0144: Roster Item Exchange https://xmpp.org/extensions/xep-0144.html

but i dont think its meant to be used for this

is gajim's workspaces feature based on roster groups?

wgreenhouse: no

MSavoritias (fae,ve): thanks. > and the groups of rooms could be entirely client side too I had a server side solution in mind in this case. Grouping of MUCs could of course additionally be done in client side and in contrast to Gajim's current workspace solution, be synced across clients.

It's specifically to organise entity's which are not in the roster or not even on the same account

> One feature I miss from the matrix universe are 'spaces': you join a space, e.g. 'Dino', which consists of several Channels, e.g 'Support English', 'Support German', 'Development', etc. grouped together so that all related channels are easily discovered. > > Is there something equivalent as an XEP? Something client devs would see as useful enough to implement in the future? I have started working in this direction slightly. Cheogram Android now has a "related chats" button in the details view for any MUC ↺

meson what benefits would we get from server side sharing? assuming we seperate moderation

> I have started working in this direction slightly. Cheogram Android now has a "related chats" button in the details view for any MUC heh just noticed. how does it get the related chats list? name or host matching? ↺

MSavoritias (fae,ve): it queries the muc component to ask for a list

is that based on the MUC xep?

> meson what benefits would we get from server side sharing? assuming we seperate moderation Let me try explain again: You'd set up a space on the server, similar how you create a MUC, with a description and within this space you'd create MUCs. The client would then add a space, query the list of MUCs and join any MUC of choice from this list. In that way I meant server side. Hopefully this makes sense ✏

> Damn, this must be the biggest accomplishment of your lives > > You all will live to tell this story! > > I congratulate you all > > :D :)

wgreenhouse: Damn, I feel sad for the hurt you've caused. How will I live with this?!

> > meson what benefits would we get from server side sharing? assuming we seperate moderation > > Let me try explain again: You'd set up a space on the server, similar how you create a MUC, with a description and within this space you'd create MUCs. > > The client would then add a space, query the list of MUCs and join any MUC of choice from this list. > > In that way I meant server side. Hopefully this makes sense ah. hmm but the problem with this proposal is that it makes it server bound ↺

not all group chats may be on the same server

sagaracharya: live with it by proving me wrong

> not all group chats may be on the same server ~Do you have an example for that?~ ✏

> is that based on the MUC xep? MUC+service discovery yeah ↺

> not all group chats may be on the same server ~Do you have an example for that?~ Yeah in my mind all were on the same server. Hu. ✏

Now that subdomains and certificates for them are free I think it does make sense to just use that for related MUCs ✏

> > not all group chats may be on the same server > > ~Do you have an example for that?~ > Yeah in my mind all were on the same server. Hu. well it feels like an needless restriction. but could be different usecases? although we do have default group chats that you can drop people in. sniket does that ↺

> well it feels like an needless restriction. So something less encapsulated but more open: A space as a collection of MUCs (jids), whereby a MUC can be part of several spaces?

yeah. basically client side collections you can share with a uri. the idea was that a person has a group with groupchats they have created and then they decide to publish/share it. for that they put the list somewhere on the server (probably pep) and make it publicly visible. and then can share it as a xmpp link that anybody can subscribe to it and copy it on their client.

the subscribe could be optional

this doesnt solve the moderation part that discord adds but makes the spaces as in share groups easily implementable.

thats the idea at least

> this doesnt solve the moderation part Which exact moderation part?

the idea of spaces is basically two parts. The first one is that you can group related rooms and share them as one group. That eases discovery around common topics. like the xsf rooms. or the emacs and lisp room.

so that people can easily see where one community/crowd hangs out and how the topics are seperated.

the second part is that the group is moderated as one. for example if I want to add meson into all the xsf rooms as moderator i change their status in the xsf space to moderator and they are moderator in all xsf rooms. without needing to go each individual room. or if i want to ban somebody from all xsf rooms i just ban them from the space.

Discord does both. there is the argument that Discord doesnt have good threading which is the reason servers/spaces exist. which does have a point. it is ridiculous the amount of rooms some "servers" have

but i do think there is still value to spaces outside of that. albeit less extensive than discord. if xmpp embrases threads that is

thanks for explanation. sounds reasonable. ✏

MSavoritias (fae,ve): so for maximum compatibility maybe a client could just present a UI like it's 1 invite, 1 affiliation change etc, but actually send 1 invite per room and change the affiliation for each channel? Then only the inviting/moderating client would need support? Then maybe the only thing missing would be a xep to explain this and define a way to group rooms in pubsub ?

Why did I change language from room to channel in the same message... What's wrong with me... 🤣

Yeah pretty much. Good idea. And disco to see if the fallback need to be used.

So this is kind of like Twitter lists? Where a user publishes a group of addresses they think of as related but the members aren't necessarily aware of each other?

Maybe no negotiation or fallback at all, just send X invites, each with the group set, clients that understand groups will see they are a group, clients that don't will join them all individually

It can be yeah. Or it can be an "official" space too. And everybody subscribes to the xsf space for example

Client disco is... Well I hesitate to say broken, but it should be avoided because it's common today to have multiple clients, not all online at the same time, that support different things

Should be avoided where possible* maybe I should say

Client disco is useful for live stuff like "I am calling you right now" but less for messages that may go to mam etc

MSavoritias (fae,ve): if you want to write a xep for this or anything I'm willing to help, a bunch of others are too I think, I know it feels daunting at first but it's not bad

IMO the disco items format and protocol is already ideal for this, but of course that would require server support for this kind of unofficial bag vs pubsub we can just stuff in anything we want

Steps to writing a xep: find one remotely similar to what you plan to do, copy/paste it, change stuff, create GitHub PR (optional but recommended: ping editor and council in xsf or council), ask any question no matter how "stupid" in xsf

I mentioned in my FOSSY talk, the XSF is the nicest, most welcoming, and helpful org I've ever seen

> MSavoritias (fae,ve): if you want to write a xep for this or anything I'm willing to help, a bunch of others are too I think, I know it feels daunting at first but it's not bad Thank you ☺️ I do plan to write xeps at some point ↺