⚙️ How Aether works
This section gives a quick introduction to the architecture of Aether.
The basic overview
This is what you'd tell about Aether to your mom.
The first, first thing is that Aether is an app, not a website.
Why? Think of a website. When you type in www.example.com on your browser, your browser finds the computer example.com lives on, and connects to that. If you’re talking to someone over, let’s say, slack.com, what happens is that you send your message to there, and then Slack sends it to the person you are talking to.
So you have a server between you and the person you’re talking to. This is how the web works.
Aether doesn’t do that. If you’re posting on Aether, you’re publishing content directly on your device, and other devices connect to your device to get that content, and then they share that content forward. So there’s no central server involved. Everyone keeps a copy of the data, and when new posts are added, everyone gets the new post and passes it on.
Why does that matter, though? Being peer to peer is cool, but what actual problem does it solve?
Think of email. It works, regardless of whether your provider is, right? You have a Gmail, but you can send an email to a Yahoo email address.
This is only possible when there is no central entity controlling, owning email. Think of it, what would happen if email had a central, The Email Company company running it?
That company would have an incentive to not cooperate with other providers at all. They would be providing the Email service everybody uses, and they would think other third parties like Gmail and Yahoo were effectively free riding on the service they provide.
This is a little weird, isn’t it? The majority of the value Email provides is generated by its users, yet, The Email Company, just because it is a central server, can control which user talks to which user, and which user is not allowed to.
This is not so far fetched as you think. In fact, this is how the story of Twitter went down. So it’s not even really a hypothetical case after all.
So why aren’t there more open stuff like email?
Everyone who has to make money from software realised in the ‘90s that centralised services are a lot more monetisable than open services like email, and they were a lot easier to build.
That’s why there was no successor to email, half a century after its invention. It’s not for lack of trying.
- If you make it open: It makes no business sense to make something as open as email, because it’s impossible to make money off of it directly if it is so. (Or rather, it’s much harder to make money off of that than the alternatives)
- If closed: then no other company implements it (since they can be cut off at any time), it doesn’t get adopted, and people continue to use email.
How is this relevant to Aether?
Aether wants to be the email for mass communication. That’s why it has no servers: it gives no one the control that a central server affords. Control corrupts intentions, because control is monetisable.
Financially speaking, this is stupid. But considering that all the popular, centralised communication services are hell-bent on squeezing the last drops of dignity off this world of ours, somebody needs to do this.
Make no mistake, though, ideally speaking, Aether should be making enough money to pay a small team to keep it going. The best way to make anything last is to have that thing be making money, so this ensures that Aether will be there for the long term.
So, this is not about money being evil, it’s about setting the right incentives for everyone, so that the way to generate the most value for everybody is for us (people, communities, servers, networks) to collaborate. Aether having no central servers is the way that we set these incentives right.
The expert overview
The sections hereafter are intended for more technical / software people interested in the nitty-gritty.
Aether is a peer-to-peer flood network that propagates an entire copy of a text corpus, to all its participating nodes. From this corpus, on the nodes themselves, a content graph is incrementally compiled. This compilation happens under the end user’s control and it can be influenced by them.
The text corpus is a graph with six types of graph nodes, which define relations between users, content, and signals. This graph is pruned by a garbage collector in intervals, the collection algorithm is a mark-and-sweep based on time-to-last-interaction.
The nodes communicate with each other certain modifications (deltas) to the graph they each other have. Each node has the same (or near-same) source data (the text corpus), and syncing that corpus across machines is how changes in this content graph is propagated.
Example
Alice posts a Hello there! thread to the community called Sandbox.
Alice’s node creates a Thread entity that points to:
Sandboxboard- The
UserentityAlice
And adds it to its own text corpus. When a node next connects to Alice, this addition to the text corpus is shared with other computers, and those other computers will also share this change with others.
Every node that receive this change in the text corpus may decide to update the content graph it maintains, which is shown to the end user, based on the end user settings.
Every single interaction in Aether can be reduced to these change deltas in the text corpus, which can be efficiently compressed and distributed across the network on a flood basis.
Verification, Spam, Attacks, Fixed-storage-space problem
Every single corpus entity has a cryptographic signature, a fingerprint, and a proof of work.
Aether uses a modified Hashcash as the proof-of-work function. Every single modification to this text corpus requires a proof-of-work to be minted. Without this proof of work, the modifications are not accepted by peers.
Every single corpus entity is linked to other entities via graph vertices. These graph vertices terminate at root nodes, which are “genesis blocks”. There are two types of root nodes: the first are called ‘boards’, or in the end-user terms, communities. The second are user keys.
As a result, Aether can be described as a flood network that carries an arbitrary number of distributed ledgers.
Aether avoids the problem of requiring a potentially infinite amount of storage by incorporating a deletion logic that takes into account how much space the user allocates to Aether, and how long the user wants to keep content. When these limits are reached, Aether starts to delete the content starting from the oldest network interaction available.
Human-friendly usernames
- Usernames in Aether are not unique, due to
Zooko's triangle. However, there is a certificate authority that can issue unique names, in a similar fashion to domain name issuance. - This authority can be disabled, and multiple ones can be added.
Flood network
- Aether nodes connect in a fashion that creates neighbourhoods. These neighbourhoods are useful, because syncing with a new node from scratch is very expensive, while syncing with an existing node is very cheap. A neighbourhood is a group of pre-synced nodes, and it’s regularly turned over to allow for new nodes to enter, and for the oldest one to exit.
Distributed consensus
- Aether does not involve distributed consensus. It is an immutable network with no history state that requires a consensus to be achieved.
- The benefit of this tradeoff is that it removes the consensus overhead, Aether’s network is only limited in speed of intake by the total available bandwidth of all nodes in the network combined, since incorporating new data into the network does not go through the process of getting that data accepted into the network via a consensus protocol.
More information about network and graph
This is a 20 minute talk about Aether’s architecture from the founder of Aether, from Our Networks 2018 conference.
