As ENS stewards, we believe ENS has a central role to play in the future of a more decentralized internet, as a portable profile for every app that you access. But it’s not enough that you port your username or photo, but your content and social ties. To create a web3 version of Discord, for example, it’s not simply to create a copy of Discord using crypto as sign in, but it’s crucial to have interoperability: that the information you post on one app can be seen on others. Otherwise we’re just replicating the traditional information Silos on the web.
It’s not something any one app can build, in fact it’s a challenge that, by definition, must be done in coordination. Like a prisoner’s dilema, if one app tries to create an interoperable standard on their own but nobody follows them, they’re put in disadvantage: another stronger competitor can use it to syphon content out of them, and keep their own content isolated. But if the game becomes a Winner Takes All, then the end result is likely that we will all lose and the only winners will be the incumbent giants, which have already proven that their current user base is highly hostile at anything crypto-related. That’s why we can’t wait around for someone else to solve this problem, we need to slay the Moloch ourselves.
So ENS is announcing the first shared bounty for an interoperable API for self authenticated user action data. It will be given not to the first company to execute it, but for the first three independent apps that design the standard and implement it. This is important because it’s not about having just an idea on how your app is open, it needs to be something that works for multiple use cases.
The Bounty is currently at $60,000.00 (in either USDC or ENS) and it is being funded by both the Working Group and individual sponsors. It will be split in three equal shares for the three first independent apps that implement it in their own apps, allowing that all user generated content created in one app will also displayed and stored in other apps, based on an open standard.
The specification of the standards for the API should be written by those developers, working together. The bounty will be considered completed after there are at least three live apps, with real users, working with the standard successfully for two full weeks. If there are more than three apps that have implemented the standard, the working group will use the writing of the spec as the tie breaker, and can decide to award smaller bounties for the other runner ups. All bounty decisions will be up to the current ENS Public Good Working Group stewards.
<aside> 🏆 If you are interested in being a sponsor for this bounty to increase it, please contact @avsa on either twitter or the same handle on the email “at ethereum dot org”.
</aside>
What does self authenticated data even means? It’s user data whose authenticity does not depend on the trust of the server hosting it, but that carries with itself all the required proof. This allows the data to be ported among multiple hosts and served from unknown locations, and yet still be trusted.
One early case of success of standardization of content separated from source was RSS, which allowed users to read and gather their friend’s blogs in one single reader. When reading a post, you could trust it had come from a site you wanted because your reader had gotten it directly from their domain. When social media took over blogs, your twitter client didn’t need to ping multiple sources, but just a single source of truth, which was the twitter API. You knew that tweet was written by a twitter user called @avsa because you were reading it directly from the twitter API. In order to bring content from another platform you had to either use an official embed from the other source (which often added lags) or the just copy paste/screenshot the content directly and lose any attribution. This helps proliferate false information on social media.
A self authenticated data provider would have an API endpoint (like an RSS feed) containing users action, but, unlike a traditional RSS, it doesn’t need to contain only data that was generated on its own site. In fact, providers are encouraged to connect to other providers to download and filter the information they are interested and then providing that as a single end point API for the end user. This way the user’s experience is connecting to a single API (like in social media) but the data can be self verified on the client instead of having to trust the provider.
This document does NOT specify the standard, but rather the requirements that the apps must adhere to when using or writing a standard.