In a previous post I mentioned an Ethereum event database that I would like to create (chronicle). This event list will be curated so gatekept by default, as we will maintain it. However, I don’t want to create just another centralized database. Though it will be all open-source, which is great, but maybe it needs some more systemic solution for better composability…
Event Lists
That’s why I want to introduce something I’m calling Event Lists. It’s supposed to be an open standard (or specification) for creating lists of events and their details. That means - anyone will be able to use this standard, and create their own list of events. So our EEG Ethereum event list will be just one of many.
Gatekeeping is dead and EEG is definitely not meant to be the sole curator. That’s why Event Lists can be a pretty good way to achieve inclusivity and decentralization. Any community or subcommunity, or even an individual, will be able to publish the list or their events contained in it.
Different types (and scopes) of lists:
- a comprehensive list of all events in one industry, e.g. Ethereum event list
- list of own events - communities, companies or projects can make their list, just with their own events, e.g. EEG Events like meetups, or ETHGlobal events
- group of events, such as Devconnect or Prague Blockchain Week
- a single event - even a single event will be able to publish its own list (for aggregation)
- private event list
Use cases
This common standard will be our foundation on which we can build various tools that can be used by all those who implement the standard:
- clients for browsing of events
- universal - aggregating multiple lists into one interface (like cryptoevents.xyz)
- specialized - interface dedicated to one event sector (like ethevents.xyz)
- embedded - embedding the list of events directly into the website (like Ethereum.org Events list)
- clients generating various statistics and metrics
- potential integration in clients of social networks
This standard will not only be useful for Ethereum or cryptocurrency events, but for all types of events.
Example 1: List of events on Ethereum.org
On Ethereum.org in the Community section you can find a list of Ethereum events. That’s great, but this list is maintained by the Ethereum.org team, who handle all the extensive documentation, so there’s a long wait for PR about adding more events or editing them (or you have to have someone in EF to go through it for you).
Event Lists are a great solution for Ethereum.org - because they will only need to implement this standard, and they can leave the listing and curation of events to EEG and other trusted sources. It doesn’t have to be fixed to one data provider, but there can be multiple providers and they can change over time as needed.
Technology
From a technological point of view, the event list will be a single JSON file that can be hosted on:
- distributed/decentralized file storage - IPFS/Arweave/Swarm etc.
- decentralized/federative social protocol - Matrix/Nostr/Bluesky etc.
- centralized web2 hosting (https://)
The specification of the JSON file structure would be written using the JSON Schema standard.
Inspiration: Token Lists
Whole idea it’s heavily inspired by Uniswap’s Token Lists, which focuses on token listing for dApps. In terms of curation, it’s a very similar thing, whether it’s tokens or events.
I recommend anyone interested to read their article Introducing Token Lists, where the advantages of this solution are nicely described.
Potential issues
Schema complexity and grow
Compared to Token Lists, the basis of which is really simple, just a few properties, here we need handle a lot more properties. The schema should be basically future-proof, i.e. only backward-compatible changes should be made, but still it will probably be a good idea to introduce major versioning.
It will probably take much longer to stabilize the scheme, because I believe there is a lot of information to collect. In any case, it is best to keep the basic schema as simple as possible and add any extra data using some form of “extensions” (?).
No unique event IDs
In the case of tokens, it’s simple - each can be uniquely identified by its smart-contact address. For events, there is no universal identifier, it is a combination of location, name, time and other details. That can be a big problem when merging the same events together from different lists.
It would be great to have a DID for each event, but this is unrealistic because it would mean that the organizers would have to create the DID themselves. We want to be able to add an event organized by someone else to the list.
Proof of concept
I’m experimenting with this on GitHub, I’ve created a repository of event-lists:
Conclusion
The whole idea is still in its early stages. We need to talk more about it. For now, it seems like the best way to go, but maybe some of you will have a different opinion.
What do you think of this standard? Does it seem like a good idea to you? Do you see any major problems or obstacles?
I would be glad for any comments or ideas! 
. Might seem a little over-engineered but could be fun and might open up other use cases.