| 1 May 2025 |
 @joepie91:pixie.town | and so there would be something attached to the @ and so you should be checking for that, not just counting isolated @s | 15:47:42 |
 @emma:rory.gay | ideally, you'd check for just localparts and displaynames, yes | 15:48:01 |
| @joepie91:pixie.town | no, that is not what I said | 15:48:09 |
| @emma:rory.gay | oh, did you mean matching @.*:.*? | 15:48:35 |
| @emma:rory.gay | aka "is it a valid mxid" | 15:48:42 |
| @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 |
| @emma:rory.gay | like not running an entire machine learning model if your sensitivity is set to 0 anyways | 15:53:42 |
| @joepie91:pixie.town | if you simply do not have a culture of trying to get things "as right as possible within the constraints" then you will never get reliable code regardless of how much work other people put into trying to fix it | 15:53:55 |
| @joepie91:pixie.town | and matrix core does not have that culture and that is why everything sucks | 15:54:15 |
| @joepie91:pixie.town | it's a negligent approach to software development | 15:54:34 |
| @joepie91:pixie.town | this just happens to be a particularly obvious example of the problem | 15:54:49 |
| @emma:rory.gay | true | 15:55:10 |
 KFears (they/them) | In reply to @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 I have seen a lot of such code coming from corporate world. Not sure if there's a correlation here | 15:58:53 |
| @joepie91:pixie.town | KFears (burning out): there is; a lot of companies are purely extractive towards their developers, in that they are expected to be 'shipping code' at all times, and they do not get the room to experiment and learn to improve their craft | 16:15:23 |
| @joepie91:pixie.town | it's not the only factor, but pressure is often a factor in unnecessary corners getting cut, because people start taking the most obvious paths for everything, assuming that any further effort would slow them down, instead of actually doing the analysis | 16:16:10 |
| @joepie91:pixie.town | and so people start associating "doing it right" with "costs a lot of time" even though often the opposite is true, not just in the long term but even in the short term | 16:16:50 |
| @joepie91:pixie.town | this is very much a culture problem, ultimately | 16:17:26 |
| @emma:rory.gay | i do a lot of shippiong code | 16:17:32 |
