forked from cadence/out-of-your-element
Guzio
748e851b39
/This is a squash-commit - the following is a rough summary of all sub-commits, written in style of commit messages (not necessarily those commits themselves), ie. short and in present tense./ * Document design choice to not bridge Discord threads as Matrix threads [by directly quoting Cadence] * Alter thread-to-announcement, so that it replies in-thread [with this, Matrix users will get a list of almost all (exl. those that don't branch from anything) open threads on a given channel, whereas before it wasn't possible. Also features slight alterations to the text] * Notify the user, whenever an in-thread message on Matrix is sent, that this isn't how they're supposed to do threads on OOYE * Detect /thread being ran as a reply or in-thread to branch the thread from the relevant message * Handle various /thread errors [notably being ran without args (infer the title if ran in the context above, simply show help if not)] * Whenever possible, direct the user to an already-existing thread-room [if /thread was ran as a reply or in-thread, or as part of the notification mentioned in point 3 (feat. a new utility method)] AUXILIARY TYPE CHANGES (not always relevant to UX-improvement-related changes): * Fix „boolean” being referred to as „bool” in types.d.ts * Rename execute(event) in matrix-command-handler is now parseAndExecute(event) [and it is no longer of type CommandExecute, but has its own custom definition, because a) it has a different return now (returns what command was ran (needed for point 3 in section above) instead of always undefined and b) other params from CommandExecute (like ctx or words) weren't being used - quite the contrary, their values were only being created at that stage (as part of command parsing - hence the rename, too), so telling that they're values you pass into execute() was at least somewhat confusing] * Further narrow-down the type of guard() in m2d event-dispatcher TEST CHANGES: * Create 7 new tests, all pass * Update 4 existing threads, all pass * Pass all other relevant tests [and almost all other tests, too - there are some issues with event2message for stickers, but given the fact that this commit does not touch the stickers subsystem in any way at all, it does not seem like they are any way related to my changes and they must've been failing before] * Do extensive manual testing and debugging Co-authored-by: Guzio <guzekk@protonmail.com> Co-committed-by: Guzio <guzekk@protonmail.com>
1.3 KiB
1.3 KiB
I thought pretty hard about it and I opted to make threads separate rooms because
- parity: discord has separate things like permissions and pins for threads, matrix cannot do this at all unless the thread is a separate room
- usage styles: most discord threads I've seen tend to be long-lived, spanning months or years, which isn't suited to matrix because of the timeline
- I'm in a discord thread for posting photos of food that gets a couple posts a week and has a timeline going back to 2023
- the timeline: if a matrix room has threads, and you want to scroll back through the timeline of a room OR of one of its threads, the timeline is merged, so you have to download every message linearised and throw them away if they aren't part of the thread you're looking through. it's bad for threads and it's bad for the main room
- it is also very very complex for clients to implement read receipts and typing indicators correctly for the merged timeline. if your client doesn't implement this, or doesn't do it correctly, you have a bad experience. many clients don't. element seems to have done it well enough, but is an exception
overall in my view, threads-as-rooms has better parity and fewer downsides over native threads. but if there are things you don't like about this approach, I'm happy to discuss and see if we can improve them.