Tent v0.1(tent.io) |
You can see it in source code.
I want to hack and work on my own ideas. That's why I trust my mail hosting to Google. Sure, they read all my emails and analyze me for marketing. That's a small price to pay though. I get a rad web client, Apple Mail + iPhone support, and never need to worry about my email server. Anyone remember qmailrocks.org? I used to sit for hours messing with and playing with qMail back in the day. I've done it. I've hosteed mail servers for friends and family. What a pain in the fucking ass!
Same for hosting. I love configuring infrastructure. I taught myself HAProxy, load balancing, nginx, and clustering years ago when people were still using mod_python. I built a FreeBSD box for fun with old parts an an old SSD the other weekend. I have quite a few linodes running right now. But it's also a pain in the ass. Because of that, I also enjoy pushing my personal site to Heroku and not worrying about it ever again. git push, boom done.
A lot of people take things like Facebook for granted. We all bitch and moan about all kinds of issues it has or features it lacks, but it's a gargantuous network that virtually everyone that I know or care to talk to is on it. My family and friends back home in LA where I grew up, my new friends in Sweden that I met while abroad recently. It's got a handy mobile app (that was luckily redeveloped recently) and best of all it's 100% free.
This decentralized stuff is nonsense. There's too many layers of crap. Even if there was a one-click-deploy social network for people where all they needed to do was rent a server somewhere... someone is still running that server and you need to worry about them snooping your data or whatever else the neckbeards are worried about.
Remember Diaspora? Hah.
I don't know why you are assuming that everyone will have to run their own.
Also, it seems very cynical/naive to think that just because such systems aren't currently working/won't currently work with given social structures, that this will always be the case. Do you disagree?
I can't help feeling that the natural outcome of decentralized social networking is that people eventually start hosting them for mom and dad, then a few friends, then start companies, then we are back to facebook. Someone, somewhere is going to have to have a database of names mapped to servers.
Centralization is, in an abstract way, present in so many of our social structures, that yes, I disagree that within a capitalist economic structure (one which is optimized for sharing of services rather than individualism, ie: non-technical users simply wont do this unless the work is done for them, like facebook did) it would be next to impossible for something like this to work.
People quite simply don't want to deal with this shit, and centralization brings efficiency and management amongst many other things.
Facebook is the opposite of this. I have no option to build my own site for facebook style networking. I have no option to subscribe to Google's implementation of a general social networking protocol.
Imagine if GMail only allowed you to send Google Mail(TM) to other @gmail.com addresses. Email's decentralization allows us to ignore the fact that other people may be reading on an iphone, yahoo mail, or emacs.
Decentralization isn't (only) for neckbeards. It's about giving users freedom to socialize with those who choose a different client. Isn't it bizarre that I use LinkedIn, you use Facebook, therefore we can't be friends?
First we build the decentralized social network, then I will decide if I want to social network with you via google, yahoo, or emacs.
Your mom/sister/dad/cousin are going to use a service that allows them to post status updates, instead of just using Twitter. Just like your mom/sister/dad/cousin use Gmail for email, and not their own server.
Most people don't host their own email service, but most people do benefit from using email – and the best part of it is that there's no monolithic Email Inc. that could someday go bankrupt and bring everyone's emailing days to a close.
Plus, it's really just an advanced version of email. I mean, you could build a fancy social network on top of SMTP. And SMTP is decentralized, so I don't see any reason why this shouldn't work.
Regarding Diaspora, it seems that tent.io is starting with the protocol instead of the frontend, which seems more promising to me.
Did you try to install a recent Skype version? Download an executable, run, enter your login and password, and it just works.
Execution matters, you know.
If there was a system that acts like current centralized systems out there it wouldn't be a matter of it being hard. The technology is becoming easier and easier.
If presented properly, there is no reason a decentralized system couldn't attract normal people.
Facebook and Google make it appear that what you are using is actually on your system. That you control the information. Yet, the so called "small" price of that is you have to give away personal information to them.
With a system that is completely decentralized and secure and keeps people's privacy while being so easy to use that my Mother can use it w/out problem, centralized systems would be in danger.
So yes, the current way of doing things is for geeks. That will change with projects like Tent. Centralized services will ultimately fail simply because of the violations to peoples privacy are starting to really piss people off. Normal people. Like me.
If I want to share my music playlist with my friends, I should be able to do it. I also don't like being censored and watched, which is exactly what these systems do. Don't believe me? Search it. And if you don't mind that type of thing for convenience, then I'm not sure you understand freedom.
And by the way, those "neckbeards" are the ones who are going to set things straight. A decentralized system doesn't necessarily have "servers". Everyone will be their own type of server.
That's not the point. Those aren't the ones decentralization benefits. Decentralization will benefit other organizations, such government agencies, companies, non-profits, NGOs, etc. These organizations most likely have other services running on either their own infrastructure or they have some one else paid to host it. They benefit by retaining control of the namespace and ability to post a message without relying on a centralized service.
Diaspora has some similarities with Tent, but there are a lot of differences between Tent and Diaspora.
There is a reason we don't dispose of our own garbage. It's just worth paying some one else (plus efficiencies of scale). Infrastructure like social network is garbage. People don't wanna deal with it, don't care how it works, and are glad to externalize the cost. They just want their waste to magically disappear. Or, to maintain / increase their social status with friends and family.
The sweet spot both Tent and Diaspora are/were aiming for is one where most users use somebody else's service, but a few crazy neckbeards choose to self-host.
The neckbeards who actually care (often quite unreasonably) about privacy, etc, provide a very useful service to the ordinary users - they keep the central service(s) honest, ie, keep them from turning into Facebook. Because it's possible to escape, because the neckbeards keep that possibility open, the ordinary users are not captured.
At least, that's the theory. Diaspora didn't execute on it. Tent, well, we'll see.
Make it easy for people to participate casually, but also make sure that people can customize to their liking and exert full control over their own stuff if they wish to, without causing trouble to the rest of the network.
This is truly, exactly it. I don't expect my mother or friend to run a Tent server. But imagine Facebook were a Tent/Diaspora host. People would have left in DROVES by now if another, somewhat equal host could migrate their data in and provide better user respect.
Why does everything have to be built on top of HTTP? Sure, I know you're going to say, because it works, and works well that's why.
But think about it. The reason why we have all these centralized services in large part is because of HTTP. HTTP has made it really easy for someone to build a centralized service, or application, like Facebook or Twitter. Before the days of HTTP, if I wanted to build a service, I probably would invent a protocol like Telnet, Gopher, SMTP, IRC etc., which is often naturally decentralized, instead of programming a web application.
Perhaps if we want more decentralized services, we should focus on frameworks that make it easier to construct TCP/UDP based protocols.
Just a thought.
From the homepage:
Tent is open, decentralized, and built for the future. Tent changes everything.
Tent allows every user to run their own server, but like email and the web, most
users will use a hosting service to handle it.
The documentation for Tent version 0.1 is now available along with a reference
server, tentd.
What is Tent?
Tent is a protocol for open, decentralized social networking.
Is this project like Diaspora? How is this different from the competition. I'm excited to hear how this is unique and to see where the project goes.
(I posted this as a reply to someone else but it deserves its own comment.)
The docs don't include any specs for handling push errors. If I push a new status and one of my followers' servers is down what do I do? Do I retry later? Do I continue to try pushing future updates? At what point do I stop trying to send updates to their missing/broken server?
If my server goes down how do I handle missed updates? Do I need to query everyone I follow? Can I fetch statues since the last one I received like Twitter? The docs say "There are a number of parameters available to limit the scope of the request" for GET /posts but don't specify what the parameters are.
Error handing is crucial for a decentralized network like this, especially one that pushes to other servers. Without a method for handling servers that go down and other errors it will absolutely not work.
[0] http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-co...
It's time for you to show me why I should invest my time in writing apps for your platform/protocol.
I recommend putting a link to the tent.io homepage that says "new to Tent? Click here!"
For this to get traction, it'll need at least one server with a strong user base.
Sooooo...Facebook basically.
Since the protocol is new it doesn't include any specs for handling push errors. If I push a new status and one of my followers' servers is down what do I do? Do I retry later? Do I continue to try pushing future updates? At what point do I stop trying to send updates to their missing/broken server?
If my server goes down how do I handle missed updates? Do I need to query everyone I follow? Can I fetch statues since the last one I received like Twitter? The docs say "There are a number of parameters available to limit the scope of the request" for GET /posts but don't specify the parameters.
Error handing is crucial for a decentralized network like this, especially one that pushes to other servers.
I wrote a series of blog posts about how such a system would work: http://carcaddar.blogspot.ca/search/label/ClearSky
Tent really really needs some justification docs.
There are also a few projects using XMPP, like BuddyCloud, Jappix, Movim, OneSocialWeb etc.
We could easily have a distributed web search engine to replace google. It could run on everyones machine, and it'd be awesome. But what would be the advantage?
Also before twitter/facebook, we had email - a distributed social network. How is the "new" distributed social network going to be better than email?
"Easily?" Distributing things is hard. The claims of those who don't know this are to be treated with skepticism.
> It could run on everyones machine, and it'd be awesome.
Until we get something like "Trusted Computing," there will be a few people who will run servers that "cheat" somehow. This has been true for distributed systems over the Internet for over 3 decades now. (SMTP, Gnutella, Bittorrent, just to name a few.)
Imagine you cannot use a word document created in windows cannot be used in linux or mac. Imagine YOU need to use windows just because other people use. Will this be good?
Choice of operating system is upto you and you must be able to exchange data across operating systems. That "interoperability" is needed for any good system. You don't need interoperability only if you want to monopolize the market.
I'd like to hear more about that. An easy to build distributed system able to take the same computing/network load of google? Man, that would be awesome.
These are the highly encouraging words I keep seeing from Tent that I never saw from Diaspora.
We're pleased to announce version 0.1 of Tent, <insert description of WTF Tent is>.
The description should preferably indicate not just what it does at a low level, but why you'd want to use it. In this context, the description on the documentation page, "Tent is a social layer over HTTP using JSON.", doesn't motivate Tent's existence particularly well. Something like this would be more instructive:
Tent <why Tent exists> by adding a social layer to HTTP.
Are there any authorization & authentication measures? (so you know a notification is really from whom it claims to be)
I see mention of HMAC in the overview, (how) does it solve those problems? I know basics of TLS, RSA - how is it related? I'd be grateful for hints. Also, I remember some alternative mentioned in old threads about Diaspora, which was reportedly devised by some security guys (?) and tried to have good security model - do you know the name of this project? Some GNU one?
Maybe Tent should think about a strategic partnership with a raspberry pi or another one of the many great cheap computing solution available today.
Write some basic stuff into it, and sell the device as a plug into your router and go social network device.
That way you could have a backup of all your social data, stored on your server if you wanted but broadcasted to the other servers.
I think the fundamental reason HN/Proggit and co. reject XMPP is because it's XML. Which is a ridiculous reason. Real-time streams over encrypted TCP seems to be the right way to go over forcing a protocol not meant for constant communication (HTTP) to do so.
To that add the fact that there's actually minimal benefit for most protocols to using something other than HTTP. Obviously there are protocols that are much better run over something other than HTTP, but most protocols, probably including Tent, aren't like that.
But your second point is unanswerable. I'd go a little farther and say HTTP is actually a pretty good fit for Tent.
If we see HTTP as a transport protocol like UDP or TCP, then yes you're very right. But if we look at HTML and web browsers becoming denominate applications of the Internet, then I believe that's how a lot of this centralization happened.
If you look at the web as a series of servers, sure it's decentralized. But contained on those servers are a lot of centralized services, i.e. Facebook, YouTube, etc.
Port 80 is already open.
A few of the DiSo protocols were based on XMPP instead of HTTP.
But yes, NAT does complicate things, particularly for home users, but I guess that's a limitation of the universe.
The notion that everything has to be HTTP annoys me too.
Persistence is handled by storing-and-forwarding your profile information to your friends. Privacy is ensured by broadcast encryption. If you want people unconnected to your network to find you, you could publish public profile information on a directory server (this could also be the status server that's needed for bootstrapping a connection if you're logging in from a public computer at the library or wherever).
I included links to definitions and further information about all the terms used in that series of blog posts. I'm definitely not an expert on cryptography but I'll be happy to try to answer any questions.
There's nothing complex about taking some data, encrypting it, and sending it to another computer. P2P/F2F public-key cryptography networks have been around for about a decade (see Justin Frankel's WASTE http://waste.sourceforge.net/). Putting this together with some advancements into an unhosted browser app is not a huge leap. The problem isn't going to be the technical complexity, it is going to be the UI and slow upload speeds.
The business model for this kind of network is going to be the same as the business model for BitTorrent - advertising on public directory web sites.
Can it be captured in a small, simple application?
WebRTC is cool because it will be in web browsers everywhere, and you'll have the "log in from the library computer" ability even for P2P networks, as long as there is a status web server you can bootstrap off of.
I'd be interested in hearing other people's take unless it involves "XMPP is too complicated."
I used to agree with you that the general public shouldn't run their own server, but that argument may no longer apply.
For example, my home PC (a mac) wakes up from sleep whenever I remotely need something off of it (took no setup on my part). The machine is always backed up, and already has all of my photos and address book. It's been just as reliable as my paid shared web host. So, why not start deploying services from our home PCs.
Think of the obvious benefit—I no longer have to upload photos. Given some additional thought I bet we could come up with other benefits to hosting from home.
I'm not quite ready to advocate for this, but maybe it's time to reconsider this assumption.
This doesn't mean you shouldn't be able to use it as a server - you should. However, to use it as a server, you'll need a proxy/gateway server on the real Internet (ie, in the cloud) and a pseudo-protocol by which the gateway talks to your home PC. The pseudo-protocol could even look a lot like the protocol that real servers speak to each other on the real Internet - but there's no requirement that they be the same. (I'm not sure how well inbound port 80 works if you're on Comcast, anyway.) So, when designing the real-server protocol, it's a layering violation to also be thinking about this pseudopod.
The hell are you talking about? I know I have a public IP address and am running several wikis, a Minecraft server and a Mumble server from my home, accesible via Internet (behind a firewall).
Next up is a SIP/XMPP server. Or maybe tent?
No thanks.
I think his point is that two nodes should be able to open and then connect on any port they choose, not just TCP 80. Please correct me if I'm wrong.
Are we saying that a user should not even be _allowed_ to have an application listen on any port except a known few?
Isn't the more important issue whether an application/process is actually listening on a port? I mean you can send me all the nasty bits you want but unless I'm prepared to receive them, what difference does it make? And I thought the whole premise here is that the only people on this social network are ones you know. They shouldn't be deliberately sending you nasty bits anyway.
I am a unixnoob. Please go easy on me for my ignorance.
This page (http://searchengineland.com/by-the-numbers-twitter-vs-facebo...) claims that google search handles 34k requests per second.
I'm yet to see someone describing how you can easily create something completely descentralized that is able to achieve such a high performance.
And I'm talking only about speed. If you throw other issues like quality of results, privacy, dependability, how to get traction, and so on, the thing becomes insanely difficult.
If it was so easy to do this kind of stuff, someone would already have done it.
That's not to say it was easy to make Facebook succeed, or that it would be impossible to make a service outcompete Facebook now. But it was certainly far easier to unseat the king back then than it is now.
(What's unfortunate is that IPv6 seems destined to become no more than one of these "crappy networks.")
But yeah, making a facebook/twitter-style social network app that uses plain email as transport would be really cool.
Probably. On the server-side RSS is nicer in some respects - you're not sending out mail to old, disused inboxes, you don't have to manage subscriptions or worry about being blocked as spam etc.
One thing that I think might make email better is if people got used to the idea of "email apps". The idea that my inbox might collate stories from a given source into a scannable digest (like RSS might give me) seems like a strange departure from the traditional idea of what an email client or service is "meant to do" - present discrete, unmodified messages in the most transparent way possible.
For a social network it's clear that you'd need something like that, though - you'd need clever filters on your feed, thumbnails on images, possible integration with image-sharing services etc etc. Using email and mailing lists gives you a big head-start, but if you can't build on top of it then it can't take off like a dedicated protocol can.
Because they have to. Don't set up a router? Don't get an internet connection. It's like how people manage to put their tax in.
The barrier for entry needs to be much, much lower than setting up a router, otherwise it'll just be passed over in favour of something else, like Facebook.
(This, though, like the internet, changes when you reach critical mass. Then barrier for entry can be higher without impacting uptake much.)
Wordpress.
A very important part of an interactive webpage is how it changes over time and with different inputs. Web developers have no trouble looking at some example widgets and imagining all the possible things a user could make them look like, but most people (might) have trouble doing that.
The same thing, I imagine, applies to running servers. I only know a bit about operating servers, but from my experience there is a complete, unremovable complexity that comes with having a powerful set of tools. Perhaps, we could remove almost all the configurability from the instant-server kit, but then why would you want to run your own?
What makes it all possible is NAT traversal. That is the fundamental problem being solved which takes us back to peer-to-peer and the orginal model of the internet. The rest is all just pre-configuration and UI.
The harder part, to me, is distributed trust in the discovery phase. Without a central authority it's really hard to ensure authenticity, fight spam, etc.
In general this is a common misconception at HN and in similar circles: Gmail may be ubiquitous among the tech crowd, but it's far from clear that it's even in first place among webmail providers.
It seemed more like a chat client than something I could run any application over. It was more an application for doing certain defined things accessible in menus (the ones you mentioned) instead of being a generic means to create peer-to-peer networks.
For networks with strangers, it's an entirely different ballgame. I have little interest in that can of worms. Way too complicated. That's for the geniuses who can create stuff like Freenet.
I guess I could look at the WASTE code, but I doubt I would find it simpler than the approach I've settled on. As I say, we all have our preferences. I like things very simple.
"Layering violation" is not the best term for what I meant, which is just "design mistake." Also the OSI model doesn't have much to do with reality. But if you want layering violations...
Modularity is a good thing. Composability often is too. For systems deployed in the large, the end-to-end argument also guides designs to simple cores and complex clients.
But none of that means that any given layer "owns" any piece of functionality. It would indeed make a whole lot of sense to start thinking of IP as the new Ethernet, for instance. But we can't really do that, because the greybeard priesthood uses concepts like "layering violation" to shut down discussion and maintain intellectual turf.
By "layering violation" I really meant "layering" in a systems rather than a protocol sense. For example, it'd be a "layering violation" in this sense if your OS had a system call print_powerpoint_document(2).
I find that all of the open social initiatives are either too broad or too specific. OStatus is entirely too broad, from their FAQ:
> First, rather than being a stand-alone spec it builds upon several existing (and evolving) open web standards including: PubSubHubbub, Webfinger, ActivityStreams and Salmon.
So if I'm a developer I can't just learn OStatus, I have to learn 4 other specs as well. Diaspora has the opposite problem, it's too specific. Their recommendation for contributions is to fork their rails app. Developers don't want to fork working apps and fix bugs; they want to write their own from scratch.
And as all of the protocols necessary already exist and are quite well-established, there are already parsing tools available for anyone to use freely. So development is really easy to get into when it comes to OStatus.
Using something that already exists is in this case much better than reinventing the wheel and rediscovering all implementation issues that have already been taken care of with protocols like XMPP or OStatus.
Spot on.
Freedom. e.g. being allowed to use a pseudonym or post breastfeeding photos.
People commenting about this in lists and forums and blogs make the issue more complex than it is because they have all sorts of assumptions about how it has to work. But as Rob Pike says when you assume you put plum paste on your ass. "Discovery phase." This is nerd stuff.
Put all the nerd stuff aside for a moment. When you want to telephone someone, how to you handle the "discovery phase"? You look up the telephone number and place the call. Everyone does this the world over. Second, how many people do you actually telephone in your entire lifetime? Hundreds? Thousands? (Are you a telemarketer?) Third, how many of them are people you see face-to-face at some point? People do not normally call lots of anonymous people.
A telephone network. (Actually a system of regional networks.) Everyone has a number. You get their number and you make the call. But how? According to nerds on the web, this should be a complex problem with no easy solution. But millions of people, non-technical people, make telephone calls everyday.
To think the web equivalent of a telephone directory is an unsolvable problem is ridiculous. And to think that every person needs a directory with billions of names is similarly silly. They will only need a small subset.
Moreover, with modern storage capacities, you could store a billion names and numbers on a small device no problem. Searching billion row databases is quite fast, if you use the right software. But you will never even need to go that far.
AFAIK people do not change their telephone numbers very frequently. Certainly not on a whim. If they do change it, then they have to let others know. Somehow they manage this., even if they are non-tecnical. Of course if you keep changing your number you'll be harder to contact. This ic common sense. But why would you do that? Why would you need to keep changing your number? Get a number and stick to it.
If you think stuff like MobileIP is the solution to roaming then you need to keep looking at what's possible. There are simpler and more reliable ways to do it.
How many people do you call in a lifetime? Think about it.
If you're thinking 'p2p' as skype is 'p2p', then fine, a directory service is easy to build. You just set up a centralized service to handle lookup, collision disputes, spam fighting, etc. Then when the centralized registry decides it wants everyone to start using their real names, we're back to where we started.
Lastly, you're right that the average person only calls a handful of people. But this is not the 1970s phone network, this is the internet. It's a different communication medium with different rules. Your HN account was created one day ago and has no contact information. The chances I could call you up on the phone are basically zero, yet somehow we're having a conversation.
Not really. Directory lookup should use a standardized API so that when one directory service goes rouge, clients can just switch to another they trust.
I do think that it's essential for this to be standardized. Not only for this reason, but clients/hosts shouldn't be forced with the responsibility of indexing the entire social web themselves.
That is exactly the type of conceptual roadblock I was alluding to in my comment.
But if you look at what people, not just nerds, want to do over the internet a significant portion (perhaps even the majority) of it is the same old stuff they did in 1970's. Send person-to-person messages and make person-to-person telephone calls.
The new dimension is of course person-to-person video, and we now have more ubiquitous bandwidth to make this happen that we didn't have in the 1990's.
Whether you see possibilities or just impediments depends on how you define the problem.
If you define the problem as achieving some sort of perfectly anonymous communication, an anonyous interchange of bits, then you are outside of the problem I'm discussing. It may be a fascinating problem, but it is not one that interests me.
I'm talking about doing those same old things we were doing in the 1970's, with the same degree of privacy we had (absence of advertisements and senseless statistical analysis of every word we say for commercial purposes), using the internet.
Millions of people manage to call their friends and family despite the issues of "discovery phase" and "trust". Millions of people have a connetion to a telephone network despite the potential of "spam" (cold calling? telemarketing?)
Again, if you redefine the problem your own way++ you can argue endlessly against any sort of simple proposal, e.g. one that aims to make something we've all been doing since the 1970's easy, for everyone, not just nerds: connecting, directly, to people you know.+++ Facebook seems to revolve around the idea of communicating with people ("friends") you know in real life, not online acquaintences you have never met. Is that the reason it's popular? I don't know. And I don't really care. Even if there was no such thing as a "social network" (buzzword), I see a utility in being able to stay in contact with people I know in real life. I fail to see Facebook, which is roughly the real world equivalent of a megaphone, as being necessary to do that. Why do I have to route all by bits through Facebook's website? The answer is: I don't. And NAT traversal is the solution.
++ We need a way to have anonymous communication with strangers. As other commenters have said, that problem is for the cypherpunks.
+++ And I'm pretty sure this is how the very early internet was, before firewall mania and NAT. People had met the others they were connecting to in real life. Or, at least, they had their real life contact information and could pick up the phone and call them, or send them a letter.
RetroShare is afaik completely decentralized private social network. Although it's security design isn't as good as I would wish it to be. Good network uses PKI and all data being transferred or at rest is secured. This also means that service providers can't be held responsible.
Many decentralized plans allow still operators to soop in network parts which they're operating. If there's separate client, why not to make sure that system is secure?
I'm not thinking about peer-to-peer from an anonymous file sharing perspective. I'm thinking in much broader terms. But I know anonymous file sharing is what many projects have focused on.
You are right that many puported "peer-to-peer" solutions are not true p2p. Look hard and you'll usually find a middleman somewhere in the scheme. Of course as we all know many users are not really interested in how something works, just so long as it works. How many people really look hard at the scheme being used?
As for IPv6, I think it brings a lot of complexity. And where there is complexity, there will be problems. Working with IPv4 is complex enough as it is. I like IPv4 because it's more widely found. Not everyone will have access to IPv6.
But nothing stops most of us in the free world from choosing an alternative root system. Other than the support cost of a minor config change in our OS or application software.
The difference between DNS and Facebook/Twitter is that DNS is regulated so that bad guys have to go through some kind of due process to shut down your domain. It's not perfect, but it's better than what else we've got.
DNS is really only optional for email, at least functionally. But I think a lot of people assume there can be no email without domain names.
Instead of another service that will essentially turn into DNS, I would propose just using DNS for naming. So if you're Tyler Durden you register tyler.durden.name and put an A record pointing to your DiSo server. Now you can switch providers while retaining your identity by just changing the A record.