New signup process #1297

fnetX commented 2023年09月21日 02:01:10 +02:00

Comment

The Codeberg e.V. presidium recently talked about a new approach to new user accounts on Codeberg. This has some history.

Let's reiterate the problems:

• spam waves (accounts are easily created)
  • creating thousands of issues
  • deleting user accounts takes much more resources on the server than creating them (performance problem, DoS)
  • emails are sent out → bad email reputation
  • users are annoyed and project workflows disturbed
  • we receive copyright complaints when linking to infringing material → legal issue
• captcha is inaccessible, also see #479, #483
• interaction quality on Codeberg is low (if it is "too easy" to create an account, you have more people who don't care about free software and simply drop a comment and never show up again; or that actually have a very demanding / rude tone)
• performance issues lead to repeated requests to slow down new user accounts, see #908 and #1130 for examples
  • introducing a singup workflow that better tells users that Codeberg is about Free Software might reduce the amount of proprietary / private repositories abusing our service

The following options have been discussed and have been found not to tackle the problems in a sufficient way:

• manual account approval: increased effort on our side, potential delay might turn off contributors ("I just want to report a small bug to project X")
  • it works well for e.g. Mastodon instances, but if you just want to participate quickly, you have federated instances at hand which is not yet the case with Codeberg
• other captcha options are either not accessible, not privacy friendly, not well tested or have other difficulties; and the setup at Codeberg stalled
• removing spam does not seem to reduce its creation

We reconsidered the pros and cons for manual account approval and came to the conclusion that:

• reading a short text is less effort than writing it (DoS ratio is balanced again)
• the review workflow might easily be offloaded
• increasing the barrier might increase the quality of interactions on Codeberg

So we open up the possibility for someone to implement a service that could look like this (or similar):

• Forgejo-native signups are disabled, the sign-up route redirects to an external service instead
• the service explains what Codeberg is and asks one or a few questions
• the necessary information for the registration is asked in the form (e.g. username, email etc)
• based on the responses, someone has the possibility to approve the registration
• confirming the correctness of the mail address still makes a lot of sense
• we could regularly ask long-term Codeberg users (e.g. older than a year) to sign in via OAuth and give them the possibility to review a few accounts and do us a favour
• the accounts can finally be created via API

(The technical implementation can vary a lot, an implementation within Forgejo might also be an option)

If someone wants to work on this, please let us know, ideally by creating a team in Codeberg/Contributing. We will not currently dedicate any power of ours to it, but we welcome contributions, because we think that this might be a more healthy way to join Codeberg.

Feedback about the idea itself is also very welcome.

Thank you for understanding.

### Comment The Codeberg e.V. presidium recently talked about a new approach to new user accounts on Codeberg. This has some history. Let's reiterate the problems: - spam waves (accounts are easily created) - creating thousands of issues - deleting user accounts takes much more resources on the server than creating them (performance problem, DoS) - emails are sent out → bad email reputation - users are annoyed and project workflows disturbed - we receive copyright complaints when linking to infringing material → legal issue - captcha is inaccessible, also see #479, #483 - interaction quality on Codeberg is low (if it is "too easy" to create an account, you have more people who don't care about free software and simply drop a comment and never show up again; or that actually have a very demanding / rude tone) - performance issues lead to repeated requests to slow down new user accounts, see #908 and #1130 for examples - introducing a singup workflow that better tells users that Codeberg is about Free Software might reduce the amount of proprietary / private repositories abusing our service The following options have been discussed and have been found not to tackle the problems in a sufficient way: - manual account approval: increased effort on our side, potential delay might turn off contributors ("I just want to report a small bug to project X") - it works well for e.g. Mastodon instances, but if you just want to participate quickly, you have federated instances at hand which is not yet the case with Codeberg - other captcha options are either not accessible, not privacy friendly, not well tested or have other difficulties; and the setup at Codeberg stalled - removing spam does not seem to reduce its creation We reconsidered the pros and cons for manual account approval and came to the conclusion that: - reading a short text is less effort than writing it (DoS ratio is balanced again) - the review workflow might easily be offloaded - increasing the barrier might increase the quality of interactions on Codeberg So we open up the possibility for someone to implement a service that could look like this (or similar): - Forgejo-native signups are disabled, the sign-up route redirects to an external service instead - the service explains what Codeberg is and asks one or a few questions - the necessary information for the registration is asked in the form (e.g. username, email etc) - based on the responses, someone has the possibility to approve the registration - confirming the correctness of the mail address still makes a lot of sense - we could regularly ask long-term Codeberg users (e.g. older than a year) to sign in via OAuth and give them the possibility to review a few accounts and do us a favour - the accounts can finally be created via API (The technical implementation can vary a lot, an implementation within Forgejo might also be an option) If someone wants to work on this, please let us know, ideally by creating a team in [Codeberg/Contributing](https://codeberg.org/Codeberg/Contributing/issues/). We will not currently dedicate any power of ours to it, but we welcome contributions, because we think that this might be a more healthy way to join Codeberg. Feedback about the idea itself is also very welcome. Thank you for understanding.

crystal commented 2023年09月21日 02:26:27 +02:00

This seems like a good idea. If we're going to have an external registration server that allows trusted users to log in and approve pending registrations, I think it would be pretty easy to implement an invite system on top of that. This would allow end-users to invite their team members using a one-time token which would bypass the usual approval process.

This seems like a good idea. If we're going to have an external registration server that allows trusted users to log in and approve pending registrations, I think it would be pretty easy to implement an invite system on top of that. This would allow end-users to invite their team members using a one-time token which would bypass the usual approval process.

yoctozepto commented 2023年09月21日 07:04:57 +02:00

We could also establish this way a chain of trust. Basically, what GPG (PGP) aimed to do at Internet scale with crypto but this time for our community and focused solely on the level of trust of the account itself (or rather, the human behind it). This way we know also which accounts are least likely to be "problematic".

We could also establish this way a chain of trust. Basically, what GPG (PGP) aimed to do at Internet scale with crypto but this time for our community and focused solely on the level of trust of the account itself (or rather, the human behind it). This way we know also which accounts are least likely to be "problematic".

JakobDev commented 2023年09月21日 08:17:28 +02:00

I think this would hurt more than it helps. This would also turn off people who just wants to write a bug report, which is not a good thing for projects hosted on Codeberg. Its also won't stop spammers. We must face the harsh reality in the year 2023. We know have large language models e.g. ChatGPT which are the holly grail for spammers. You can easily create natural sounding answers for those questions.

I think this would hurt more than it helps. This would also turn off people who just wants to write a bug report, which is not a good thing for projects hosted on Codeberg. Its also won't stop spammers. We must face the harsh reality in the year 2023. We know have large language models e.g. ChatGPT which are the holly grail for spammers. You can easily create natural sounding answers for those questions.

fourstepper commented 2023年09月21日 09:41:22 +02:00

I agree with @JakobDev. I am not in on the scope of the mentioned issues, however it doesn't seem to be enough of an issue to warrant such efforts for now

I agree with @JakobDev. I am not in on the scope of the mentioned issues, however it doesn't seem to be enough of an issue to warrant such efforts for now

yoctozepto commented 2023年09月21日 09:47:49 +02:00

Well, I agree this is a hammer-style solution but I disagree that spam bots would be inclined to use ChatGPT to persuade us. ;-) This would be the case if Codeberg was specifically targeted and I don't think this is the case. That said, I have not explained my entire position. I think this idea is good if all else fails. I mean, there is room for improvement on the technological side - again, that said, with either solution we need minds and hands to deliver them.

Well, I agree this is a hammer-style solution but I disagree that spam bots would be inclined to use ChatGPT to persuade us. ;-) This would be the case if Codeberg was specifically targeted and I don't think this is the case. That said, I have not explained my entire position. I think this idea is good if all else fails. I mean, there is room for improvement on the technological side - again, that said, with either solution we need minds and hands to deliver them.

dpk commented 2023年09月21日 11:56:49 +02:00

I agree with @JakobDev. In the @scheme working groups we want to encourage comments on our specifications (in the form of issues in our issue tracker) from as many people as possible, so that our work reflects the input and wishes of as large a segment of Scheme users as possible. Making signing up to Codeberg harder would limit our ability to do this.

I agree with @JakobDev. In the @scheme working groups we want to encourage comments on our specifications (in the form of issues in our issue tracker) from as many people as possible, so that our work reflects the input and wishes of as large a segment of Scheme users as possible. Making signing up to Codeberg harder would limit our ability to do this.

fnetX commented 2023年09月21日 12:06:15 +02:00

We are currently hit with SEO spam. Based on our research, ghost workers from countries like Indonesia are manually posting a lot of spam through the GUI. It works, because labour is cheap over there and it is very easy to "hire" them.

They are not IT experts, nor do they want to target Codeberg. They probably just want to spam out their stuff "somewhere". The scope of this proposal is to increase the hurdle and make it harder to register an account on Codeberg than for us to review the registrations. It will not prevent spam from entering Codeberg, but it makes it harder for them.

I compare this with open email gateways: Of course we haven't get rid of email spam, but it is harder to send spam today than it was when you could simply ask every mail server to forward your junk.

And replacing the inaccessible captcha with a more personal question is also valuable IMHO. Also take into account that manual user account approval was requested by Codeberg users a lot and works for many other services, too. Even if it slows down our growth, I think we get the goal of offering a reliable alternative Git hosting for Free Software projects a lot closer.

We are currently hit with SEO spam. Based on our research, ghost workers from countries like Indonesia are manually posting a lot of spam through the GUI. It works, because labour is cheap over there and it is very easy to "hire" them. They are not IT experts, nor do they want to target Codeberg. They probably just want to spam out their stuff "somewhere". The scope of this proposal is to increase the hurdle and make it harder to register an account on Codeberg than for us to review the registrations. It will not prevent spam from entering Codeberg, but it makes it harder for them. I compare this with open email gateways: Of course we haven't get rid of email spam, but it is harder to send spam today than it was when you could simply ask every mail server to forward your junk. And replacing the inaccessible captcha with a more personal question is also valuable IMHO. Also take into account that manual user account approval was requested by Codeberg users a lot and works for many other services, too. Even if it slows down our growth, I think we get the goal of offering a reliable alternative Git hosting for Free Software projects a lot closer.

dpk commented 2023年09月21日 12:14:06 +02:00

Could a statistical spam filter applied to the first contributions made by new users work as an alternative approach?

Could a statistical spam filter applied to the first contributions made by new users work as an alternative approach?

dpk commented 2023年09月21日 12:32:55 +02:00

Apologies for posting multiple comments, but I genuinely think that requiring someone who wants to file a bug report to explain why they are committed to free software, and have their answer approved, is a bad idea. It would make Codeberg unusable for us.

Many users of free software projects aren’t particularly interested in free software as an ideology. They are using the software because it solves a problem they have; the fact it’s free is at best a nice secondary benefit. If they find a problem, they still want to report it and get it fixed. You say ‘interaction quality on Codeberg is low’, and mention drive-by issue reports and entitled users as an example. But drive-by issue reports can still be valuable — and a new user’s commitment to the ideology of free software is no indication of how long they’ll stick around — and entitlement is not something you can solve unless by applying an extreme version of an ideological purity test in one’s answer to the proposed sign-up question.

In the Scheme working groups we have particularly extreme requirements: we have a charter that requires us to accept public comments from anyone who cares to submit one, including one-off contributions from people we never hear from again, and including comments with an air of entitlement.

Scheme is not per se a free software project — it’s mainly a specification for a language, and any actual code our repos contain is secondary to the actual spec. (Mostly example code and small sample implementations of individual features.) We chose Codeberg as the platform to host our spec and issue tracker for a number of reasons, including the Scheme community’s long-standing association with the free software community — going back to the MIT AI Lab in the 1970s, where both Scheme and the free software movement originated. Despite this association, not all Scheme users are free software activists and we cannot expect them to be.

If Codeberg were to make a change of this sort, we would probably be forced (by our charter) to find a different host. It was already difficult enough to find a host that met our requirements the first time: Codeberg offered us a unique set of positive features.

Apologies for posting multiple comments, but I genuinely think that requiring someone who wants to file a bug report to explain why they are committed to free software, and have their answer approved, is a bad idea. It would make Codeberg unusable for us. Many users of free software projects aren’t particularly interested in free software as an ideology. They are using the software because it solves a problem they have; the fact it’s free is at best a nice secondary benefit. If they find a problem, they still want to report it and get it fixed. You say ‘interaction quality on Codeberg is low’, and mention drive-by issue reports and entitled users as an example. But drive-by issue reports can still be valuable — and a new user’s commitment to the ideology of free software is no indication of how long they’ll stick around — and entitlement is not something you can solve unless by applying an extreme version of an ideological purity test in one’s answer to the proposed sign-up question. In the Scheme working groups we have particularly extreme requirements: we have a charter that requires us to accept public comments from anyone who cares to submit one, including one-off contributions from people we never hear from again, and including comments with an air of entitlement. Scheme is not per se a free software project — it’s mainly a specification for a language, and any actual code our repos contain is secondary to the actual spec. (Mostly example code and small sample implementations of individual features.) We chose Codeberg as the platform to host our spec and issue tracker for a number of reasons, including the Scheme community’s long-standing association with the free software community — going back to the MIT AI Lab in the 1970s, where both Scheme and the free software movement originated. Despite this association, not all Scheme users are free software activists and we cannot expect them to be. If Codeberg were to make a change of this sort, we would probably be forced (by our charter) to find a different host. It was already difficult enough to find a host that met our requirements the first time: Codeberg offered us a unique set of positive features.

crystal commented 2023年09月21日 16:12:53 +02:00

I agree with @JakobDev. I am not in on the scope of the mentioned issues, however it doesn't seem to be enough of an issue to warrant such efforts for now

I strongly disagree. With all due respect, how can you claim to know that it's not a big enough issue to warrant such efforts if you're not aware of the scope of the problem? Deleting spam accounts and users causes database deadlocks that bring Codeberg to it's knees for at least an hour each day. As much as we would love to simply defer this work to some later time when traffic is lower and fewer users will notice, that's not necessarily an option when the content of the spam violates various copyrights and Codeberg must act upon DMCA notices immediately.

> I agree with @JakobDev. I am not in on the scope of the mentioned issues, however it doesn't seem to be enough of an issue to warrant such efforts for now I strongly disagree. With all due respect, how can you claim to know that it's not a big enough issue to warrant such efforts if you're not aware of the scope of the problem? Deleting spam accounts and users causes database deadlocks that bring Codeberg to it's knees for at least an hour each day. As much as we would love to simply defer this work to some later time when traffic is lower and fewer users will notice, that's not necessarily an option when the content of the spam violates various copyrights and Codeberg must act upon DMCA notices immediately.

maltejur commented 2023年09月21日 17:59:41 +02:00

We recently moved to Codeberg, and one of the main reasons for that was because it makes signing up easy for users who want to report bugs (in opposition to GitLab, which requires users to verify with their credit card). So while I definitely see that this is one biggest problems facing Codeberg right now, it would also be sad to see users not joining Codeberg or writing bugs for projects on Codeberg because of a difficult sign up process.

So to still be able to provide a instant signup for users who just want to report a single bug or two, maybe the following mechanism could make sense. Users are able to sign up through the current UI, but new accounts are heavily rate limited. For example, they are only allowed to create 1-3 new issues, write ~5 comments, are not allowed to create new repositories, etc. If they then hit the rate limit, for example when trying to create a new repository, they are prompted to verify further, for example through questions with a text field and manual reviewers. If they then get manually verified, their account gets "upgraded" to a normal one. To address the "interaction quality on Codeberg is low" problem, a option for repositories could also be added to only accept comments from verified users. This way maintainers can individually decide if they find comments from new unverified accounts valuable or not. Would that make sense and still solve the problem?

We recently moved to Codeberg, and one of the main reasons for that was because it makes signing up easy for users who want to report bugs (in opposition to GitLab, which requires users to verify with their credit card). So while I definitely see that this is one biggest problems facing Codeberg right now, it would also be sad to see users not joining Codeberg or writing bugs for projects on Codeberg because of a difficult sign up process. So to still be able to provide a instant signup for users who just want to report a single bug or two, maybe the following mechanism could make sense. Users are able to sign up through the current UI, but new accounts are heavily rate limited. For example, they are only allowed to create 1-3 new issues, write ~5 comments, are not allowed to create new repositories, etc. If they then hit the rate limit, for example when trying to create a new repository, they are prompted to verify further, for example through questions with a text field and manual reviewers. If they then get manually verified, their account gets "upgraded" to a normal one. To address the "interaction quality on Codeberg is low" problem, a option for repositories could also be added to only accept comments from verified users. This way maintainers can individually decide if they find comments from new unverified accounts valuable or not. Would that make sense and still solve the problem?

ashimokawa commented 2023年09月21日 22:13:47 +02:00

Just a raw thought (and I know this would have to be a forgejo feature):

What if we distinguish between "verified" and "unverified" users, and then let project maintainers choose to open their project to "unverified" users while the default is "verified only".

Just a raw thought (and I know this would have to be a forgejo feature): What if we distinguish between "verified" and "unverified" users, and then let project maintainers choose to open their project to "unverified" users while the default is "verified only".

fnetX commented 2023年09月22日 15:10:57 +02:00

@dpk @maltejur Thank you for your comments. Please note that our signup process does not want to limit Codeberg's users to those interested in Free Software. Writing "I want to report a bug I just found" is also a totally acceptable use case. Also note that this is not something we are planning long-term, but a possible hotfix for a critical problem: We are drowning in spam.

I get your motivation, and I think that the quality of software increases drastically when more feedback is collected, because it allows all these small "quality of life" bugs (annoying, but not important enough to report) are fixed.

But maybe asking users to sign up for a platform like Codeberg is already the wrong approach there. Please consider if a good overall solution is finding other platform for feedback collection and having Codeberg as a working place for the development (including longer discussion regarding the feedback, design, translations etc).

The best long-term solutions is different in my eyes, but all implementations that work with user reputation etc or influence their abilities on the platform are hard to implement and not easily possible.

@dpk @maltejur Thank you for your comments. Please note that our signup process does not want to limit Codeberg's users to those interested in Free Software. Writing "I want to report a bug I just found" is also a totally acceptable use case. Also note that this is not something we are planning long-term, but a possible hotfix for a critical problem: We are drowning in spam. I get your motivation, and I think that the quality of software increases drastically when more feedback is collected, because it allows all these small "quality of life" bugs (annoying, but not important enough to report) are fixed. But maybe asking users to sign up for a platform like Codeberg is already the wrong approach there. Please consider if a good overall solution is finding other platform for feedback collection and having Codeberg as a working place for the development (including longer discussion regarding the feedback, design, translations etc). The best long-term solutions is different in my eyes, but all implementations that work with user reputation etc or influence their abilities on the platform are hard to implement and not easily possible.

akib commented 2023年09月22日 17:00:45 +02:00

If the new system makes it harder to report bugs, it'll be drastical. Most of the issues in my projects are sent by new accounts.

I'd suggest to add something like community moderation in "this" website. There'll some trusted users, and unverified/untrusted users will be able to create issues and do comments, but their rate will be limited (say... one per 30 minutes, and maybe one per 5 minute if the issue is opened by them). Then Codeberg will prompt verified users (on that issue's page) whether is issue/comment is spam or not. When the vote count exceeds some threshold, we can trust the user. If too many people reports the comment as spam, hide the comment, suspend the user account and put on moderation queue.

The untrusted users should probably also be able to create repositories, and they should public but searches shouldn't list them. Perhaps we can also limit the speed of push for them, so that they can't fill up the server.

And by the way, trusted user should be able to report spams, no matter who posted it.

If the new system makes it harder to report bugs, it'll be drastical. Most of the issues in my projects are sent by new accounts. I'd suggest to add something like community moderation in "this" website. There'll some trusted users, and unverified/untrusted users will be able to create issues and do comments, but their rate will be limited (say... one per 30 minutes, and maybe one per 5 minute if the issue is opened by them). Then Codeberg will prompt verified users (on that issue's page) whether is issue/comment is spam or not. When the vote count exceeds some threshold, we can trust the user. If too many people reports the comment as spam, hide the comment, suspend the user account and put on moderation queue. The untrusted users should probably also be able to create repositories, and they should public but searches shouldn't list them. Perhaps we can also limit the speed of push for them, so that they can't fill up the server. And by the way, trusted user should be able to report spams, no matter who posted it.

crystal commented 2023年09月22日 17:26:10 +02:00

I really appreciate that people are bringing different ideas for how to curb the spam issue, but many of these suggestions are simply off-topic for this issue. I understand that the proposed system is less convenient, and I also want Codeberg to remain easy to join for real people who actually want to participate in good faith. Unfortunately, it's currently far too easy for bad actors who only wish to fill our database with SEO garbage linking to scam websites. Bugs in Forgejo are currently preventing moderators from effectively dispatching these spammers, and severely degrading the quality of the service for the legitimate users whenever they try. I think there are some good ideas here, but most of them would require fairly extensive changes to Forgejo, and this sort of development can't happen overnight. The whole point of this issue is to implement some stopgap measure to curb the rampant abuse of the platform now, so legitimate users will not be plagued by it while we work on improving Forgejo's tooling and resolve its database performance issues.

I really appreciate that people are bringing different ideas for how to curb the spam issue, but many of these suggestions are simply off-topic for this issue. I understand that the proposed system is less convenient, and I also want Codeberg to remain easy to join for real people who actually want to participate in good faith. Unfortunately, it's currently far _too easy_ for bad actors who only wish to fill our database with SEO garbage linking to scam websites. Bugs in Forgejo are currently preventing moderators from effectively dispatching these spammers, and severely degrading the quality of the service for the legitimate users whenever they try. I think there are some good ideas here, but most of them would require fairly extensive changes to Forgejo, and this sort of development can't happen overnight. The whole point of this issue is to implement some stopgap measure to curb the rampant abuse of the platform _now_, so legitimate users will not be plagued by it while we work on improving Forgejo's tooling and resolve its database performance issues.

jcolomb commented 2023年09月25日 11:32:07 +02:00

A very interesting issue, glad I signed up before the storm.

A neat way to reduce the burden on the admin would be to ask new users to write a text about why they want to register AND review 3-4 user requests.
(one could also add some requests known to be spam so that reviews need to be correct on that one to be accepted)

A very interesting issue, glad I signed up before the storm. A neat way to reduce the burden on the admin would be to ask new users to write a text about why they want to register AND review 3-4 user requests. (one could also add some requests known to be spam so that reviews need to be correct on that one to be accepted)

fnetX commented 2023年09月25日 15:32:56 +02:00

I fear that allowing the user to review requests in this moment could allow them to approve themselves too easily by creating multiple accounts. I'd tend to delegate this to users who have been users for a long time.

I fear that allowing the user to review requests in this moment could allow them to approve themselves too easily by creating multiple accounts. I'd tend to delegate this to users who have been users for a long time.

akib commented 2023年09月25日 18:08:50 +02:00

Wikipedia works. And if we are really don't trust new user at all, how about a reputation system like Stack Overflow? (Okay I agree I'm too dumb.)

Wikipedia works. And if we are really don't trust new user at all, how about a reputation system like Stack Overflow? (Okay I agree I'm too dumb.)

ashimokawa commented 2023年09月25日 20:33:07 +02:00

@akib

wikipedia has a multi-mullion dollar budget, a lot of paid staff, they do delete all kinds of vandalism.

And for wikipedia everyone can clean the mess, but we cannot allow everyone to edit/close everyones issues.

@akib wikipedia has a multi-mullion dollar budget, a lot of paid staff, they *do* delete all kinds of vandalism. And for wikipedia everyone can clean the mess, but we cannot allow everyone to edit/close everyones issues.

fnetX commented 2023年09月28日 14:48:50 +02:00

In order to fight spam, we have used workarounds to limit certain email providers like gmail. We have blocked tons of throwaway and other dubious email providers that were part in recent spam campaigns. Obviously, this is not a good option either, so we really need to come to a better solution.

There are long-term discussions on how to improve the situation. We are continuing with better spam scanning, we already improved rate limiting a lot, and if someone has some free cycles, I think we'd appreciate some kind of limit for new users (e.g. disallow migrations, too many comments etc etc until they reach a certain age or even better, are set to "valid" in the database by some magic heuristic we apply).

However, I think that having a quick check what a user wants to do on Codeberg is still a good strategy, even considering the concerns. We can even apply some heuristic to auto-approve registrations based on some parameters, e.g. keywords of known projects that people could mention etc.

Valid answers for the question "Please quickly tell us what you plan to do on Codeberg?" could be:

I want to help translating xxx

I want to try it out

I noticed an issue with xxx

etc

In order to fight spam, we have used workarounds to limit certain email providers like gmail. We have blocked tons of throwaway and other dubious email providers that were part in recent spam campaigns. Obviously, this is not a good option either, so we really need to come to a better solution. There are long-term discussions on how to improve the situation. We are continuing with better spam scanning, we already improved rate limiting a lot, and if someone has some free cycles, I think we'd appreciate some kind of limit for new users (e.g. disallow migrations, too many comments etc etc until they reach a certain age or even better, are set to "valid" in the database by some magic heuristic we apply). However, I think that having a quick check what a user wants to do on Codeberg is still a good strategy, even considering the concerns. We can even apply some heuristic to auto-approve registrations based on some parameters, e.g. keywords of known projects that people could mention etc. Valid answers for the question "Please quickly tell us what you plan to do on Codeberg?" could be: > I want to help translating xxx > I want to try it out > I noticed an issue with xxx etc

Cwpute commented 2023年12月17日 15:05:26 +01:00

Picking and mixing together several ideas from here, this is my suggestion:

1. The traditional registering process to create an account on Codeberg would always lead to a manual verification by moderators or volunteers, no matter what (as sugg. by @crystal). Newcomers to write a short text explaining what they want to do on Codeberg (as sugg. by @fnetX).
   Additionally, newcomers may be granted instant acces to such or such repository of their choosing by explicitely naming one in their request, in plain text for manual verification, or picked from a search box result list (as sugg. by @fnetX).
2. For projects already on Codeberg, we could grant specific permissions: when activated by project maintainers, users who create an account from that project page, issue, commit or anything, will be instantly (after email verification) authorized to contribute to that one project (as sugg. by @ashimokawa ). This could also be worked as "invite links" generated by project maintainers, that only grant contribution permissions to their specific project.
   These limitations would last indefinitely, until verification by moderators, or until a set amount of time has passed, or after a specific set of actions have éeen performed (think Discourse's levels of trust).

This solution would greatly deter spamers, as they would be limited to a single repository in their spamming. And even if they do manage to spam in that one repo, it's still easy to spot and stop that spammer, revoke invite links or deactivate automatic contribution permissions on your project on account creation.
At the same time, it still allows for quick account creation for those who want to report a single issue with their favourite software, which will appear seamless to them, while allowing us to secure, contain and protect (pun intended).

Picking and mixing together several ideas from here, this is my suggestion: 1. The traditional registering process to create an account on Codeberg would always lead to a manual verification by moderators or volunteers, no matter what (as sugg. by @crystal). Newcomers to write a short text explaining what they want to do on Codeberg (as sugg. by @fnetX). Additionally, newcomers may be granted instant acces to such or such repository of their choosing by explicitely naming one in their request, in plain text for manual verification, or picked from a search box result list (as sugg. by @fnetX). 2. For projects already on Codeberg, we could grant specific permissions: when activated by project maintainers, users who create an account from that project page, issue, commit or anything, will be instantly (after email verification) authorized to contribute to that one project (as sugg. by @ashimokawa ). This could also be worked as "invite links" generated by project maintainers, that only grant contribution permissions to their specific project. These limitations would last indefinitely, until verification by moderators, or until a set amount of time has passed, or after a specific set of actions have éeen performed (think Discourse's levels of trust). This solution would greatly deter spamers, as they would be limited to a single repository in their spamming. And even if they do manage to spam in that one repo, it's still easy to spot and stop that spammer, revoke invite links or deactivate automatic contribution permissions on your project on account creation. At the same time, it still allows for quick account creation for those who want to report a single issue with their favourite software, which will appear seamless to them, while allowing us to secure, contain and protect (pun intended).

n0toose commented 2024年02月18日 22:49:22 +01:00

Hi, I found out about this service / component that might be worth linking here:

• https://code.europa.eu/eu-captcha/EU-CAPTCHA/

Hi, I found out about this service / component that might be worth linking here: - https://code.europa.eu/eu-captcha/EU-CAPTCHA/

fnetX commented 2024年02月18日 22:56:40 +01:00

Offtopic / what did they do to their navbar?there is a small status bar with small and barely readable text, and a big navbar with a EU logo, the bar is 3 times the size of normal navbars and covers important parts of the page, rendering them unreadable, too

I still believe that the best captcha is no captcha. Captchas ahve become useless basically.

Offtopic / what did they do to their navbar? I still believe that the best captcha is no captcha. Captchas ahve become useless basically.