This is a review of the current situation of Aether in terms of overarching architecture & coding style. Github repository is here.
Who are you?
I’m Burak, a 23–year–old designer from New York City.
Why is there no Windows or Linux executable?
If there are things that you do not explicitly see a reason for, chances are that it’s there to mitigate some kind of attack or abuse. There was a particularly nasty case of implicit trust into a third party that could be exploited to create a DDoS, but I have almost completely rewritten the culprits. Aether functions on the principle of no trust: if you see something in code that assumes the remote will answer truthfully, please notify me immediately, I will take a deeper look.
I have opted for sanity and consistency rather than full compliance with language style guides. If you see something I shouldn’t be doing, both in nitty gritty and in architecture please also let me know. If something seems wrong, it’s probably wrong.
This is my first real code project, which should be obvious looking at the code. The code I have written long ago is probably less sophisticated than what I have written yesterday: the entire thing, in a sense, is like seven cities of Troy, built on top one another.
Don’t expect open–source project levels of quality. I’m just making it up as I go. This doesn’t mean it’s horrible, rather, it varies. It has gotten a few significant partial rewrites already, and it will likely get more. There are a few code smells I am aware of, and probably hundreds more I am not. You’re welcome to point out—I’ll do my best to fix.
Much like other peer–to–peer protocols available, Aether does not have any servers in the classical sense. People use Aether to serve posts, which are the main unit of information, but that’s the extent the resemblance goes.
Since the only type of content allowed is text, it is more or less unaffected by residential broadband speeds across the world; each post containing a few kilobytes of information is no strain for all but the thinnest of pipes. This triviality of carrying over specified information is also one of the key points that makes Aether unique; Since the actual retrieval of information is not a problem, it can use this flexibility to replicate data in many different locations. In fact, from a theoretical point of view, Aether can be seen as a large–scale eventually consistent database.
This replication also allows the votes to exist: If a node asks another for posts, the remote node will reply with SHA256 fingerprints of the posts the remote has received since the last sync. The fingerprints are grouped into a few categories: If a fingerprint is grouped as positive, the local will save it as a positive vote if the post bound to the fingerprint exists locally. If it does not exist, it will ask for the post itself, create the post, and then save the vote.
The basic idea is quite simple: if Alice likes a post written by Bob, Alice will upvote it, and thus will start to distribute that post, too, increasing Carol’s chances of coming across Bob’s post. This means voting is important. There is only one way to moderate, and it’s the collective one. This is essentially direct democracy.
This two tier structure has its benefits: you can strip away the entire frontend and build your own. A remarkable lot of functionality is available through Charon API, which you can peruse. The backend is only concerned with fundamental functions such as sending, receiving data, and database transactions. Whatever you want to do with the data it supplies to the frontend is your decision. The sorting algorithm for posts for example, lies in the frontend territory.
This separation is not complete yet and I had to make a few sacrifices in order to ship in a reasonable time: If you want to build on top of it, let me know and I’ll try to make your life easier.
There is a mechanism called ‘neutral broadcast’ that prevents extinction of posts. If a post’s availability falls below a certain threshold across direct circumference of a node, the node will start to flag it as neutral, and will make it publicly available. This is designed to ensure that most posts will not disappear from Aether because the people who upvoted it have all gone offline.
Aether is language–neutral. If you give it a list of languages you know, it will start to fetch posts in those languages. This allows a Chinese Aether and an English Aether to coexist without polluting people’s feeds with posts in other languages. Aether will try to decide at the point of posting the language of a post, but especially for shorter posts it can get language wrong. In those cases, a manual selection fixes the error.
The encryption is standard TLSv1 with the cipher suite TLS_RSA_WITH_AES_256_CBC_SHA with 2048 bit RSA keys, handled by OpenSSL. I can proudly say I have written exactly zero percent of the encryption code, but you should do your own audit of the repo.
I considered using 4096 bit keys, but while my first-world retina Macbook Pro doesn’t quite flinch at the idea of doing a few hundred handshakes per second, it’s probably not true for most people’s hardware.
The encryption isn’t meant to stop physical access—nothing can. Rather, it’s there to prevent eavesdropping in circumstances where all cleartext communication are filtered or tapped. Aether does not care about who the guy sitting at the other end of the wire is, so client certificates or a PGP-style web–of–trust is in this case not needed.
The certificate and the key can be found at UserProfile directory. If you are concerned that your key might have been stolen, just delete them. Aether will simply create another pair and certificate. It does not affect your connectivity; user identity is not based on cryptographic keys. In fact, there is no such thing as user identity.
The client is designed to retain very little information; the ideal would be to retain absolutely nothing that would reduce plausible deniability, but to notify the user if there are are any replies, Aether has to retain a ‘locally created’ flag on posts. This flag is never transmitted and I am planning to give user an option in settings to not use this flag at all if they can live with not getting notified for replies. The other pieces of information are a few config and debug flags, and a list of topics the user is subscribed to. You can take a look at this yourself by unpickling the backendSettings.dat and reading the UserProfile.json in UserProfile directory.
Warning: The current client is a beta client, and if you do not specifically tell it to not keep logs, it will log almost everything and send it in cleartext! Please consider keeping logs, while I have tested this with a few computers, I have no idea what the emergent phenomena will be. The network could use quite a bit of fine tuning, and logs are the only way for me to see how the network reacts.