After I have been at the 30c3 (30th Chaos Communication Congress), I noticed many people were working purely on 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.
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 single 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
The federated server operator has control over its users
The architecture is hierarchical
only really used services and domains need to scale up, not the whole network.
the end user uses only the bandwidth/disk 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 only downside of the Fenrir federation is that your main server can impersonate you when connecting to new other services. That is, the server can create accounts on your behalf.
But once you log into somewhere, your authentication server can not impersonate you there.
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, 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 yourself on the features of your system, and not on the technical details of its distribution.