-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open singups discussion #62
Comments
I thought about this a bit and have some different thoughts. I think the 'shadowban' thing was too complex and unnecessary. Instead, I basically just copied what I do on https://flounder.online/ User creates account with a brief description of where they came from -> they are set as pending = true, and cannot make posts -> admin approves them A really hacky version of this is on my PR (it is not very clean but just a demo to experiment with for now) |
no need to apologize, it's been great to see you have fun with cerca! in my mind fishbb is like a vanguard trying out variations of potential solutions. hope you are not in a rush to get things merged, i've been away from computers on weekends recently and enjoying that so additions and changes in the very near-term may be a bit delayed
could you come up with a solution that allows composing multiple different signup solutions?i could see open signups being good for a fresh new community but if that forum gets raided / has spam issues then you might want to turn that off but keep other modes operating
you are correct, and i'm not entirely sure yet how i land on this! i'm not entirely opposed but: having a bigger community of potential randos starts to introduce the need for individual users having affordances like hiding posts from users they feud with (less of an issue with a more tight-knit community with prior/alternate conflict resolution mechanisms)
this seems like a simpler approach than shadowban 👍 to bring down admin burden and easily mitigate abuse this needs, imo, a batch-operation mode with checkboxes and where you can toggle all / toggle none (here be sneaky javascripts hiding) to selectively confirm/delete pending accounts |
No worries, I kinda burnt myself out working on this most of the weekend haha I'll prob work at a slower pace now
After some thought, I changed my mind on this -- I think that purely open signups makes spam too much of an issue. The operational burden of managing spam is too much for what cerca is trying to be, I think. The "approval-based" workflow (my current approach / the flounder approach) seems like a good compromise for me.
My idea with the "approval-based" signup works for closer-knit communities as well -- it's easier for most nontechnical users to just make an account and wait for approval than a website or key based invitation system. So I'd say I'm aiming not at a big open forum with it, but rather just a way that reduces the friction of signups a bit.
This is a good call. Surprisingly, I've never had an issue with flounder.online having a ton of junk signups, and it's been online for 4 years. The only antispam is that I only allow 1 registration per IP per day and I haven't even seen anyone try to abuse that |
Sorry for all the issues today, I've been doing a lot of work on cerca haha
I've been working on an optional boolean to allow open singups. This involve creating a concept of shadowbanned / "hidden" users. Posts by these users are visible only to themselves and admins
admins can then either unhide a user's account, or ban them if they are spammers. This allows users to participate immediately without something like email confirmation, while also locking spammers out of making posts (while giving them no visible feedback that their posts are invisible)
I would imagine this isn't necessarily what cerca is originally designed for, but I don't think it deviates too far -- and I think it makes it easier for small communities where an admin can simply ban anyone who isn't in the targeted community, while also making it so it's easier for people to sign up
WIP implementation on aw-fork2
#59 is intended to lay the groundwork for this, simply so people can't extremely trivially ddos the server and make the site unusable for admins
The text was updated successfully, but these errors were encountered: