Look, we can debate the proper and private way to do Captchas all day, but if we remove the existing implementation we will be plunged into a world of hurt.
I run tucson.social - a tiny instance with barely any users and I find myself really ticked off at other Admin’s abdication of duty when it comes to engaging with the developers.
For all the Fediverse discussion on this, where are the github issue comments? Where is our attempt to convince the devs in this.
No, seriously WHERE ARE THEY?
Oh, you think that just because an “Issue” exists to bring back Captchas is the best you can do?
NO it is not the best we can do, we need to be applying some pressure to the developers here and that requires EVERYONE to do their part.
The Devs can’t make Lemmy an awesome place for us if us admins refuse to meaningfully engage with the project and provide feedback on crucial things like this.
So are you an admin? If so, we need more comments here: https://github.com/LemmyNet/lemmy/issues/3200
We need to make it VERY clear that Captcha is required before v0.18’s release. Not after when we’ll all be scrambling…
EDIT: To be clear I’m talking to all instance admins, not just Beehaw’s.
UPDATE: Our voices were heard! https://github.com/LemmyNet/lemmy/issues/3200#issuecomment-1600505757
The important part was that this was a decision to re-implement the old (if imperfect) solution in time for the upcoming release. mCaptcha and better techs are indeed the better solution, but at least we won’t make ourselves more vulnerable at this critical juncture.
I disagree, once your open source project “sprouts wings” you enter an unspoken power battle. If enough of the community disagrees with something the chance of a successful fork grows. Once a project is forked away, you no longer have any control at all.
Also, even if I don’t upgrade to v0.18, I have to live in a fediverse that have other instances that WILL, and they might pose a problem with increased spam.
You’ve seen Hackers one too many times. Again you can run your instance however you want, and can defederate from instances that don’t implement things they way you are demanding they should, but you do not dictate how others (or the developers) run things.
The beauty of open source is you can always fork your own. The beauty of federation is you can block whoever you want or whatever instance you want.
Other than that, you have no right to demand anything of anyone.
No, I was around when SysV Init was “replaced” by Systemd and how that impacted the Debian project (and other distros).
But you know what, sure, let’s stick to your bad faith, insulting interpretation, after all it is more becoming of an internet troll. I’m sure it’ll get you lots of updoots from similarly trollish individuals.
Personally, I believe in something called collective responsibility, and that does including expecting community members to do their fair share. But it sounds like you envision federations as mini fiefdoms.
I’m not part of this conversation, I am not a mod, I am not an admin, and I’m not necessarily informed enough to make any determination on who is right and wrong. However,
There’s no such thing.
I’ll give you that one. Speaking of which, I should watch it again, I haven’t done so this year yet.
… once again, the devs already said they would accept a PR with mCapchas. I don’t see why any capable dev would fork a project rather than just contribute code. The community can disagree all they want - it takes actual programmers to split.
And if other instances start becoming spambots, just defederate.
A fork avoids this problem how?
Who’s writing the code for the fork? If you see them, can you ask them to just submit the PR that the devs said they’ll approve?
That assumes that the fork would be mCaptcha rather than a simple reversion to the existing captcha. But yeah, the fork would initially be a roll back until mCaptcha is implemented either in our own or in the base repo.
And then you’ll need to convince every instance admin to swap to this fork.
Right but to your other point, the admins who don’t fork will send you spam.
What does that mean in the context of lemmy’s license? As I understand it, everyone is allowed to fork it away, but not allowed to change the license. Which allows everyone to fork it further away or back.
I don’t understand what control means in this context. Isn’t it a thing people can just modify and use, now and for all future?
That’s a bit decontextualized, but the idea is that other than the license terms ensuring that derivatives are also open source, there is also a power of community consensus and popular appeal. Your project will go further and get more improvements if it is popular and used by other developers. It’s less about forking having actual power, but what happens when folks feel they must fork because of a core issue with something the original project did that might take a while to be resolved. It can create a larger group of people in the latter group and thus make a fork to garner more interest than the original project.
So, do you think we need to step up to the developers to implement captcha or give way to the community and support a fork with better anty-spam measures?
I’m already in talks with some other admins about a potential fork. Initially we’d just roll back ONLY the captcha change, then work on a better implementation and roll it out in a way that doesn’t leave instances exposed.
It would be seamless for most users since it’s essentially the same thing as before, just with the Captcha code still included.
Instead of going to the effort of managing a fork, why not just submit a PR with hCapcha to the base repo 🤣 As a Dev, it’s not that hard.
Sounds good, thank you for your efforts! I think the decision is bad for the current state of the lemmyverse, we need some roadblocks for spam bots.
I think forks and OG projects can live side by side, even more so, they can have a symbiotic relationship. The beauty of open source that we can learn from each other.