People Parties - Community Proposal

[bjoern]

Hello everyone! Here’s the two-pager as promised. We really appreciate your feedback!

Virtual people parties on the Internet Computer

Goal

Determining whether supposed users are actual human beings benefits the Internet Computer ecosystem in multiple ways: For instance, social media platforms provide more meaningful interactions if the content is provided by real humans, decentralized governance processes benefit from power being distributed more evenly across many voters, and the bootstrapping of token economies becomes fairer if tokens can be distributed evenly to individuals.

Virtual people parties establish the personhood of otherwise pseudonymous identities. In a virtual people party, a small group of users validates each others’ personhood in a process that is fast, easy, and anonymous! Validated users may then achieve benefits such as increased voting power in the governance system or additional capabilities in social media dapps.

Concept

Each people party event takes place at one specific point in time; there will be different events for users in different time zones. Users register for a people party by committing to a specific location that they will visit during the duration of the party. When the party begins, the people party dapp assigns all users into groups of 6 people each, and creates a shared video session for each group, as well as a random pseudonym for each user. In each session, the participants have to prove that they are at the location they committed to. The following process is performed for each user, one by one: One user (the “prover”) shows the video captured with their phone’s main camera (i.e., they never show their face, only their surroundings) and reacts to requests from other users (the “verifiers”). The verifiers approve or deny validation depending on whether they are convinced that the prover showed them a live view of the committed location.

To ensure that one user can only participate in one group, it is required that each user must join from a distinct location. To disincentivize bots from registering with the people party canister, each user must deposit 1 ICP for the duration of the party; this deposit can be withdrawn after the party is over and if the user does not want to participate in subsequent events.

Benefits

People parties and validated personhood benefits different parts of the IC ecosystem:

• Validated users receive increased voting power and thereby increased voting rewards. Dapps running on the IC, such as social network platforms, may provide extended capabilities to accounts held by validated users.
• Dapps on the IC can differentiate between humans and (potential) bots, enabling them to prioritize content created by real humans over bots.
• Decentralization is improved by providing additional voting power to validated persons, compared with a purely stake-based distribution. Allowing validated persons to act as pseudonymous node providers will also improve decentralization on the infrastructure layer.

Implementation

The core component is the “people party” canister smart contract that coordinates the people parties and tracks the results. The canister allows users to register for a given party while committing to a location (ensuring that the locations of different users are sufficiently far apart) and to join a group for the party they registered for (ensuring a random assignment of users to groups). The canister orchestrates the calls, determining the order in which the users validate each other’s claims, and counts the votes. The canister keeps track of which users have been validated successfully, and allows the user to share the information about the successful validation with other dapps. The canister also informs the NNS about the neurons that are supposed to be boosted.

The frontend of the people party dapp is served by the canister into the user’s web browser. It uses WebRTC to transmit the video between the client devices.

As most users will be on mobile networks, STUN and TURN servers will be needed to relay traffic. Those servers will initially be hosted by the DFINITY Foundation, but note that they do not need to be trusted as all traffic routed through them is end-to-end encrypted in WebRTC.

Risks and mitigation

There are multiple risks associated with the people party concept.

• Registration by bots: As long as not too many bots are registered, those will end up in validation calls with real users. At least in the beginning, we consider it unlikely that bots will successfully masquerade as an actual person; of course, we will have to improve the validation process over time for this to remain true. So those bots will not be validated. Registering many bots is disincentivized by the ICP deposit; this can even be made more effective by potentially slashing a fraction in the case the validation of a user failed. The risk of being attacked by bots will have to be re-evaluated over time.
• Insufficient participation: If too few real users participate, the people party system will not provide the expected benefit in improving decentralization of the IC, and low participation will also make it easier for bots to undermine the system. To mitigate this risk, we have to advertise the concept to an as-large-as-possible user base, and incentivize continuous involvement by providing sufficient rewards (such as the voting power boost).
• Inappropriate content shown in video by malicious users: This is hard to prevent entirely, since the video streams are sent end-to-end encrypted between end devices. The prover’s streaming will stop after sufficiently many verifiers have voted. If this turns out to be a problem, we can provide a button to quickly hide a video that shows inappropriate content.

[lastmjs]

How will users prove to others’ their location? Is that up to each of the individuals in the people party?

For example, if I live in San Francisco, should I point my camera at a known landmark? I suppose that would do it. But what if I live in an obscure place with no notable landmarks or buildings? And being too specific with the location would remove anonymity.

[nomeata]

This somehow evokes fond memories of the GPG key signing parties of the 2000nds:

[bjoern]

I get it that NNS and Ledger, etc. are essential to the functioning of IC. But People Parties seems like it could be built by anybody in the community? Am I missing the point? Is there any essential feature here that cannot be tackled by the community?

Indeed, it could. And granted: ideally, it should. There are some aspects where it isn’t just a usual dapp – namely where it starts interacting with the NNS the neuron boosting and – hopefully – for allowing pseudonymous but personhood-validated node providers; namely, where the people parties are improving decentralization of the IC itself. But even that should eventually not be sacred ground – when the entire codebase has become truly open source.

Or maybe I shouldn’t be worried, because so far only II is a semi-good quality app, and all the others are disappointing to say the least.

Rest assured that we are aware of the deficiencies. And that we attempt to build the system in a modular way so that the community can build better tools: a better II, a better NNS UI, …

[bjoern]

@lastmjs

How will users prove to others’ their location? Is that up to each of the individuals in the people party?

In our current development version we provide the verifiers with the video on top and a street view on the bottom of the screen. (And we only allow registrations where street view is available.)

[weedpatch2]

I think your solution is a good temporary solution, however that does not prevent malicious actors from putting offensive content on the video stream to simply shock the other users. I think this is a great draft idea! I can’t wait to see how it turns out!

[lastmjs]

A simple “hide video feed” would hopefully work out well

[nomeata]

@weedpatch2

however that does not prevent malicious actors from putting offensive content on the video stream to simply shock the other users

You mean, like a Cardano ad maybe?

[lastmjs]

Interesting.

Could you also grab location information from the IP address metadata shared through WebRTC?

[lastmjs]

By the way, I’ve been digging into the design with @bob11, and we’re feeling pretty good about it. It won’t be 100% perfect, but I think it will massively cut down on bot activity.

[rubenhorne]

I think that’s a really clever idea to use Google street view with a live video feed from a prover as proof of their humanity.

We will need to choose locations wisely because who knows if it will be inclement weather on the day in question. It will be interesting to see if extreme weather or other dangerous circumstances (tornadoes, hurricanes, flooding, unrest, etc.) end up disrupting your ability to be at a location. It would be smart to allow users to select their location close enough to the day that they could have an approximate weather forecast.

If people really want two verifications, they could still do it by setting up on either side of a time zone border and being in one party on the east side and then jump west a bit and be in another one an hour later. But that’s the trade off and it doesn’t seem like a bad one to make.

Three questions:

1. with the parties divided into time zones, is there a set party time and date being proposed too, or do that time zone’s users vote on it? Could be a non-trivial concern in the case of inflexible schedules.
2. what is the mechanism by which location conflict is resolved and how close is too close?
3. what is on the list of “allowable” requests? It seems like requesting the prover to show themselves to the camera isn’t allowed, but, for example, is asking the prover to say something out loud off limits?

Overall great design though and let’s stop those bots!

[bjoern]

@lastmjs

Could you also grab location information from the IP address metadata shared through WebRTC?

Good question, but realistically most of the connections will be going through a TURN relay – it seems on most mobile networks direct point-to-point connection between the devices are not properly supported. And that probably (although I would have to check) means that the SDP data contains the IP address of the TURN relay not the one of the end device.

[bjoern]

@rubenhorne

1. with the parties divided into time zones, is there a set party time and date being proposed too, or do that time zone’s users vote on it? Could be a non-trivial concern in the case of inflexible schedules.

In the current design: only indirectly by voting on the deployment of the people party canister. (We plan to make that controlled through the NNS, because ultimately the NNS depends on that canister for correctness of the neuron boosting.) But this is really only the first instance. We may have a more flexible mechanism in the future.

2. what is the mechanism by which location conflict is resolved and how close is too close?

First come first serve – but that’s during the registration phase, so if you register half an hour in advance that will give you ample time to go to a suitable location. We did not define the exact threshold for “too close” yet. We were thinking about something like a few hundred meters.

3. what is on the list of “allowable” requests? It seems like requesting the prover to show themselves to the camera isn’t allowed, but, for example, is asking the prover to say something out loud off limits?

That is a great question and also one that we love to get more opinions on. So far we’ve been planning for the verifiers to anyway ask the prover to do X or Y, so we’re not really planning to hide the voice. But I expect usual requests to be of the type “move left” or “show me the street sign” or “can you move the camera upward”. But as I said: it would be great to get your ideas on what should be acceptable and how much we need to protect for privacy. (In the end, that seems to be subjective.)

[rubenhorne]

As far as gaming the system goes, I think one big threat that I can see right now is that some time zones have very low populations such as the middle of the Atlantic and Pacific Oceans (see this map). Someone could take any number of bots and put them in GMT-2:00 or GMT-11:00 and probably take over those people parties. Perhaps we say your time zone needs to have at least 1 or 5 million people or it gets combined with neighboring ones, just to make sure enough real people will be there at the people parties.

[weedpatch2]

Yes, exactly like this!

But, additionally, there could be a slash mechanic, by which unvalidated partiers lose part of their 1 ICP stake. Disincentivizing any actions other than the intended partying.

[northman]

1 ICP for a large portion of the world is a large sum of money that is out of reach for many.

[coin_master]

I think 1 ICP is reasonable since first they will get it refunded and second how can they boost their voting rewards if they don’t have the minimum to spawn a neuron?
I am in favor of slashing since this will also minimize the bots overall.
A question I have regarding the public API that this canister will offer to other dapps to query, is it already defined? Or do we have a rough idea how it would look like?

[Saj_ICP]

How many ICPs can be staked in a boosted neuron?

Is there any upper cap?

[nomeata]

I assume there will be multiple instances of these people parties, right, and someone eager can take part in multiple installments, so in total earnings multiple “proofs of peoplehood”?

And once your principal is known to be peoplehoody, it could (in theory) be traded and accumulated, right?

So its more a proof of “past human effort” than “this principal right now is a district human”?

[bjoern]

@rubenhorne

Perhaps we say your time zone needs to have at least 1 or 5 million people or it gets combined with neighboring ones, just to make sure enough real people will be there at the people parties.

I think we will start with fewer groups – maybe one for Americas, one for EMEA, one for Asia and Pacific. But yes, we have to ensure that we have sufficient real people in the calls.