Rename SLUR_REGEX to POST_FILTER_REGEX POST_FILTER_REGEX gets its value from ENV var LEMMY_POST_FILTER_REGEX and has a default that matches nothing (.^) updating test cases to use a filtering regex...
It seems like you’re arguing from a point of unfamiliarity with federated social media like Mastodon. When you’re talking about “syncing the message” being able to “crash” an instance of Lemmy, this is not based on how anything ActivityPub actually works.
I don’t know what Lemmy does, and I’m not sure how much clearer I could have been that the possible outcomes mentioned were speculative, having seen no other Lemmy code than the slur filter. I saw just one line of code and it was lousy.
Mastodon nodes certainly *do* store copies of msgs from other nodes, which is precisely why I would envision Lemmy having msg redundancy.
Below you’ve construct a straw man about how if a slur filter has been implemented one way, then that means that it must programmatically break federation if it’s variant between instances
You don’t know what a straw man is. A straw man is obviously *not* speculating on risks and outcomes. To construct a straw man is to misrepresent someone else’s argument. My reply was to @adrianmalacoda@lemmy.ml . I did not even present his arguments, so there was obviously no opportunity to misrepresent them.
Pretty radical semantic versioning you’ve got going on there if every modification requires a different project name. 🙄
This ^ is an example of a straw man. I neither said nor implied that a modification “requires a different project name”, yet you’re implying that this is my stance.
When you fork a project and modify it, and the mods are not to be integrated upstream, the new software is different and the project is yours regardless of what you name it. If the original project name isn’t trademarked and you don’t care about causing confusion, you can name it the same if you want, and even choose conflicting version numbers. The authorship is likely different as well (it’s the set of all upstream authors plus yourself).
The way these instances will interact has probably not yet been specified, so it’s ridiculous to start getting up in arms about it.
You’re apparently implying here that you think it’s wise to ignore the production of code that will likely cause a conflict in the future and wait until the problem manifests during operation time. As opposed to thinking in advance “hey, hard-coding an English slur filter for the world maybe isn’t the smartest way forward”?
This is *precisely* the time to get the design right on this-- if not sooner.
Please do not start spreading pseudotechnical FUD about the properties of this software without reference to fact.
I’m afraid state of the art software design principles are not “fact”. Sorry you have to hear this from me, but competent design prior to implementation is a subjective opinion. It’s an opinion that’s widely held in high regard across the most prestigious academic institutions in the world and has far more merit than the sloppy and reckless approach you’ve suggested. And how dare you present your “personal opinion” and then demand facts – without so much as stating what factual information you’re in need of.
I don’t know what Lemmy does, and I’m not sure how much clearer I could have been that the possible outcomes mentioned were speculative, having seen no other Lemmy code than the slur filter. I saw just one line of code and it was lousy.
Mastodon nodes certainly *do* store copies of msgs from other nodes, which is precisely why I would envision Lemmy having msg redundancy.
You don’t know what a straw man is. A straw man is obviously *not* speculating on risks and outcomes. To construct a straw man is to misrepresent someone else’s argument. My reply was to @adrianmalacoda@lemmy.ml . I did not even present his arguments, so there was obviously no opportunity to misrepresent them.
This ^ is an example of a straw man. I neither said nor implied that a modification “requires a different project name”, yet you’re implying that this is my stance.
When you fork a project and modify it, and the mods are not to be integrated upstream, the new software is different and the project is yours regardless of what you name it. If the original project name isn’t trademarked and you don’t care about causing confusion, you can name it the same if you want, and even choose conflicting version numbers. The authorship is likely different as well (it’s the set of all upstream authors plus yourself).
You’re apparently implying here that you think it’s wise to ignore the production of code that will likely cause a conflict in the future and wait until the problem manifests during operation time. As opposed to thinking in advance “hey, hard-coding an English slur filter for the world maybe isn’t the smartest way forward”?
This is *precisely* the time to get the design right on this-- if not sooner.
I’m afraid state of the art software design principles are not “fact”. Sorry you have to hear this from me, but competent design prior to implementation is a subjective opinion. It’s an opinion that’s widely held in high regard across the most prestigious academic institutions in the world and has far more merit than the sloppy and reckless approach you’ve suggested. And how dare you present your “personal opinion” and then demand facts – without so much as stating what factual information you’re in need of.
lol k