It has been a long time, but finally we can give you a proper Project Decorum update! This post will first discuss some differences between the old SAFE Network and the current Autonomi network that impacts Project Decorum’s design, and will then explain on how we adapt and what our development plans are.
No Native DNS
In older designs the SAFE Network had a native DNS, a “domain name system”. For Project Decorum, the main advantage of this DNS was that it was possible to give a piece of data on the network a deterministic and (more importantly for us) predictable address that anyone (or any app) can look up, without the prerequisite of a third party adding it to a managed index first.
Aside from looking up websites, other examples of a user directly using this would be looking up another user’s profile, or a subforum (like a subreddit) by simply knowing or trying its name. For Project Decorum we also wanted to use this on a protocol level, where for example the (potential) replies to a post would have predictable addresses that could be derived from the original post’s network address.
The important thing for us about a native DNS system is that it’d allow users that are completely unknown to each other to discover and interact with each others’ content without a third party being involved in any way. The new Autonomi design does not have a native DNS system, so the discovering of content is always facilitated by either out-of-band sharing (using for example a non-Autonomi messaging app or website) or by searching/crawling the Autonomi-hosted content of other users that you already know (someone’s managed DNS index you have chosen, your social graph, etc.).
Our goal has always been to have Project Decorum’s protocol rely on third parties as little as possible, but without native DNS it’s unavoidable that they’ll play a bigger role than we previously expected. This means that Project Decorum’s apps will work more similar to existing decentralized social media protocols, that typically rely on users to host their own servers or offer a plurality of third party services to choose from. While somewhat disappointing, we also realized this could be an advantage in terms of compatibility with other protocols, and started looking for any established players that would be a good match. And we think we found one!
Atproto
Atproto (short for AT Protocol, which stands for “Authenticated Transfer Protocol”) is a protocol developed by BlueSky for distributed social networking services. The most important features that align with Project Decorum’s goals are:
-
Custom feeds
Atproto puts control over the algorithm that creates your feed in the hands of of third party developers and users, a primary Project Decorum ideal. -
Collaborative moderation
Atproto supports subscribing to moderation services of your choice and to run your own, something that Project Decorum always planned to have. -
Lexicon
RDF (Resource Description Framework) has often been discussed on these forums by our community members. Atproto considered using it, but ended up developing something different called Lexicon. Lexicon is more suitable for enforcing schemas than RDF, which is especially important for compatibility and interoperability in decentralized networks. -
Account migration
Atproto supports migrating your account to different servers. This would allow users to migrate their existing accounts to or from Autonomi as desired. In this way we may be able to partially piggy-back on the network effect of atproto/BlueSky, and if things don’t work out with Autonomi or Project Decorum, users could transfer their account to a regular atproto host!
Development plans
Atproto is designed to run over the regular internet using direct client-server and server-server communication. We aim to make our atproto-compatible protocols run on Autonomi without such direct connections as much as possible, by having clients and servers upload their data to Autonomi to be fetched by others as needed. It should be possible to run your account on Autonomi and interact with other Autonomi users without running a server yourself or any direct connection the rest of the atproto ecosystem (called the Atmosphere).
We also aim to develop software that allows users and services to bridge Autonomi and the wider Atmosphere. Bridges that want to provide Autonomi users access to non-Autonomi content would typically reupload the relevant content to Autonomi and provide pointers to them, while bridges that want to provide access to Autonomi content to the rest of the Atmosphere would function more like typical servers.
Our initial focus will be on being able to run an atproto Personal Data Server (PDS) that stores all the atproto account data on Autonomi. Atproto uses a fairly complex specialized data structure called a Merkle Search Tree (MST) for account repositories. Storing it on Autonomi is not as easy as just uploading the local database, as we need to organize these MSTs in Autonomi data structures in such a way that granular access and updates are possible, while maximizing speeds and minimizing costs.
Atproto makes use of commit Event Streams from PDS and PDS aggregators (Firehoses) to notify the rest of the network when users create or change content. While we don’t want to rely on direct connections to follow these Event Streams, atproto also supports a backfill window, which we can change to upload the relevant data to Autonomi instead. These Events are typically structured as a “diff” between the old and the new account repository, and we’ll maintain a certain amount of the most recent at the same time. Implementing this would be the next step after the MST account repositories are present on Autonomi.
Afterwards, if nothing else pops up that we need to do first, we will start working on the Project Decorum AppView, which is the software that aggregates data from repositories and event streams, filters it and provides an UI to the user. We will likely take the BlueSky AppView as a starting point.
While BlueSky/atproto has been focusing on “micro-blogging” (public data) use cases so far, they have included support for privately shared data and end-to-end encrypted direct messaging in their 2025 roadmap. We will keep a close eye on these development and support them when we are able to.
Impossible Futures
We are excited about seeing what the Impossible Futures program will bring, but don’t think the program is a good match for Project Decorum.
The main value of participating in Impossible Futures for Project Decorum would be marketing, but I’d much rather start marketing after we have something working, not before. There is some risk that things don’t go well during the program, either with the network itself or with our current plans, and if people have voted and locked funds it could result in both unnecessary conflict and negative marketing value.
In addition, the Impossible Futures builder rewards can really help new projects that are short on funding, but for Project Decorum it wouldn’t really make the difference. So we’d much rather see other projects win this competition!
Lastly, since our goal is making existing atproto software run on Autonomi we won’t develop a typical proof of concept product first, going straight for integration instead which may not line up with the timeline of Impossible Futures.
So in short, we are generally positive about the program and believe it can be of great help for other projects, but it doesn’t align that well with Project Decorum’s current position and plans.
That concludes the update, if you have any questions please do ask!
