|
|
# Federated vs Distributed
|
|
|
|
|
|
After I have been at the [30c3](https://events.ccc.de/congress/2013) (30th Chaos Communication Congress), I noticed a lot of people were working on
|
|
|
purely distributed protocols, and some were even openly against any client-server or federated architecture.
|
|
|
|
|
|
I believe each application should be designed with a specific architecture, Which is Why I
|
|
|
made Fenrir with federation in mind, but in a way that lets you build any system on top of it.
|
|
|
|
|
|
**This analysis is incomplete, contact me to modify it if you have comments**
|
|
|
|
|
|
# The Distributed architecture
|
|
|
|
|
|
The arguments for a distributed architecture can be:
|
|
|
* I don't want to manage one or more a server(s) (pay, administer and maintain)
|
|
|
* I don't want anyone else to own the data I put on the system
|
|
|
* I don't want anyone to have control on what I do, or what data I have on the system
|
|
|
* distributed means no points of failure
|
|
|
|
|
|
The arguments against are:
|
|
|
* distributed means highly increased initial complexity
|
|
|
* distributed means total lack of control on where the data is
|
|
|
* a distributed system has to be highly optimized for its purpose -- likely no interoperability
|
|
|
|
|
|
----
|
|
|
|
|
|
A well-designed distributed system has high security and usually a good degree of anonymity.
|
|
|
|
|
|
The fact that our data is distributed across multiple servers over the Internet means a couple of things:
|
|
|
* things should be impossible to subvert (if you do not control almost all the distributed network)
|
|
|
* limits on bandwidth / space are difficult to enforce -- imagine a distributed facebook/google database.
|
|
|
* laws become difficult/impossible to enforce
|
|
|
* everyone needs to participate in the system, so the user uses a lot of bandwidth/disk space.
|
|
|
|
|
|
some of this things can be **both** good and bad.
|
|
|
|
|
|
but each system must be designed for a specific need, so:
|
|
|
* interoperability at the protocol level between distributed systems is impossible.
|
|
|
* you need a new application for every service (and cpu, disk, bandwidth requirements change)
|
|
|
|
|
|
|
|
|
# The Federated architecture
|
|
|
|
|
|
Federation means:
|
|
|
* The federated server operator has control over its users
|
|
|
* The architecture is hierarchal
|
|
|
* only really used services and domains need to scale up, not the whole network.
|
|
|
* the end user uses only the bandwidth/disck space, cpu for its requirements.
|
|
|
* protocol-level interoperability between different organizations.
|
|
|
|
|
|
Contrary to popular belief, federation does **NOT** mean:
|
|
|
* control over user data (encryption can be used)
|
|
|
* dependency on a single organization (if the service is open, you can just change domain)
|
|
|
* dependency on **any** organization (you can setup your own servers)
|
|
|
|
|
|
In short, federation is easier, gives the operator more control, but can still be used in a secure and privacy-oriented way.
|
|
|
|
|
|
## The downside:
|
|
|
|
|
|
The only downside of the Fenrir federation is that your main server can impersonate you when connecting to **new** other services.
|
|
|
|
|
|
This means that if you already logged in somewhere, your authentication server can _not_ impersonate you there.
|
|
|
|
|
|
I'm still trying to find a solution to this, but for now it is inevitable.
|
|
|
|
|
|
# The Fenrir Way
|
|
|
|
|
|
I have chosen a very flexible design. It is federated based, but **this does not mean federation is enforced**.
|
|
|
|
|
|
**_You can still use Fenrir in a client-server model_**. You can use this model to build a distributed environment.
|
|
|
|
|
|
The problem for your distributed environment will now be the distribution and verification of the public keys. There are numerous ways to solve this, each has its own strengths and weaknesses.
|
|
|
Just get the ip, public key, and you are done, you can use Fenrir just like SSL/TLS today.
|
|
|
|
|
|
Of course, I still recommend designing a federated system that grants security and privacy to the end users, maybe as opensource as possible, so that people who do not want to trust anyone else can still run their own servers.
|
|
|
|
|
|
Since federation is easier, you can then concentrate on the features of your system, and not on the technical details of its distribution. |
|
|
\ No newline at end of file |