There were optimizations related to database triggers, these are probably responsible for the speedup.
Lemmy maintainer
There were optimizations related to database triggers, these are probably responsible for the speedup.
Alright Ive added @kevincox@lemmy.ml, @CrypticCoffee@lemmy.ml and @Lettuceeatlettuce@lemmy.ml 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.
True there are a lot of issues related to notifications. I will see what I can do.
Here is the relevant issue, but no one is working on it currently.
It was always normalized, but recently there seems to be more backlash from maintainers.
Mastodon seems like a better comparison. It has more than a dozen forks and clones, and plenty of donation income.
Sure it would be good to have more contributions in Lemmy, but as these projects are made by volunteers they will do what they are most interested in. Nothing we can do to change that. And if they add new features which prove useful, they can also be added to Lemmy.
New users for Piefed and Sublinks are most likely to come out of the millions of Reddit users, not out of a few thousand Lemmy users. So this will increase the size of the Lemmy network and lead to more activity.
Having other projects which are similar to Lemmy is a great sign. It means users have more choices available and developers can experiment with different solutions. It’s really not a competition, because the existence of more compatible Fediverse projects will also benefit Lemmy, as there will be more users and more content.
Yes that’s me :)
There is an issue which discusses this: https://github.com/LemmyNet/lemmy/issues/4298
Sounds like there might be a bug in Lemmy then. Please open an issue in the Lemmy repo.
Well written, it would deserve a separate post.
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.
The Activitypub protocol is fine. It could use some minor improvements but there’s definitely no reason for an entirely new protocol.
The key is refreshed after 24 hours so it will work if you wait a bit.