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

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 6 hours ago | parent | prev | next [-]

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.

▲

supriyo-biswas 6 hours ago | parent | next [-]

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.

	▲	Yizahi an hour ago \| parent \| next [-]
		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.
	▲	iugtmkbdfil834 5 hours ago \| parent \| prev [-]
		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.

▲

bsimpson 5 hours ago | parent | prev [-]

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?

	▲	63stack 5 hours ago \| parent [-]
		You are not supposed to vouch for strangers, system working as intended.

▲

dboon 6 hours ago | parent | prev | next [-]

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.

	▲	anupamchugh 6 hours ago \| parent [-]
		> 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.

▲

DJBunnies 6 hours ago | parent | prev | next [-]

Indeed, it's relatively impossible without ties to real world identity.

▲

mjr00 6 hours ago | parent [-]

> 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".

▲

DJBunnies 4 hours ago | parent [-]

That’s not the point.

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

	▲	jen20 4 hours ago \| parent [-]
		But surely then a maintainer notices what has happened, and resolves the problem?

▲

hobofan 6 hours ago | parent | prev | next [-]

Then you would just un-vouch them? I don't see how its easy to game on that front.

	▲	Yizahi an hour ago \| parent [-]
		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 :)

▲

6 hours ago | parent | prev | next [-]

[deleted]

▲

smotched 6 hours ago | parent | prev [-]

you can't really build a perfect system, the goal would be to limit bad actors as much as possible.