Allow Good Status Uploaders to approve other uploaders.

[gbaz]

Arxiv or lobste.rs style -- as suggested by chris martin on twitter.

Draft workflow: once someone registers an account they get a magic link that they can send to two people who are themselves approved uploaders for A) more than a month and B) have at least two uploads each. Those two can click the magic link to approve the new uploader.

This alleviates the burden from trustees. @ysangkok @andreasabel what do you think?

[ysangkok]

Sounds great, I'd happily implement something like this.

I am not sure magic/tokens are really needed though, you could simply have the database store a list of people who have vouched for every single user (defaulting to []). You could have a link like /user/{username}/vouch which would be accept POST and GET. Then the user wants to get approved could just send that link around, no need for magic. Once the list grows beyond length N, Hackage-server adds the user to the Uploaders group and stops accepting new vouches.

I think tokens mostly make sense when there is no other reliable authentication. But in our case, we have that, since the people who vouch should be able to log into their Hackage accounts.

I think Lobsters uses tokens because the flow is in the other direction: the trusted users invite the untrusted.

[gbaz]

Yep, your approach sounds cleaner. I'd also want to store when someone was vouched for, just for more audit trail here. I like this approach, and think it could help a fair amount, although I'm not sure it would subsume the trustee approach or just be an alternate -- i.e. we don't want it to only be word of mouth for growth. 🤔

[friedbrice]

you could simply have the database store a list of people who have vouched for every single user

@ysangkok I am very confused by your description, and I can't imaging the specifics of a workflow that it entails. Imagine that Alice has vouches for every single user, including Bob. Since Alice has vouched for Bob, Bob can add Carol. But once Carol is a user, Alice has no longer vouched for every single user! What's my misapprehension here?

[gbaz]

i believe the intended meaning is: "have the database store a map of users to the list of those that have vouched for them"

[ysangkok]

Indeed, that is the interpretation I intended. Sorry I didn't word it very elegantly.

[andreasabel]

What happens in the bad cases?

• Alice vouched for Bob who turned malicious
• Alice maliciously vouched for Bob and Carol

[ysangkok]

@andreasabel Given that the list of vouches is never deleted, only appended to, there could be a page for trustees that would allow reviewing the chain of vouches to determine when it went bad.

The page could show a tree, with the root being the user being scrutinized, and the children of each node being the person(s) that vouched for the parent node.

Would that be sufficient?

[gbaz]

Right -- in the event we get a spam package we can trace up the tree to find the malicious approvers and cut them off.

[ysangkok]

In two weeks time I will retire from Flipstone, and I will get more time. I will then start working on this feature, initially by making some UI mockups.

David Christiansen and I were wondering one thing though: Would it make sense to add reCAPTCHA first instead? Because that would be a lot less work. We could also make it such that reCAPTCHA gave you a "vouch" automatically.

CAPTCHAs in general might be circumventable by spammers, but reCAPTCHA is integrated with the Google account system. Is the main issue with this approach that we don't wanna be helping or using big tech conglomerates like Google?

[gbaz]

The issue is that the spammers we have gotten are not "volume" ones but targeted. They're willing to expend actual resources and time to get verified and then upload spam packages. So they're willing to personally jump through extended captcha hoops, etc. to get verified, if that means they can get some spam up on a high-ranked (seowise) site. The only real thing that can stop them is a social process with actual responsible people vetting them.

[ysangkok]

Here are some UI mocks that I'll start implementing the day after tomorrow if there are no complaints:

First off, any user follow a link from the user link of a any user page (see the view bottom):

Once clicking this link, you land at /user/<username>/vouches which shows a list of vouches for that user, and if you have been a member of the Uploaders group for more than a week, it has a button to add an additional vouch.

When the button is pushed/clicked, the page contents changed to reflect that your vouch has been added:

The button would POST to the same URL, and after verifying and processing the POST, the server would show the GET response again.

If any user shown on the list was themselves vouched for, a link to their vouch page is appended after their user name. This allows for drilling down in the case of abuse ('vouches' would link to /user/HaskellCurry/vouches):

I could add the tree (mentioned above) also, but I think it won't be necessary, since I am thinking of rate-limiting using the date of addition to the 'Uploaders' group.