[RFC] Advanced Blockparty: a solution for overbooked meetups

[ethernian]

TLDR: If a Blockparty gets overbooked, candidates should be able to put a additional stake for other candidates, which means: “I stake 1eth for you because I will see you there”. Finally a meetup organizer invites those subset of all candidates with the most eth on stake.

Introduction
The maximal number of candidates for some Blockparty is limited. Extra applicants should go to wait list. It means, Blockparty creates a priority based on application time, which has nothing to do with meetup and the person. It is not that good.

I propose to extend the Blockparty by simple additional rule selecting participants (in case of overbooking) not by their application time but by some kind of “WantedBy” ranking. This improvement will allow more useful and focused events.
It will also allow to better split overbooked meetups by topics and interest groups into multiple ones.

How it works
Consider, we have a Blockparty with capacity of 6 participants (a medium table in a restaurant). Consider we have 12 candidates willing to come. Besides usual Blockparty staking, we allow any candidate to put 1eth on stake for some another candidate to express “I want you”. By doing this candidate increases recepient's “WantedBy” ranking, but owns the stake. After some time we will become a relationship graph, like this:

A will see C,D,E (and puts 3 eth on stake)
B -> D,F
C-> B,D,E
D -> (no preference)
…
L -> A,D

So, a subgraph with 6 nodes with most eths on stake gives us the set of candidates who fits the size of the event and are most interested to talk to each other.
An meetup organizer could select the next subgraph with 2nd biggest “WantedBy” stake (and reserve a second table in restaurant). And so on.

Old Blockparty rules apply here too. In particular if somebody doesn’t appear, he loses all his
stake.

[DISCLAIMER]: Work in progress. Some details are intentionally missed.

[makoto]

Hey, thank you for your input. It's an interesting attempt to solve overcrowdded event by adding more dimension rather than FIFS(First In First Served).

If I understand correctly, you are trying to order by popularity and people will vote because they want to meet these popular people.

Here are my thoughts.

1. How do you solve the problem of several friends trying to game by voting for only their friends? Even worse, you can just join as A, and also pretend as B,C,D,E which all points to A so that you are guaranteed to have a spot. If there are such backdoors, what's different to just auction spots by highest price (or just pick randomly).
2. Even if people act honestly, the popularity order is very disadvantageous against people who are new to the event. How do you make events more inclusive to newbies?
3. The biggest irony is that staking many people does not gurantee the spot of your own. Don't you get pissed if all the people who you voted for can get in but not you because no one else voted for you?

[ethernian]

1. I think a group of gaming friends will form a cluster on the graph. Identifying interest clustering is the goal of the proposal. Ideally, each cluster should make own event, focused on clustered interests.
   At the end it is an organizer's decision to pick this or that cluster for his event.
   I your example, I think, a cluster of gaming friends will become a friendly advice from the organizer to create an own event.

2. If you want newbies in the events, just reserve some tickets for them. All newbies are equal - it doesn't matter who will get the ticket and who not: you can just repeat the event for the new set of newbies.
   My proposal doesn't work well for promotional events, it works better for workgroup events. But anyway you could mix models.

3. [WORK in PROGRESS] It depends on how you calculate "WantedBy" weights. Two ways here:

   1. sum the votes from people inside the cluster only.
      If you have voted for many people in cluster, it will lose all the votes if you "get removed"
      OR
   2. sum the votes from all the candidates.

[makoto]

• Re 1, part of the purpose of coming to events are for networking. If group of friends are dominating the event and they only want to stick together, they should organise their own event imo.
• Re 2, having separate tier is a good idea but the tier is usually used for people who come more regularly so that it can use on chain history. Any new slots for newbies can be faked for generating new accounts.

Another important point, what kind of outcome are you expecting from the participants so that I can measure and track if the solution is in fact useful? If you are tracking participants happiness, not sure if this makes any difference as you just get + from people who got in and - from people who couldn't no matter what priority order you use (or in fact most people will be convinced that the timed order or randm is fairer than popularity contest ).

[ethernian]

If group of friends are dominating the event and they only want to stick together.

Exactly.

Any new slots for newbies can be faked for generating new accounts.

Well, is it a real problem? Let's call it "ordinary ticket" instead of "newbie ticket". Additionally to the "community ticket". Community ticked are distributed after "WantedBy" rating, Ordinary tickets are for anyone else and distributed by FIFS or by lotery.

To be honest, I have not thought about measuring yet. Possibly because currently there is no such measuring in FIFS too. I will write later if I'll get an idea.

[makoto]

Part of the reason you organise a meetup is for networking so not so sure if I want to encourage certain group of people who know each other to dominates my meetup. If they want to stick together, they should organise by themselves, not me. I'd rather prefer to priortize people who have been to my events before which is far easier to track.

Having said that, People have different opinions/preferences for registration process as well as deposit distribution process (giveth people prefer to donate to someone else rather than distributing among participants). Providing multiple ways to handle priority/deposit distributins and make it pluggable may be interesting so that event organiser can choose a way which he/she prefer (almost like Zeppelin crowdsale for meetups).

As a "default" option, I think it's easier/safer to stick to FIFS until we find a way to measure which way is more effective (we even have to start from defining what "effective" means).

[makoto]

The Gathering of Security community attendee list is in fact interesting ones to try your thought experiment. They got full quite quickly and the existing BlockParty logic (staking if you mean to come) is not so effective as most people will be attending ETHBerlin anyway (= highly likely to come).

https://docs.google.com/spreadsheets/d/1itaFDAXeCE5UP6nqciBYXPXiAsp36Mh4ewoCeLp7xX4/edit#gid=0

From the list I can see the followings

• Probably some participants are more well known (aka influencers) than the others.
• Some orgs (esp Consensys Dilligence and Trail of bits) have more participants than the others.
• The event organiser said they want to invite only relevant people but want to make the audience balanced.

You could experiment your idea partially by just creating a google form with list of questions you need for signaling and post it to the forum and see how people react. Of course there are no on chain staking effect but you can introduce some sort of constraints by restricting the number of votes (eg: only 3 votes per person) but you can at least be able to collect some data points.

Here are the list of questions I would include.

• Your name:
• Are you on the attendee list or on the waiting list?:
• Who do you want to meet in the meeting?:
• How much would you pay if a spot is in auction (and you are currently in the wait list):
• What logic do you prefer to get the spot (FIFS|random lottery|by popularity|auction price| anything else)?:
• How much ratio of newbie (or less known people) should be in this meeting 0-100%?

[ethernian]

The Gathering of Security community is probaby too late because the promise of particpation is already done, and wont be reverted.

There will be FEM Gathering in Prague just before devcon4. The even will be most probably overbooked. This could be good usecase. If you agree, we could talk to Boris Mann as the organizer

[makoto]

@dip239 sure we can give a try kickstarting the conversation that no guarantee that we can build the needed features on time (or we may not need smart contract for that).

[ethernian]

@makoto sorry for delayed answer. I could have a look at blockparty project and implement the functionality in my sparse time. I just need your general approval, that it make sense to try.

[makoto]

@dip239 no one needs permission to fork open source project as log as it honors the license policy (in this project MIT). Having said that if you are going to implement the logic you may want to speak to the ethmagician organisers if they are going to use it. Otherwise you will be wasting your time.