| 20 Feb 2024 |
 @joepie91:pixie.town | In reply to @adam:robins.wtf
would it be helpful to have a bot that sends a welcome message the first time they join the space/channel ? in principle, but that's going to be spammy in the room, and likely perceived as unwanted if done as a DM | 17:18:46 |
| @joepie91:pixie.town | (spammy in the room at our volume, that is - I think it'd work if the place were smaller) | 17:19:11 |
 adamcstephens | i meant as a DM. and people can elect to ignore the message in the DM | 17:19:21 |
 @piegames:matrix.org | I strongly dislike bot DMs | 17:19:57 |
| @joepie91:pixie.town | I'm not confident that the people who ask a question before reading the topic, would open and read a DM before asking a question :) | 17:20:26 |
| adamcstephens | well we're working with the technology we have. they joined our community so why should we be afraid to send them a message. | 17:20:30 |
| @joepie91:pixie.town | without wanting to go into a long discussion about the details of the 'why', people are going to take offense to that | 17:21:19 |
| @joepie91:pixie.town | and more generally, "making people read something first" as a moderation approach has a poor track record, so I don't think that that should be our focus for addressing this issue | 17:22:10 |
| * @joepie91:pixie.town mumbles something about nobody reading manuals | 17:22:26 |
| @joepie91:pixie.town | like, I agree that people should more carefully look at the community they're joining before engaging, but I also know that the likelihood of this actually happening reliably is close to zero, and so we'll need something other than that | 17:23:37 |
| adamcstephens | that's why i suggested we try and push something to them. but that's a non-starter. | 17:24:04 |
| adamcstephens left the room. | 17:24:11 |
| @joepie91:pixie.town | right, but that is still expecting them to read something, which is not likely to happen | 17:24:34 |
| @joepie91:pixie.town | welp | 17:24:36 |
|  tomberek joined the room. | 18:23:49 |
| 21 Feb 2024 |
 @fractivore:cyberia.club | I just keep thinking, one or more humans probably need to actually go debug one or more matrix client's implementation of threads and/or implement threads in clients that don't have them. Easier said than done, I know... | 06:39:45 |
| @fractivore:cyberia.club | Between:
- Threads work perfectly on element but are very spotty everywhere else and possibly not implemented at all
and
- Threads have some support on most clients - the set of clients that accounts for 99% of users or so. These clients support threads in some capacity, but it might be a fallback like using nested replies, or it might be janky and buggy.
...
Which would be the better outcome? Would either of these conditions be sufficient for us to start using threads, or are we looking for a better state than either of those? (i.e. 3. Threads have out-of-beta support on the 99% set of clients)
| 18:09:11 |
| @joepie91:pixie.town | the issues with threads are not just implementation issues, there are also protocol-level problems and a lot of history behind them | 18:15:53 |
| @joepie91:pixie.town | one of those problems being their inflexibility on weaving in and out of threads | 18:16:21 |
| @joepie91:pixie.town | the extremely summarized version is that they ended up implementing Slack-style threads instead of some other model for what seems like business-related reasons, and so we ended up with a thread model that just fundamentally doesn't work well (or at all) for a lot of people, and that is exhausting to interact with even if the implementations worked perfectly | 18:17:49 |
| @fractivore:cyberia.club | Okay... but surely the general concept of threads is something people want in general, right? What would we need to get there? Is it just hopeless due to the state that matrix has ended up in ("governance issues" or whatever), and we'll just have to wait for the next generation federated instant messenger? | 18:30:54 |
 K900 | Honestly I don't think threads are fundamentally broken, you could build a Zulip-style UI on top of Matrix threads | 18:32:00 |
| K900 | Just no one has done it yet | 18:32:03 |
| K900 | But Slack style "spin off entire conversation" threads are definitely what the "intended UX" is | 18:32:18 |
| K900 | So most clients implement that, the stupid fallback or nothing at all | 18:32:28 |
| @joepie91:pixie.town | I would say that there is a general desire for threads that work better, yes - concretely, getting there would require spec work and implementations outside of the upstream governance process, because that is kind of stuck at the moment. I don't think that is hopeless - but it does mean that this is not really a short-term solution and that "just use threads as they are now" isn't really one either | 18:32:56 |
| @joepie91:pixie.town | In reply to @k900:0upti.me
Honestly I don't think threads are fundamentally broken, you could build a Zulip-style UI on top of Matrix threads from what I understand, some people have looked at this and came to the conclusion that it is not viable without some protocol-level changes | 18:33:16 |
| @joepie91:pixie.town | but getting anything through the spec process right now is a challenge | 18:33:53 |
 raitobezarius | In reply to @k900:0upti.me
Just no one has done it yet I'd do it if I would not foresee that doing it anywhere relevant would cause everyone else to have a utterly bad experience | 18:34:28 |
| raitobezarius | In reply to @joepie91:pixie.town
from what I understand, some people have looked at this and came to the conclusion that it is not viable without some protocol-level changes Yeah, I'd say you could do it now without protocol level changes but that would be bad for everyone else without those protocol-level changes | 18:35:02 |
