Dynamic DNS Facebook
March 17th, 2010First post in this series: Freedom Box
So you want to take control of your own online life. Where to begin? Our first step is the razzle dazzle of the social networking tools: the ability to find your friends.
Social networking tools are made up of mostly unremarkable parts like email, IM, and photo sharing, etc. The selling point is not that Facebook offers better email than Google, or better status updates than Twitter, few think they do. What motivates people to join a social network is the promise of getting in touch with friends who are otherwise hard to contact. Of course, the more people join believing they can find each other, the more people there are in the system and the better we actually are able to find each other. There is no magic to it; it is just a centralized directory fueled by the network effect. They require all your personal information, but the service does not need that to function. In fact, if the phone book had 400 million users and some pictures, it would work just as well. Which is great, because we can build that out of existing parts.
The Internet as Directory
The internet is build on a central directory called the Domain Name System or (DNS). DNS is what directs us from the memorable addresses we type, domain names like “churchkey.org”, to the actual IP address of the computers with information we want, like this blog. If the address of the machine behind a domain name changes, a simple DNS update points the old name at the new address and web traffic keeps moving without anyone noticing. If the machine you’re keeping your stuff on moves frequently, perhaps it is a laptop or on a cable internet connection where the IP address can change unexpectedly, you keep a little script called dynamic dns running on it that updates the directions automatically as you move. These tools enable us to find our stuff anywhere on the internet but they are built for finding machines, not people, so we need to extend them a little.
Making the Directory People-aware
A server running our new extension would be called something like a “friend finding service” or perhaps “FrienDNS”. People could create accounts with this FrienDNS server just as they do with dynamic dns servers, picking a user name and putting in directions on where to find the machine with their stuff, but this time they give the server a little more information about themselves as people. Not too much information, this is a centralized service after all, but just enough for people to recognize each other in a search and ask to “friend” or otherwise connect. Maybe that’s just a name, picture, and where you’re from; the kind of things you found in old college facebooks before the term got trademarked. Maybe you give more information than that to the business community FrienDNS service or to the dating one. You decide in each context how much information to give other people before agreeing to connect with them.
Managing “Friend” Requests
Once someone finds you and wants to connect, the FrienDNS service gets directions to your machine from the dynamic dns service underneath and sends the request over to you for approval, just like we expect social networks to do. In addition, I’m going to say we should have the friend finding service keep a unique token from us, some little bit of machine data we give it so that, when it sends us a connection request, we know it really came through the service. So when you get a request to connect with someone, you see who they are from their FrienDNS account information, which service they found you on, and a token from the service confirming that the request really did initiate there.
By requiring that people go through the friend finding service we get all of the SPAM and abusive member management aspects of social networking tools. If a particular user turns out to be a SPAM bot or the arm of some advertising agency, people can report that user back to the service for account deactivation. Since a loss of cooperation from the service means that you can’t get user’s tokens, and everyone will ignore connection requests that come sans-token, users need to play by the rules if they want to continue contacting new friends.
We can use the same system for screening potential connection requests. So, if you are using an online dating site built around FrienDNS, and you only want to receive contact from people you think you’ll like, we could build tools to check for whatever dating criteria you want before handing out your token. If you want to hook into your school’s email system and only give contact information to someone with an active @yourschool.edu email address, we can add tools for doing that too. Or, if we want to move in the other direction and run some services that have greater anonymity, there is no technical requirement for the token; it is just an example of the kind of simple things we can do to police friend requests for those contexts where we need to police them.
Saying “Hello”
Once you and your friend have agreed to connect, you exchange keys and establish an encrypted connection with each other. From this point on, the FrienDNS service has no idea what you are saying to each other. You only need to talk to it if one of your machines moves and you need updated directions on where to send your encrypted communication stream. You could even agree to go get your directions from some other system and simply ignore yesterday’s FrienDNS in favor of some new, more popular one. Once you have connected with each other, that’s it, you’re no longer dependent on the good graces or good behavior of any intermediary. Congratulations, you have replaced your intermediated “social network” with a network of direct friend-to-friend connections. We’ll look at what that means more next time.
Later posts in the series:
Part 3 – Talking amongst ourselves: Friend-to-Friend Network forthcoming
Part 4 – Putting the pieces together: Freedom Box schematic forthcoming
Part 5 – Making it easy: Look and Feel forthcoming
