zlacker

Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors

>>abraco+(OP)
Indeed, it's relatively impossible without ties to real world identity.

>>abraco+(OP)
you can't really build a perfect system, the goal would be to limit bad actors as much as possible.

>>abraco+(OP)
You can't get perfection. The constraints / stakes are softer with what Mitchell is trying to solve i.e. it's not a big deal if one slips through. That being said, it's not hard to denounce the tree of folks rooted at the original bad actor.

>>abraco+(OP)
Then you would just un-vouch them? I don't see how its easy to game on that front.

>>DJBunn+r
> Indeed, it's relatively impossible without ties to real world identity.

I don't think that's true? The goal of vouch isn't to say "@linus_torvalds is Linus Torvalds" it's to say "@linus_torvalds is a legitimate contributor an not an AI slopper/spammer". It's not vouching for their real world identity, or that they're a good person, or that they'll never add malware to their repositories. It's just vouching for the most basic level of "when this person puts out a PR it's not AI slop".

>>abraco+(OP)
The usual way of solving this is to make the voucher responsible as well if any bad actor is banned. That adds a layer of stake in the game.

>>abraco+(OP)
At a technical level it's straightforward. Repo maintainers maintain their own vouch/denouncelists. Your maintainers are assumed to be good actors who can vouch for new contributors. If your maintainers aren't good actors, that's a whole other problem. From reading the docs, you can delegate vouching to newly vouched users, as well, but this isn't a requirement.

The problem is at the social level. People will not want to maintain their own vouch/denounce lists because they're lazy. Which means if this takes off, there will be centrally maintained vouchlists. Which, if you've been on the internet for any amount of time, you can instantly imagine will lead to the formation of cliques and vouchlist drama.

>>speps+t2
A practical example of this can be seen in lobsters invite system, where if too many of the invitee accounts post spam, the inviter is also banned.

>>dboon+L1
> The interesting failure mode isn’t just “one bad actor slips through”, it’s provenance: if you want to > “denounce the tree rooted at a bad actor”, you need to record where a vouch came from (maintainer X, > imported list Y, date, reason), otherwise revocation turns into manual whack-a-mole. > > Keeping the file format minimal is good, but I’d want at least optional provenance in the details field > (or a sidecar) so you can do bulk revocations and audits.

>>speps+t2
That's putting weight on the other end of the scale. Why would you want to stake your reputation on an internet stranger based on a few PRs?

>>supriy+Z6
I think this is the inevitable reality for future FOSS. Github will be degraded, but any real development will be moved behind closed doors and invite only walls.

>>bsimps+Ra
You are not supposed to vouch for strangers, system working as intended.

>>mjr00+p2
That’s not the point.

Point is: when @lt100, @lt101, … , @lt999 all vouch for something, it’s worthless.

>>DJBunn+Sh
But surely then a maintainer notices what has happened, and resolves the problem?

>>supriy+Z6
And another practical observation is that not many people have Lobsters account or even heard about it due to that (way less than people who heard about HN). Their "solution" is to make newcomers beg for invites in some chat. Guess what would a motivated malicious actor would do any times required and a regular internet user won't bother? Yeah, that.

>>hobofa+P1
Malicious "enabler" already in the circular vouch system would then vouch for new malicious accounts and then unvouch after those are accepted, hiding the connection. So then someone would need to manually monitor the logs for every state change of all vouch pairs. Fun :)

>>DJBunn+Sh
Real world identity isn't sufficient or necessary to solve that problem.