diff --git a/README.md b/README.md
index e69de29..93944c8 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1,29 @@
+## The problem:
+Even though the matrix.org blog describes [two way puppeting bridges](https://matrix.org/docs/guides/types-of-bridging.html) as the holy grail of bridging, and they link [a great community project](https://github.com/matrix-hacks/matrix-puppet-bridge) as an example how to do that, there still is a problem: How to decentralise this? 
+
+Until now, everyone can run their own bridge, in addition to their own home server, and 3rd party rooms will be mapped into matrix just fine. What happens though, if two people, who both use this kind of bridge, join the same 3rd party room? The matrix room they write to is not, how one might assume (or rather hope), the same room, and all of a sudden, messages written by matrix user A arrive at the room of matrix user B as some ghost user, from the 3rd party network.
+
+## The solution(s):
+### A single, centralised bridge:
+
+The easiest way to circumvent this, is using one central bridge for all users. I don't have to tell anyone why this is a really bad idea, since there are multiple bad problems with that.
+
+### Multiple Bridges:
+
+Using multiple bridges in a single room creates some other problems though:
+ 1. What messages should a bridge forward?  
+     1. Everything -> Duplicate messages.  
+     2. Only those of it's registered users -> Missing messages.  
+ 2. How to find the already existing matrix room, or how to even know if there is any.
+
+These problems, especially the second one, seem rather difficult to solve at first, adding a lot of complexity, with not a lot to gain. 
+
+Looking at the IRC Bridge though, shows that the first one is easy to solve. The difference between receiving a message a lot of times on one server (the single freenode bridge on matrix.org) due to a lot of connections (one per user), and receiving a message a lot of times on different servers is not so big. One of the connections is used for receiving the third party messages and piping them into the matrix room (all except those, that come from users bridged by other bridges), and the other ones are used for sending messages as the corresponding users. 
+
+Failover needs some way where the bridges can communicate, but hey, they are all already connected to a federated communication network, that should not be a problem. A "bridge status room" to accompany a chatroom should be fine for that. Determining a bridge to take over for an unresponsive bridge should be easy, just base that on the reliability of the different bridges.
+
+The second problem is harder though. The easiest way would be to have an openly available database of 3rd party room to matrix room (needed for 2) and 3rd party user to matrix user (needed for 1.2) mappings. That is not desirable though, since it is centralised and leaks some information, that should not be leaked/does not need to be leaked.
+
+Decentralizing that is as easy as moving from a central database to a matrix room. Accessing that should be easy, with a list of public aliases to make sure joining that room works even when some servers go down unexpectedly. Fixing the data leak is also not that bad. You'd just need a public mapping of a 3rd party id to the bridge bridging that user, to get the room mappings, since the bridges can then communicate through matrix privately. 
+
+From then on, what's left to do is writing a spec on this and actually implementing it, but how to do it should be rather clear now.