hiddentao
commented
8 years ago 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 :)
jefflau
makoto
@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:
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.