| 1 May 2025 |
 @emma:rory.gay | * oh, did you mean matching /@.*:.*/? | 15:49:03 |
 @joepie91:pixie.town | yes, that is the kind of thing I am talking about. and if it's not certain that an @ is always followed by an mxid, then it could even be @\B (ie. @ followed by a non-boundary character) | 15:49:10 |
| @emma:rory.gay | i feel like this would be the most reliable way to handle it, tbh | 15:49:53 |
| @emma:rory.gay | unless you have a bunch of users that just have singular english words as localpart/displayname... | 15:50:11 |
| @emma:rory.gay | at which point, you've been scuntorphe'd | 15:50:31 |
| @joepie91:pixie.town | it would be, but the point I was trying to make above isn't that it's suboptimal, because that can easily be responded to with "well I didn't have the time to get it right". the point I was trying to make is that it would've taken like 5 more minutes and zero structural code changes to deal with the low-hanging fruit only by doing a simple regex check, and that even that wasn't done, and that this is a recurring problem with element/matrix core code | 15:51:34 |
| @joepie91:pixie.town | checking against a list of known users would be ideal but even without the resources to implement that (as it involves state management and so is a bit more work), there is still no excuse for the implementation as it exists today | 15:52:05 |
| @emma:rory.gay | tbh, this is the kind of thing they would definitely accept a PR for | 15:52:36 |
| @joepie91:pixie.town | a PR will not fix this because it is a process problem, not a code problem | 15:52:52 |
| @joepie91:pixie.town | core devs write these bugs into the code faster than you could possibly PR fixes | 15:53:02 |
| @joepie91:pixie.town | that is why things never actually get more reliable | 15:53:10 |
| @joepie91:pixie.town | * that is why things never actually get more reliable despite things getting fixed | 15:53:18 |
| @emma:rory.gay | ive had more impactful changes merged tbh | 15:53:23 |
