Aether News & Updates - March 2018
Hey folks! Since the past month we’ve been working on Aether full time. Here’s what happened, what’s coming and what our tentative release date will be for Aether 2. But first, an intermission of sorts…
What the heck is Aether?
If you haven’t been following it yet, Aether is an app that gives you community moderated, community governed[1] public spaces, similar to subreddits. You subscribe to the topics you’re interested in, and it gives you back interesting links and discussion around those. Major difference compared to Reddit, though, is that Aether is transparent, auditable and extremely privacy-oriented[2], all the while it attemps to be a more pleasant place hospitable for civilised discussion amongst peers. Aether’s boards are owned by nobody, and they live in nowhere,[3] thus they cannot be censored (but can be reversibly hidden). It also gives you ability to host free websites in this distributed network.
It is not a social network, though. Or, rather, it’s an antisocial network — we attempt to be a place expressly made for following and discussing things you’re interested in, not for meaningless chatter of your third cousin’s husband’s new car stereo.
Spiritually, Aether strives to be the mass communication equivalent of email. Similar to email, app and the the core protocol underneath is open source, and no permission is needed to implement third party clients.[4] If you’re familiar with it, Aether is functionally quite similar to Usenet of days of yore, brought to 21st century. If not, think Reddit, but open, more sane, smarter, gentler, more transparent.
What’s the overall status?
We’re currently building the sync product underneath Aether to be as extensible as possible. For the consumer-ready app, the estimated arrival is about three months of work, so a tentative launch date would be June 2018. If you’d like to keep in touch with the updates and for launch invite, you can subscribe to the mailing list here.
Tech roadmap
Note: This part is mostly for people who are interested in development / engineering aspects of Aether. If you’re just interested in the product, you’re more then welcome to skip.
The expected completion of the backend[5] is about a month away. After this is done, it will be the frontend and the client that is next.[6]. The work in the backend is the more novel and creative part of Aether in terms of engineering, the frontend and client are fairly common app types with existing best practices. Aether 1’s frontend experienced no significant bugs nor performance problems, therefore our past experience is also useful — and should make it a reasonably fast endeavour.
This is a list of items that is on the plate for implementation as of now, for the backend.
Implement the initial block download algorithm that triggers when a node is offline for a long enough time that it loses track of the network head, or when a node is joining the network for the first time. This algorithm distributed the load across multiple nodes so as not to overtax one single peer that provides the bulk of the send bandwidth.
Implement the petri dish reporting to automate the testing for time-to-consensus (TTC). TTC is how fast a group of nodes reach to consensus, and it’s denoted as percentage ratio divided by seconds.
For example, a 55 second TTC at 50% means that it takes 55 seconds to reach consensus across N number of nodes that differ in their content by 50%, excluding the time spent in sync process.
Think through and decide on whether private realms are a possibility for the initial launch. Private realms are encrypted, members-only boards and other services only for their members, and they traverse only between their members, their data nor connections do not mix with the public network. They effectively are separate, split universes.
Implement the minor libraries, such as moving the main transport to HTTPs only, hardening the outbound server, and reference counting for data deletion.
Consider a separate class of bootstrap nodes which are community members that self-nominate themselves to be available for getting new nodes up to speed.
There are also some other more minor to-do items, but they do not merit the discussion here as they are of mostly mechanical nature.
How can I help?
First of all, if you have considered, thanks for the support! We will shortly be starting to host community events in San Francisco, California, USA. If you’re there, you should email us for an invite.
The best thing you can do to help, if you choose to do so, is to spread the word to people that might be interested in such a thing, so that when the alpha-testing start in June, we will have enough of a critical mass to bootstrap a community of like-minded people. We realise that the technical product is one thing, but the much harder challenge is to have content from like minded people that is interesting, so that you return to it day after day to enjoy it. It’s all about the humans behind the wires in the end.
Bonus
Here’s a video of Aether backend achieving consensus! (You probably need to be an engineer to share the excitement, though)
Footnotes
[1] Aether’s boards have moderators, but those moderators are subject to an ongoing election. Moderators’ actions (including deleting posts) are auditable by everyone, and if a mod falls too much in popularity as indicated by community voting process, their modship is revoked.
[2] We do not mean strong privacy in the sense that “we won’t look at your data [asterisk] [asterisk] [asterisk] followed by legalese that makes the app own all data and your firstborn for any purpose in perpetuity” We mean strong privacy in the sense that “we can mathematically prove that your data never leaves your computer”.
[3] Aether is a peer-to-peer, distributed network. You might have heard of this term in regard to crypto-currencies, and yes, Aether does borrow some aspects of the blockchains. It is different, though, in the way that it uses a new type of blockchain that does not require distributed consensus. That makes it much faster (100x-1000x faster) than existing blockchain implementations.
[4] The app Aether is open source (AGPLv3), as well as the underlying peer-to-peer communication protocol (Mim). Source code can be found here.
[5] The backend is actually reasonably complete, in that it does its job just fine under petri-dish testing. The work that is left is stress testing to root out bugs, and adding some new features that is going to be useful in the future.
[6] Aether is composed of three parts: a backend, a frontend and a client. Here’s what it means.
Backends are nodes that communicate with other nodes in a peer-to-peer fashion. They form the backbone of the information traversal across the network. A backend does not retain any user information, and it can be a private (baked into your app, which is the default) or a public entity (i.e. it can be made available on a public park, similar to a community-access Wifi network.) A backend can also serve multiple users. A backend does not care or understand what it transmits, so long as it is valid Mim blocks. For example, an Aether thread is a thread entity and a few posts linked in a fashion that indicates who replied to whom, amongst other things. The backend does not follow the links between these blocks, or nor does it understand that this is a thread. It just passes the entities within that thread according to the rules that are set in the protocol. A backend is effectively a distributed database with a novel sync engine and load balancer that is particularly optimised for the type of data that it carries through.
Our current testing reports that a regular laptop or desktop computer running the backend can ingest data equivalent to a month’s worth of Reddit’s content in around 14 minutes from the network, given no bandwidth constraints.
Frontends are the apps that connect to these backends, and they compile their own understanding of the world based on the blocks received by the backend. This is where a bunch of Mim blocks become a linked, compiled “thread”, that humans can understand. Frontends fetch the data from backends and then save into their own databases, in a compiled form.
Client is the actual, user-visible application that the front-end drives. This is the user interface, and the commands issued by this client hits the frontend. Clients are OS X, Windows and Linux, as well as mobile devices. Desktop and laptop computers are full nodes, which means they run backends, frontends, and clients in tandem. Mobile devices are partial nodes, which means that they run only the frontends and clients, and they need to connect to either a public backend provided by the community, or one provided by default for mobile devices. So long as they connect to a backend that is tracking the network head, it does not matter which backend they connect to.
