Its okay, everyone is wrong about some things.
Lemmy maintainer
Its okay, everyone is wrong about some things.
Good example of AI making stuff up instead of simply saying “I don’t know”.
Alright Ive added @[email protected], @[email protected] and @[email protected] as mods and removed the inactive ones.
I just opened an issue about it: https://github.com/LemmyNet/lemmy/issues/4744
This, particularly reports are not fully federated.
None of that matters if Mastodon doesnt implement these suggestions or standards. And from past experience its extremely unlikely that they will. Thats why I think its best to ignore what Mastodon does, its not our concern how they decide to render things.
It was always normalized, but recently there seems to be more backlash from maintainers.
We have never rejected any patches from lemmy.world admins or from sublinks developers.
Well written, it would deserve a separate post.
I couldnt find it in the repo, what sort of plugin hooks do you have?
Sure the plugin hooks still need to be implemented. It wouldnt make much sense to do that now before any actual use case exists, then the hooks would remain unused or wouldnt even work properly. Thats why it should be implemented together with a proof of concept plugin.
Its not necessary to learn Rust to improve mod tools in Lemmy. There can be external mod tools implemented as api clients using any language, such as LemmyAutomod. Its also possible to add plugin support for Lemmy, which again can be implemented in various languages thanks to webassembly
This is not true, Lemmy can definitely have plugins and there is an extensive discussion about this topic. The conclusion is that plugins should be implemented in webassembly, so that they can be written in many different languages. See extism for details. Whats needed is someone with a clear use case who can implement a proof of concept, as it wouldnt make sense to add plugin hooks that no one uses.
Also mod tools can be implemented as api clients such as LemmyAutomod.
One of the comments mentions that another app can trigger search through an Android intent. So its better to be safe and close any potential vulnerabilities, but this doesnt seem particularly useful for an attacker.
I dont have time to read all that. The problem with Beehaw is that the admins are extremely entitled, as if we had some obligation to work for them for free. Similar to what is described in OP.
However we are consistently improving the mod tools, and accept contributions in that area. You can see in the dev updates.
What is this “stance on mod features” that you are talking about?
Im a former contributor to F-Droid with various merged pull requests. Looking at the indicated pull request I really doubt that it was an intentional attack. First of all its easy to forget for a new developer to escape SQL parameters, and the docs dont even mention a risk of SQL injection attacks. And of the users pushing for the PR to be merged, one is a long-time F-Droid contributor, and the other also looks like a real human with many contributions in other repos, so no sockpuppets in sight.
It simply looks like standard open source behaviour, for better or for worse. A new user makes a contribution for a highly demanded feature, and users want it to get merged as soon as possible. Maintainers are discussing the big picture of the change and want to avoid breaking changes, without getting into code review yet. The new contributor seems unwilling to make any design changes to his PR, and gets frustrated that it doesnt get merged as is. The potential vulnerability is only noticed half a year after the PR was opened, at which point it was already de facto abandoned. So not an attack, but simply a developer who is new to open source and doesnt understand how the process works.
We applied for funding last August, but unfortunately we are still waiting for it to be finalized. Seems like NLnet is quite overloaded these days.
We only do major versions around once a year so those could still be named, while using numbers for minor versions. Lemmy is more user-facing than react, so it would make sense to have a more user-friendly versioning.
You can use pg_stat_statements to find slow queries. Try sorting by top
total_exec_time
.