blockparty
blockparty copied to clipboard
makoto
Ideas: socials app + p2p proof of presence
@jefflau @makoto
Jeff and I were once working on an idea called Socials, which was sort of a cross between Meetup and Twitter. People could setup ad-hoc events which other people could then join. Once joined people could share info in the chatroom. All SoLoMo :p Regular event organizers could setup a "club" which would have members, etc. etc.
Anyway, I was thinking that block party could be extended a little with a similar idea. A mobile app which allows for ad-hoc event/meet setup. Two types of events:
- Free ones
- Paid ones
Only the paid ones need to utilise the blockparty blockchain stuff. Basically, in order to attend a paid event the user would need to pay some "tokens". If they don't have any tokens they would have to purchase them via an in-app payment (Play store, App store).
When the user first purchases tokens they would actually be creating an Ethereum account and purchasing Ether, which would then get sent to some contract we have that then issues them tokens. We can use uPort or some similar identity mechanism for storing and handling keys.
Once they have tokens, they would "purchase" entry to the event with X number of tokens as specified by the event. Purchasing would involve invoking the blockparty contract. From this point onwards everything works as normally does in blockparty, and the user gets a split of the eventual token pot.
Users will be able to gift other users tokens. As for selling, will have to think about that.
One key point is that users don't even need to know that the whole thing runs on Ethereum, that's just for us in the backend.
There's nothing like this out there - meetup.com doesn't give you a payout from a central pot and their mobile app doesn't allow for ad-hoc setups in the way I'm thinking of.
Now on to proof of presence and how that can be made to work well...
So event organizer acts as "trusted verifier". In order to prove my attendance both I and the event organizer must be running our app on our phones and come within certain distance of each other. When the phones are within certain distance we may be able to use Bluetooth scanning or some similar mechanism to passively prove presence - I prefer passive to active (e.g. manually syncing QR codes) as otherwise it's an annoyance. But if has to be active then must be made as simple as possible.
If using GPS to prove presence then I opt for 100m rather than something smaller because an event could be meeting at a festival/park/etc that constitutes a large area. Moreover GPS may be slightly off, so again you need some slack. I think 100m is reasonable. Obviously, if we use something like Bluetooth to prove presence you'd actually need to be within 10m or so anyway. Perhaps a stack of methods in priority order can be used, e.g. try Bluetooth first, followed by GPS, etc.
Now here's the cool part. If I have proof of presence then the next person who attends only needs to come near my phone to get proof of presence. So it's kind of a p2p proof of presence. Of course, they can still go near the event organizer's phone to again get proof of presence. If you iterate forward, as more people attend, it becomes marginally easier for the next attendee to prove presence, which means this method scales up really well.
Further notes:
- Nice thing about using tokens rather than Ether is that giving a user tokens is simply a matter of calling into a contract. And so we can give them a fixed price that's disconnected from Ether price. E.g. £1 = 100 tokens
- All users get normal web accounts. If they want to attend a paid event only then do we need to create an Ethereum key-pair for them. And we can store this key-pair in the backend against their web account (client-side encryption, zero-knowledge authentication, of course). This is nice because it means we don't even need to use uPort since they have a normal web account which can be used to recover their Ethereum data at any point. And it's still secure :)
Regarding event payments...
Paid events have a running cost. Thus, you can't get all your tokens back since some are required to cover the cost of running. So really the pitch is that people who don't show up forfeit their payment and that that payment comes back to you.
The payout per user should be proportional to the no. of tokens they paid in. If I pay in twice as many tokens as Jeff I should get double his payout, for whatever payout eventually happens. This would be an interesting dynamic - would people often choose to pay more than the asking price in order to get a larger payout? Very interesting. At this point it's almost like a betting game. The larger you pay in, the more likely you think it is that some people won't actually turn up.
Effectively, you could end up with a class of people who simply want to win money through betting, and don't actually care about the event. E.g. I would try to pick and choose the events where I'm most likely to make money by virtue of many people not showing up. But if other people are also picking and choosing such events, then in the end such events would likely have a good turnout - is this true? does the system become self-balancing like this?
If you free event doesn't require blockchain access then how do you guarantee people are going to come? I think the original vision (and MVP) for Blockparty is that it creates incentive to show up for an event. If no one is paying a deposit, there's nothing to lose or share (to those that do come).
I was also thinking about paid events could just be deposit + ticket cost. So for instance we could have a paid event that involves us going to a club, the ticket costs £20, but you pay £25 and the additional deposit gets refunded on proof of attendence/presence.
@jefflau @hiddentao thanks for the input. I was away for holiday for a while.
proof of presence
If I have proof of presence then the next person who attends only needs to come near my phone to get proof of presence.
I thought something similar of letting people to link to each other until everybody (or more than 50%) gets connected but that cannot still prevent fake participation remotely so your idea of linking to organizer is better. It's a "People chain"!
token as participation
I actually briefly thought about it before and discarded for the 2 reasons.
- How do you additional info such as twitter account when all the action users take is to purchase the token?
- If people only interact via token, can they still invoke function of Dapp (eg:
withdraw function)?
These concerns may go away if we can completely hide Ethereum from users, but it still expose Participating via Token is lowers barrier to entry but if the users are not equipped how to interact with contract, that
I wasn't big fan of how DAO made participation so easy by just buying a token but that made difficult for normal users to withdraw Ether because they had no clue how to interact with DAO.
It would be super great if hiding Ethereum can solve these issues.
Free vs Paid
I think our USP is for Free event. If organiser wants to charge, they can just use EventBrite. I like the idea of organising the party on the spot from mobile (like we were sort of doing via WeChat while we were in Shanghai) but that can be done without Blockchain. Paid event integration can be done in the future but probably lower priority.
About the mobile event management, it sounds similar to this http://techcitynews.com/2016/10/16/qa-louise-doherty-of-plansnap-on-being-accepted-onto-techstars-and-using-sport-to-combat-startup-craziness/ . The company apparently got some sponsorship deal without writing single line of code, meaning they have nothing :-)
Some good thoughts there. I like the "people chain" term. I'm even thinking that that "proof-of-presence" functionality itself could be refactored out as a separate commercial service.
PlanSnap has a decent enough name. They're looking for a CTO - https://www.f6s.com/plansnap. "I love her business idea mainly for solving a real social issue - frictionless planning with friends - in a revolutionary way"
Yes, proof-of-presence has a wider application so best to be decoupled from blockparty. Happy to integrate if you made one :-)