Aether News & Updates - April / May 2018

Time for another update! I’ve been busy working on Aether for a few months now. This means a lot of changes, and the codebase has grown quite a bit. The good news is the backend is close to complete, which means I can move into the frontend in the next few weeks and start showing actual UI and start collecting critique.

As always, the code is pushed weekly here, and this is the list of commits.

Launch timeline

The idea is that we would be able to launch in July or August. This means there’s a few months left for the frontend, and I want to be able to be completely done (well, 95% done) with the backend by the end of May.

Currently working on…

The main thing I’m working on right now is to interpret the results from petri-dish testing to the point that the network is stable as possible at the outset. Petri dish testing is a framework that we’ve built that runs multiple Aether nodes in the same machine under an isolated environment, which makes it so that we can see real node behaviour over time and analyse the results of it. This gives us metrics like time-to-network-consensus, and we can optimise these metrics to make the network overall the fastest and the most stable it can be before launch.

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.

These are the items that are currently on my plate.

Create the ‘bouncer’ library. This is our rate-limiter so that the Aether nodes running won’t break when they’re bombarded with requests, they’ll just start to refuse them after a certain threshold. This value is user-settable.
Implement Initial Block Download IBD is the process where a node that is new to the network bootstraps itself across multiple remote nodes, not just one. This is important because it makes the entry speed much faster.
Violations counting This is the system that temporarily blocks misbehaving nodes, so that their actions are ignored until the misbehaviour is corrected.
Event horizon & deletions This system is the one that allows Aether to be ephemeral. This deletes too-old content based on rules set by the program and modified by the user.
Frontend This is the layer between the backend and the client. This layer caches requests and compiles the raw data in the database into forums, threads, posts and people. At first, this will be mostly passthrough, in the future (before release) it will start to cache the results of the computation and maintain these caches to render user latency to be zero.
Client The client is an Electron app using TypeScript and Vue. This includes the design work also.

I do have some more smaller items, but they’re going to take only a week maybe, in total.

If you have any questions, feel free to post a GitHub issue, or email me at burak@getaether.net. Cheers!