Ian Clarke edited this page Sep 27, 2013 · 29 revisions

Note: This is a rather rushed description of my intentions for Tahrir's architecture. I would spend more time on documentation, but I think its more important to get to a working prototype quickly. If you have questions, just ask on our mailing list (don't worry, we are very welcoming to newbies).


Tahrir will be a distributed, decentralized, scalable, and anonymous "workalike" for services like Twitter and Facebook. Unlike these services it will be software that you download and run on your Internet-connected desktop computer or laptop (and later your cellphone).

I'll elaborate on each of our design goals here, while contrasting Tahrir's design with existing anonymity systems like Freenet and Tor. For some planned post-initial-release features see Future Capabilities. You can also read about our Design Philosophy.


Tahrir is released under the GNU General Public License version 3.

Low-bandwidth usage

We want people to keep Tahrir running even when they aren't using it. To encourage this, its important that Tahrir use a negligible amount of bandwidth. Therefore, on a broadband connection, Tahrir will typically use less than 1k/sec of bandwidth. On a dialup, it will use even less.

Small-world routing

Tahrir will rely on a self-organizing small world network (like Freenet) to achieve scalable routing and broadcast of messages between peers. If Tahrir was the Internet, this would be its IP layer. This layer does not offer anonymity, although may offer a degree of obscurity as messages are relayed between peers and encrypted.

This approach has the added benefit that it can operate both in situations where the connections between peers can be chosen by the algorithm, and situations where they are not (as in a "darknet"). Please see Oskar Sandberg's thesis for further information on this.

This lowest-level of the Tahrir stack will operate over the UDP protocol. It is intended to have no easily discernible features, such as running on a specific UDP port, or having identifiable header information, although this quality in-itself may make it stand out. Nonetheless, steganography is not a goal for our initial release, although it could be added later, perhaps making Tahrir traffic imitate VoIP or video-game traffic.


Like Tor and I2P, Tahrir will offer its users the ability to route their messages through a Mix-Net. This system will be built on-top of the small-world routing layer.

Unlike Tor and I2P, Tahrir has much less stringent latency requirements (due to its Usenet-like "store and forward" approach, described below), and this makes timing attacks, one of the most serious challenges faced by Tor and I2P, much more difficult. People are a lot more tolerant of a delayed tweet than they are about a delayed web-page loading.

A critical issue for mix-net systems is relay selection. If an adversary can get you to choose relays they control, then they can break your anonymity.

Tor makes all relays publicly available to everyone, but this has the unfortunate effect of making it trivially easy for an adversary, like the Chinese government, to block these relays the moment they show up.

Tor has sought to address this problem through a mechanism called "Tor Bridges". They aren't made available all at once, but rather they are rationed, in the hope that this makes it more difficult to harvest all of them. However, this approach is likely to merely inconvenience an attacker, and it certainly inconveniences the end user as they must obtain a list of bridges through out-of-band means (which themselves may be subject to censorship).

I2P employs a more sophisticated mechanism involving a "distributed hashtable", however this mechanism may be quite easy to disrupt and/or corrupt.

Tahrir's peers will learn about new relays through a variety of mechanisms, including from other Tahrir peers. Its relay-selection system will use multiple heuristics to make it as unlikely as possible for an adversary to control all of the relays you use, by ensuring that they are "diverse" according to a variety of metrics (source, IP address if we know it, etc).

Tahrir will also have the ability to spread "virally". A friend will be able to give you a copy of Tahrir via email, or on a USB drive. This will contain everything your computer requires to join the Tahrir network. This avoids the fundamental problem of finding an uncensored "out of band" means to join the network initially.

Tweet transmission

Naive broadcast

In its earliest released form, Tahrir will use a system similar to Usenet for distributing tweets. Basically the idea is that each "tweet" has a "time since useful" (TSU) integer associated with it, which is incremented every time a tweet is forwarded to another Tahrir node.

Typically any node will have a long list of tweets it might want to broadcast to other peers, but these broadcasts are constrained by Tahrir's low bandwidth threshold. It will always start with the one with the lowest TSU value. If a node's user reads the tweet, then the TSU value is reset to 0.


In this version, Tahrir nodes can register their interest in particular tweets, which then propagate "upstream". A node that has registered a specific interest in tweets by a particular author will always take priority over naive broadcast. Obviously this approach will be far more scalable than naive broadcast.