Event Lists: An event list standard

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
  • 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.


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:


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! :pray:

1 Like

Looks awesome!
To solve the unique identifier problem, why not bring each event on-chain, we could create a simple interface for event organizers to add their event to the list, and in the process, they need to mint an NFT, and we can use it as the identifier, “so that each piece of the garden has something on-chain” :slight_smile: . Might seem a little over-engineered but could be fun and might open up other use cases.

1 Like