Conceiving The Gathering

February 2019, I attended my first developer convention, ETHDenver 2019. I was anxious and excited about meeting potential peers and others interested in building things I had dreamed about. The night before the hackathon, I went to a team building/speed dating event to help individuals find and build teams interested in hacking together. Near the end of the event, participants could share a one minute pitch describing what they wanted to build. Victor was one of the people that gave a pitch. He said that he wanted to build social games for the meatspace that made it easy and fun to get to know and connect with individuals at conferences like ETHDenver. While there were other exciting pitches, I ultimately decided that Victor’s project was the most aligned with my interest in empowering individuals to make meaningful connections. That was, in fact, my main reason for attending ETHDenver, and it stood to reason that creating a tool to foster those connections would further my goals and likely help others further theirs. At the end of the pitches, I approached Victor and we began discussing his idea. I was hooked, and for the rest of the conference we discussed how the social game would work.

Victor’s initial idea was a form of a tag tournament, with participants randomly assigned to find and connect with one another within limited time windows until a single champion remained. Yet as we spoke with one another and other hackers, the idea and its technical and social mechanics evolved. We had initially planned to have the game contact information stored on-chain, but several hours into architecting that model we realized that storing contact info on the blockchain was a terrible and unsafe thing to do.

So we decided to build something with a smaller blockchain footprint, something that we believed more closely reflected the social nature of the tool we’d be creating. We shrunk the role of the blockchain down to an incentive layer, with winners receiving ERC721 trophies that would digitally prove their achievement. The central utility of the game was actually a contact-swapping protocol that removed the inefficiencies that currently exist with sharing contact info with new connections in the meatspace. We wanted something simple, intuitive, fast and portable, meaning users could easily download their contacts’ info to existing address books. The users’ own contact info — which formed the main currency of the game — would be stored on users’ devices and shared only with those that they wished to connect with. The key innovations were to limit the game to a particular time and physical location, and also to allow and encourage users to make match recommendations among their connections, to enhance the chances that deep, meaningful connections are formed within a community. It occurred to us that no matter how excellently a community gathering was organized, there was always a great deal of lost potential from the connections that were not made but which would have been meaningful. Our goal was to build something that increased the likelihood that such deep connections were made, through leveraging common connections and incentivizing each member to make meaningful matches.

Having heard about IPFS and specifically LibP2P, we thought it would be great if individuals could operate and run the tool with no central organization involved. Ideally, someone could show up to an organized event like ETHDenver and even without official permission, they could launch a game and begin pulling others into it by inviting them to connect and participate. By using p2p technology, the game and all its data would exist only on the devices that were participating in it.

Once we had that kernel of an idea, we were lucky that ETHDenver had attracted a group of subject matter experts, and that they had thrown up a sign reading “IPFS Helpdesk” at their table. Andrew and Carson from Textile, Matt from Pinata and IPFS enthusiast Cody were super helpful in funneling our ideas into various implementation ideas. This communal spirit was infectious and ratified our enthusiasm for the promise of the distributed web. Such a large collective undertaking couldn’t work but for the growing number of people who believe it is worth building for its own sake, rather than as a path to riches or control.

We also continued to iterate over the game mechanics themselves, recognizing that our project could fail in two distinct ways. The first is obvious — failure by way of crappiness. If the game wasn’t fun, or wasn’t useful, or wasn’t unique, no one would play it. If the setup was cumbersome, slow or limited to a single platform like iOS, it’s networking purpose would be fatally undermined. If collected contact info were to remain siloed inside the game, it wouldn’t be nearly as useful or accessible — hence the VCF download feature.

But we were also concerned with a second form of failure that assumed the game worked well and became popular. We imagined scenarios where the incentivization element ran amok, causing players to make superficial connections solely to run up their score and thus defeating the central goal of our tool — to increase the likelihood of forming meaningful connections within a community of affinity. We also ran through a number of scenarios where highly regarded members of a community (using as examples Andreas Antonopolous , the keynote speaker at ETHDenver and Joe Lubin, founder of Consensys) might avoid joining due to spam-like targeting behavior from less prestigious attendees.

These discussions helped us refine the game design with the intent to encourage participation from all attendees while minimizing anything that would detract from the status quo experience. We wanted to avoid privacy compromises, abusability, cumbersome setup, opaque functionality, and being boring to use. We also vetted each game mechanic through what we started referring to as the “George Costanza test,” named for the easily offended and grudge-bearing Seinfeld character. For instance, we rejected a proposed feature that would allow members to send out “want to connect” messages, after imagining how George might react to someone ignoring one of his want to connect messages.

“How hard is it to just click ok, Jerry?! It takes one second!”
“Maybe he just hasn’t checked his phone recently?”
“I saw him check it Jerry! I saw him glance!”
“He glanced?”
“HE GLANCED!”

Our ideation process involved running each element of the game was through our gauntlet of possible negative outcomes. We also recognized the danger of overengineering against problems that might never manifest. We started labeling issues that exhibited this phenomenon “steakhouse problems,” named for the following apocryphal tale:

Centuries ago, a restauranteur conceived of the first steakhouse, and described what he envisioned to an architect. Concerned about the presence of sharp steak knives at each diner’s plate, the architect designed lockable iron cages that would surround each table, so that patrons could not go on a rampage and stab innocents at other tables. As it turned out, steakhouse patrons don’t actually attack one another just because they have sharp knives at hand, making the cages worse than useless.

These design discussions especially resonated with us in the modern digital media context: Facebook’s early “move fast and break things” mantra seems recklessly naive in refusing to spend time understanding how its tech could be abused. Yet the flipside to that perspective could result in the design of sterile, paternalistic tools that no one wants to use. Making these design choices was even more important in the context of decentralized, permissionless applications that are not capable of enforcing violations of norms or terms of service like a centralized app.

Running through all these considerations over three jam-packed days, we finally settled on the following game mechanics:

• Anyone can create a Gathering by setting the name, location and expiration time
• Others can join the Gathering by connecting with an existing member via QR code
• Name, organization and profile picture are publicly readable by other members of the Gathering, but contact details and affinities are encrypted for non-connected members
• Members connect by entering another member’s code name, which is unique to each Gathering
• Connections’ contact details may be downloaded to VCF format used by address books
• Trophies minted as ERC721 tokens on Ethereum serve as the incentivization mechanism
• The scoring system encourages matchmaking as such:
  Each direct connection earns one point
  Making a match recommendation earns one point
  Each match that is made earns the recommender another two points
• Trophies may be minted for most direct connections, most matches made and most total points
• Members also have three Stars that they may choose to send to their connections to signify that their conversation was one of the most meaningful exchanges during the Gathering — A separate trophy may be minted for the recipient of the most Stars

We’ve continued to make refinements to the game mechanics, but we’ve become convinced that the basic framework we settled on at ETHDenver strikes the right balance between incentivized gamification and avoidance of the pitfalls we addressed above.

Our pursuit to create a truly decentralized social game was ambitious and with our limited knowledge of IPFS, we quickly ran out of time before even becoming reasonably close to having a working proof-of-concept. Yet we left the conference love-struck with the technology involved, convinced that our new partnership had legs, and anxious to get the tool working and deployed at some future event.

We also had a name for the project — The Gathering.