People Parties - Community Proposal

Am I the only one that gets worried every time the foundation steps into app building? 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?

I don’t mean to sabotage this effort, but it can be seen as platform risk, not unlike what Microsoft/Apple/Google/Facebook/… does.

2 Likes

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. If it turns out to be another nns.ic0.app, the community probably will just have a good laugh and move on.

2 Likes

The virtual people parties have some perks over in-person people parties. Virtual is a lot more accessible. Anyone can join, even if they are geographically isolated from other internet computer users or even if they are at a work or with family or at another commitment (just take a few minutes break at the time of the meeting). One of my questions is what radius will be used on the location sensor? I can imagine that in densely populated areas that if two+ people tried to verify who lived in the same high rise, they could both be disqualified. Maybe for now we could assume people are few enough and distributed enough, but as the internet computer gets more users over the years, the user location overlap could become an issue. Maybe at the party time those users just have to go to a less dense area? I don’t think this location uniqueness requirement is a bad trade-off for now, but it is one that the proposed model makes.

One problem that I think gets addressed well with the proposed format is duplication. I think what @lastmjs is asking about is what stops a person from making 100 different accounts (via 100 ICP) and overloading their people party? I think this question assumes a local people party. But the advantage of the virtual method is that we have a (I assume) geographically randomly distributed people party since all of them happen at the same time. So a bad actor would have to have many of their bots picked out of a pool of all internet computer users into the same random group. The odds are just so poor that I don’t think it’s worth it.

The other logistical trade is the universal time. For 1/3 of the world’s time zones, the party will occur during obscure times when they would normally be asleep. It’s a price we pay, but it might be a nice gesture to cycle the time of the party through time zones.

I’m also curious about the setup of not showing your face in the party. Is this to help against any sort of discrimination? Protect privacy? What if instead you have to just mimic various finger movements and/or foottaps or in extreme disability cases face movements. You could still preserve privacy while proving a bit more explicitly your humanity. I think the possible concern now would be that a bot maker could still manipulate the phone using a setup of motors controlled remotely while listening remotely to the instructions for many bots in many locations. This hack wouldn’t be trivial though, so this proposal is not a bad workaround for now.

3 Likes

Groups may eventually need to be organized by language (not just English default), but we would need to ensure a large enough user pool to assure that you couldn’t game the system with a flood of bots in a poorly represented language.

2 Likes

I’m also curious to know the location check mechanism. If the video app is web app, hacking that location check I believe is trivial. I can simply set a breakpoint on the frontend and change the coordinates before sending them to the canister or to another user.

If an Android or iOS app is used, I think hacking the location check is more complicated, but still doable, especially if the source code to the application is available, easily allowing users to install locally modified binaries.

The only solution I see, which is still subject to side-channel attacks, is a secure hardware module that can sign location information generated from within the module. To my knowledge retail electronics do not have these types of modules in most phones or desktops/laptops.

4 Likes

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.
8 Likes

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.

4 Likes

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

9 Likes

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.

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, …

2 Likes

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

2 Likes

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!

1 Like

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

You mean, like a Cardano ad maybe?

7 Likes

Interesting.

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

1 Like

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.

7 Likes

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!

5 Likes

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.

3 Likes

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.

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.

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

7 Likes

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.

6 Likes

Yes, exactly like this! :smiley:

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.

4 Likes