Modern XMPP project discussion - 2024-10-10

nandi: IME, even if the implementation-side of threads could be made flawless, which I doubt it can, because of competing tradeoffs in the different approaches, the practicality is often defeated by the significant fraction of users who can't be bothered with them, and you end up with more noise of a new kind

i like the way discord does it where i often use them to offload a conversation that would otherwise take up space in main room

on xmpp all the clients leave them in the main which kills my usecase 🤷‍♂️

matrix does it similarly but their ux for it is way less good

> nandi: IME, even if the implementation-side of threads could be made flawless, which I doubt it can, because of competing tradeoffs in the different approaches, the practicality is often defeated by the significant fraction of users who can't be bothered with them, and you end up with more noise of a new kind rom1dep: The Cheogram/Monocles Chat implementation is pretty low on the user effort required. And once threads are implemented in desktop and web clients too, and once admins can correct what thread a message is in for others, it will get even better. ↺

fugata: if you count on admins to "fix" users threads, you lose. And no matter how high or low the bar is to use them, if all the convenience brought by them falls apart the instant someone misposts, the incentive to use them will be low

rom1dep: I don't know, I'm an admin in a lot of rooms and I wouldn't mind moving mistagged messages to the right threads. You know that forum admins have the same powers, right? And one can always appoint more admins. But the main thing is to have more clients support it. ✏

Some remarks: - forums are closer to email than to IM - it's not always black or white whether a message belongs to one thread or another - with the current message reply implementation seen in several clients that doesn't let one cited message be edited/split , or multiple cited messages be combined in one message, it doesn't help maintaining purpose-specific threads - clients have yet to agree on a common implementation and UX for threads and there's no consensus in sight

i feel like "follow discord" is the boat most people would jump in even though they're proprietary and whatnot ✏

nandi: not really. This discussion pops up every other week, and the case of discord threads was discussed previously. Some people like it, some do not, and some people prefer the old discord threads over the new way (whatever that means)

this is why we can't have nice things. i still say that just following discord will get the most people, there's always gonna be dissenters

One also has to keep in mind that discord tends to attract a specific demographic and use-cases (e.g. large screens/desktops/homogenous communities spread over topic-specific rooms/...), and it's not clear to me how well that overlaps with the typical XMPP user needs

why would clients need to follow one model? every client is for a difference audience so that doesnt make any sense

also it doesnt even make sense for all clients to adopt threads

and yes people sometimes wont use the "correct" thread. that doesnt mean we burn everything down and we implement nothing. i mean people sometimes reply to the wrong thing but yet replies are nice

ive never seen threads used to manage content, interesting idea

zulip kinda has that

those guys are like "what if everything was a thread, yolo" ✏

> and yes people sometimes wont use the "correct" thread. that doesnt mean we burn everything down and we implement nothing. > i mean people sometimes reply to the wrong thing but yet replies are nice That makes it very easy to miss replies. That happens every single day in slack and element (again, from experience)

> zulip kinda has that zulip's model isn't the worst, tbf, but it puts a lot of overhead on the users and that's a complexity hard to bear for some

> why would clients need to follow one model? every client is for a difference audience so that doesnt make any sense reminds me of when element first implemented threads as a beta feature and it just showed up as a normal reply to people who didn't have it ticked

One thing about thread markers is that I'm not sure whether they allow nesting threads (aka the "Google Wave" model), not sure there's even a consensus on "let's not do that ever again"

> One also has to keep in mind that discord tends to attract a specific demographic and use-cases (e.g. large screens/desktops/homogenous communities spread over topic-specific rooms/...), and it's not clear to me how well that overlaps with the typical XMPP user needs speaking of which, would it be possible to implement "spaces" in xmpp?

Depending on how you look at it, it's already there

??

You can group things by domain name e.g. welcome@communityXYZ.server.tld ; admins@communityXYZ.server.tld ; support@communityXYZ.server.tld and have a pubsub node at communityXYZ.server.tld letting you discover those and related roooms

Cheogram and perhaps Monocles support parts of that IIRC

> > One also has to keep in mind that discord tends to attract a specific demographic and use-cases (e.g. large screens/desktops/homogenous communities spread over topic-specific rooms/...), and it's not clear to me how well that overlaps with the typical XMPP user needs > speaking of which, would it be possible to implement "spaces" in xmpp? there has been discussions but nothing written and implented sadly ↺

ah, the biggest usecase for "servers" or "spaces" for me is the discovery aspect, although it feels too fractured sometimes when they have like 100 channels

servers are horribly accessible for spaces anyway. and its not what people mean spaces

at least when they ask the discord kind of spaces

i like the element style ones more because they don't even show up if you're not joined and on the "spaces page"

on discord one of my biggest points of confusion when I join a server is which channel to talk in heh

the biggest plus of spaces is the shared moderation and the inheritance each room can have. in the sense that people can be made members automatically of the rooms part the space

second one already exists as a xep but its compatible with MIX probably not MUC

what is mix?

is it like a newer muc?

yeah

i was speaking of https://xmpp.org/extensions/xep-0253.html

TIL xmpp has forms

Unofficial tagline: "There's a XEP for that"

do any clients actually support forms?

its ironic to me that xmppp is so extensible but the clients are so feature poor. like the most "advanced" clients like movim are cool because you have a webpage....

Depends on what you mean. Or, where. It's used extensively for configuring e.g. chat rooms.

interesting

so I probably used it just didn't know

the best kinda tech

Most likely, yes.

Direct usage is rare however.

> its ironic to me that xmppp is so extensible but the clients are so feature poor. Use feature-rich clients, then 🙂 Gajim (and IIRC Psi) gives pretty raw access to ad-hoc commands and forms via "Discover Services"

I guess part of it is I haven't learned the magic spells to do the things yet

I'm still learning what direct command even means

is that like sending a raw stanza?

https://share.conversations.im/nandi/YpdURDuJd85MnwVz/Screenshot_from_2024-10-10_01-30-38.png

stuff like this is confusing

agreed. i have no idea how to navigate that ui and i am writing xeps and read the xmpp rfcs myself

but also i would say that it would be hard to find an xmpp client that has a good ui outside of chat. except movim that is

and libervia

those are my favorite. pretty much the reason why I give xmpp the time of day

"chat" is just an addon feature for me

yep. i agree that a client that is native xmpp would be nice. right now xmpp clients are mostly trying to copy things here and there. but i am going off topic probably ✏

im tempted to make an app in tauri that loads web apps based on xmpp queries

> those are my favorite. pretty much the reason why I give xmpp the time of day > "chat" is just an addon feature for me What's your use-case for XMPP again? I like it as a high-volume and low-volume chat ecosystem, I tried to replace my heavy reliance on RSS with it without success because it just doesn't have good "news-like" clients in my opinion, I tried the social/microblogging stuff but gave-up because I already have RSS anyway.

xmpp could be much better for social/microblogging than rss. as movim already shows. specifically: comments, reactions, attachments, multimedia to name a few the problem of course would be that there are no network effects for xmpp to be preferred but its not like that has stopped us before :P

Oh, just the other day I was just thinking about how crappy chat is in general as a medium for announcements. RSS is ideal, but most of my audience doesn't know what it is. That leaves me with email, which is a pretty congested space (or so I imagine).

e.g. we have an OSM XMPP channel and I invite people there (onboarding them to XMPP) for receiving mapping party announcements...but none of them keeps up with the chat, and they usually miss announcements in the channel. (So I usually end up DMing or calling them over XMPP.) ✏

e.g. we have an OSM XMPP channel and I invite people there (onboarding them to XMPP) for receiving mapping party announcements...but none of them keeps up with the chat, and they usually miss announcements in the channel. (So I usually end up DMing or calling them over XMPP...or worse, their app is removed from RAM and stops receiving notifications, so I have to call them over phone...) ✏

yeah very much agreed. one solution is to have a moderated room that low-noice and one that is all the convos

but that doesnt work either. i tried it

"Spaces" would be a good option here. There could be an "announcements" channel in the space for just announcements (and only specific users who make announcements would have voice there), and a "chat" channel for general chatter.

what ends up happening is nobody joins the convo room or the low noice room. and discussions dont happen anymore as much

yep

with spaces you can have notifications about the whole space and easy to find all the rooms. plus you can have automatic membership management where people join rooms or not belonging to a space through inheritance

instead of managing each room

> what ends up happening is nobody joins the convo room or the low noice room. and discussions dont happen anymore as much MSavoritias (fae,ve): I don't understand - why not? ✏ ↺

some of the stuff i heard are: - its a different room so i have to switch context and make sure everybody joined there - i have to find the room in the list of chats - not everybody is joined

among others

copy paste the message also to the new room and then wait for the other person to join, if they join

> RSS is ideal, but most of my audience doesn't know what it is. ...and this audience is mostly software developers - participants in FOSS events 😅

those complaints are not solved only with spaces of course. but its part of it i think

Well, while the workaround is no replacement for spaces...but I think I could make it work. Most of the people I onboard are only using XMPP for OSM event announcements. So their chat list isn't very big - they don't have other contacts and aren't in >3 channels. Alternatively, I could start pinging people for each announcement... ...all until we get spaces, that is. ✏

yeah i mean i dont mean to discourage you ^^ having two rooms makes sense for now

its what we do for the news rooms too

until year of the ~Linux Desktop~ spaces

> xmpp could be much better for social/microblogging than rss. as movim already shows. specifically: comments, reactions, attachments, multimedia to name a few > the problem of course would be that there are no network effects for xmpp to be preferred but its not like that has stopped us before :P Technically, I'm convinced XMPP is the superior carrier for RSS content (just because of the push/pubsub model vs interval polling of RSS/Atom), but I don't care about comments/reactions, etc. My RSS client looks like a very dense mailbox with categories and filters, with which I skim through thousands of posts every day (and that's why microblogging à la twitter/movim never did it for me: it's just not that efficient and well structured). So I'm fine with XMPP taking over in this space, I just don't see the practicality of it: neither the content sources nor the clients to consume them exist yet ↺

> e.g. we have an OSM XMPP channel and I invite people there (onboarding them to XMPP) for receiving mapping party announcements...but none of them keeps up with the chat, and they usually miss announcements in the channel. (So I usually end up DMing or calling them over XMPP...or worse, their app is removed from RAM and stops receiving notifications, so I have to call them over phone...) +1 on the announcements-only room (on top of the discussions-only one) It's likely that introducing "Space" as a concept to such users would confuse them, too. ↺

> > RSS is ideal, but most of my audience doesn't know what it is. > ...and this audience is mostly software developers - participants in FOSS events 😅 There used to be a time when most people were using RSS without thinking about it, just because it was there, in the middle of their web browser, doing its thing and serving a useful purpose. In my (controversial?) opinion, it only disappeared because we let the tech giants build their walled gardens over it (and a bunch of other things, including XMPP) ↺

> yeah i mean i dont mean to discourage you ^^ having two rooms makes sense for now It could also probably help to have sticky messages/sticky media(/sticky threads/…) so that some room content can be made to stick on top ↺

true

has anyone ever had their muc messages be denied on every muc but every other feature works?

My conversations.im account is doing that and I can't debug it