11/05/2019 – Stefan Adolf
Within hours a dedicated Discord channel went wild with around one thousand more or less experienced hackers, many of them seemingly skilled in frontend matters. Only a day later their github repo opened up and the discussion was piped into an endless stream of feature requests. Everybody seemed to have a good idea of how the organization of local community events could be improved. Everybody wanted to be aboard when the whole world starts to establish an open source meetup community platform. The first thing to see on the README was a relational diagram depicting the relations between users, organizers, venues and events — and it was no coincidence that it looked similar to the concepts that we knew so far as: meetup.com.
The FreeCodeCamp “chapter” repo takes it one step further, though. They absolutely recognized that a centralized platform will sooner or later end up with similar issues as our federated friends, so they want to distribute the moving parts on as many shoulders as possible. Local communities would run their own nodes and install the containerized chapter software on them.
The only centralized part in the system — as the time of writing — would be a discovery service making it possible for new users to find their local community’s hub nodes. A splendid idea. But you’d still need encouraged locals who are willing to take action and install and maintain a running chapter node (which obviously doesn’t come for free) and tell everybody to create accounts on them.
This kind of distributed linked network is not brand new: Mastodon and Matrix (the backbone of Riot.im) are quite successfully building Twitter and Telegram replacements. Kazaa and Diaspora were showing early that P2P controlled filesystems and social networks, operated by globally distributed peer nodes had the perspective to break the restrictions of centralization.
But do you really want to build software using relational databases and machine based application hosting in the year 2020? SQL dates back to 1974, and in the days of serverless functions, running a server also leaves the bad feeling of working with zombie technology here.
Interacting with a smart contract in a state-changing way doesn’t come for free. Miners who execute the contracts’ code must run CPU cycles to execute the compiled bytecode. Ethereum therefore introduces the concept of “gas” to represent fees that are spent on every code execution step. Depending on the operation’s complexity an Ethereum client estimates an amount of gas that’s needed for the computation. At the time of execution a miner translates the gas value to “real” Ethers and expects it to have been sent along with the contract invoking transaction — if the sent funds aren’t sufficient, miners will reject the transaction. Every user who wants to interact with any smart contract in writing direction must therefore pass an appropriate amount of gas with the call.
Smart contracts are unstoppable and enable the authoring of so called decentralized apps (or short Đapps). From a very simplified practical point of view they’re frontend heavy applications that use the Ethereum ledger as event source and database.
The final eye-opener
What we definitely learned: either you go decentralized or you don’t. Having any centralized part in the whole system would break any other. With that in mind I attended Đappcon in August 2019.
A three day event that completely concentrated on the latest developments in the Ethereum world and it was no disappointment. Hundreds of international guests came to my hometown and I suddenly felt very understood — I noticed that we have not been on some esoteric path on a mysterious alien tech stack, but rather didn’t listen well enough to what so many of Đappcon’s attendees already understood: the Web2.0 as we know it is dead, the future already has begun years ago. Writing smart contacts in a way we were doing could already be considered old school. Decentralized Autonomous Organizations are already (more or less) taking over our understanding of incorporated and limited companies as we know it. I’ve met digital nomads that make a living out of building Ethereum apps and they get paid in Ethereum and Dai (an Ethereum backed Stablecoin oriented on USD). That was my personal turning point: **I had to make this kite fly and I had to find a team for it**.
That’s a more or less working contract to anchor new events and their attendee list on the ledger. What’s missing is the discovery part (show me events nearby ‘Berlin’). For this we had to dig slightly deeper into the box of secrets:
Being configured like this, The Graph will setup services that listen on MeetupCreated or MeetupRSVPee events of the Contract contract and feed all that data into a hosted database (which actually uses Postgresql under the hood) with an automatically generated GraphQL API layer on top of it. The frontend can simply ask for deep graph data, e.g. to filter upcoming events with specific tags in a certain city.
Our final Devpost submission for “Team Meeting” can be found here. Currently the code is still in hackathon state but works more or less as explained above.
Consolidation & Conclusion
What we were building and what we’re about to build
All the code and facts that you’ve seen above are the result of three weekends without sleep, achieved by around 10 people who never have met before in their lives. So please bear with us: this is not a working piece of software yet.
At the time of writing we’re in the middle of figuring out how we continue this project. We most likely stay on the Ethereum chain, even though there’s a lively discussion going on whether Parity / Substrate, NEAR, elastic Eth Sidechains or Eth2.0 / Serenity are the stacks to wait for or build on. Personally I’d happily stay with the proven Ethereum stack and embrace MetaMask as “identity” wallet and mandatory dependency for interactions.
We will surely invest some energy in the event detection / storage / discovery part of the whole story since this is what the most owned, federated and siloed part of the current meetup/event ecosystem is. The people behind our ĐOor idea want to take it a step further and add more close-to-event features (e.g. Kickback-like RSVP deposits that will be transferred back to their origin as the proof of attendance had taken place) whereas Team Meeting prefers to decouple functionality as much as possible to just help with the plain chain anchored event data base.
If you want to be part of the discussion or would like to dig through or contribute to our code or you want to fork it and build your own new meetup.com: go ahead, the way is free for you — here’s our “ ĐOor” organization that currently maintains both our ĐOor and Team Meeting repos: github.com/d0or . If you’d like to support or integrate us in any way, don’t by shy and contact us.