(aside for foaf-dev people: the laconi.ca microblogging platform is being renamed statusnet, see http://mail.laconi.ca/pipermail/laconica-dev/2009-August/002089.html )
Hi folks, I'm been thinking about this idea mostly in the context of FOAF and "social networking" portability, but I think StatusNet and the open microblogging effort is a great place to test it, and fits with Evan's "Control Yourself" motto here. There are also business model implications for companies thinking about hosting too; I'm interested on feedback there, as well as technical feedback. Please excuse the cross-post and lengthy backstory. The core proposal is in the 'Subject:' line above: can we hack the StatusNet source so it allows users to specify their preferred "root" domain name in the generated HTML? OK here's a concrete proposal in more depth - "Dockable". Dockable - backstory: The "dockable" proposal is simple: let users do more things with domain names that they own and control, and at per-user granularity so that sites can be a lifelong thing. I'd like my photo URLs at http://photos.danbri.org or http://flickr.danbri.org, rather than at http://flickr.com, however much I love Flickr. I'd like my music profile and playlists to be at http://music.danbri.org/ instead of at http://last.fm/danbri, and I'd to be able to microblog using http://status.danbri.org/ rather than http://identi.ca/danbri. A metaphor here is "dockable", in the sense that these pieces of my Web presence are a bit like boats on the unpredictable seas of the Internet (see also http://xkcd.com/256/). When a boat is docked in a harbour, eg. my photo "boat" has been docked in Flickr Bay for some years now, then it can make use of all kinds of useful, life-improving services - electricity, access to toilets, clean water, food, people to hang out with, wifi and dry land. At Flickr I get to benefit from the great community tools, giant image-hosting servers, friendly community, tagging, annotation, search and mapping tools, etc. And I know I could leave with all my data at any time; but could I leave with a working Web site that - with some loss of functionality, sure - could be moved elsewhere and just keep working? Not yet. Being "docked" - online or off - has many advantages, so many that in the real world, undocking and moving your boat elsewhere can be a big hassle. I've lived in Bristol and Amsterdam, where many boats stay comfortably docked for years. But you can do it, you can undock a boat, patch up the holes, detach cables, wires and other local services, and set out to sea, or to find another place to dock that suits you better. The freedom of movement and freedom of choice issues aren't so different on the Web. For example - with various changes at Yahoo, I'm wondering how many more years I'll keep my photos at Flickr. I know I can get my data out; they have nice APIs, and there is the Net::Flickr::Backup tool even which exports everything in RDF. The problem isn't really the data, its the identifiers and links that make the Web a *Web*. My photos profile page, the URL for each photo and page wrapping each photo; all of these are at flickr.com URLs. For websites to be as dockable as boats, site users/owners need control of the domain names that are at the heart of the URLs for each page. For classic Web sites, this is a true-ism. People don't - these days - publish serious Web sites using the domain name of their ISP or basic hosting provider. Changing provider would screw everything up, break links, create risk and dependency needlessly. For blogs, we're halfway there: many hosting providers (eg. wordpress.com) allow you, often for a fee, to use your own domain name in the URL of the blog. For IM, Jabber/XMPP allows DNS-level aliasing. For email, you can do a lot - my [email protected] email address is a Google Apps for Domains service, implemented entirely by Gmail. But for "Social Web" sites (web2, social networking, call them what you will), we have a long way to go. On Facebook, "my" stuff is always identified using URLs with facebook.com. Same goes on flickr.com, delicious.com, livejournal.com, last.fm etc. Sure, some of these sites allow me to post blog posts out to my external site, but mostly as a way of drawing in link traffic to the main site whose URLs are owned and controlled typically by some large company. I've been thinking lately that more attention needs to go on this piece of the puzzle, and less on the relatively well understood issues of data portability. Being able to get your data back is one thing; being able to keep life-long control of a site, including all it's incoming hyperlinks, is quite another. Is it so hard to imagine being on Facebook, and seeing for the bits about/from me, hyperlinks to http://watercooler.danbri.org or http://slackoff.danbri.org which when clicked, bring up pages generated and served by Facebook? Could Facebook ever be persuaded to do so? I don't know. Would they care about increased link karma? Who knows. We don't have source code to Facebook so that discussion is moot for now. Which brings me to StatusNet... Dockable microblogging - so what's the story here for StatusNet and microblogging? Well laconica/statusnet, being opensource, allows me and my friends to make our own installation(s) of the software. For a while I had a test installation running quite happily, and I could give my friends accounts and have my own mini-twitter / mini-identica experience. But the granularity of domain name is per-installation, rather than per-user. Folk with logins on my copy of StatusNet end up creating mini sites that are tied to a domain name that I control. Sure, they can take feeds and repost things on their own sites, but the basic URL patterns that form every link to their stuff, all that is using a dns name that's beyond their control. Could Laconica/StatusNet do this in a more fine-grained way? I don't know the code, but I'd like to find out. Imagine a single installation of the code where each user had the ability in the control panel to specify a domain name (eg. status.danbri.org) that is their preferred basis for all hyperlinks and documents generated about them in the site. The actual hosting wouldn't move, we're only talking about aliases here. That poor user would also have to go through the un-enviable hassle of buying a domain name, configuring it correctly via their DNS provider, etc etc. This is hard now, but it will get easier. Once the StatusNet installation knows the new alias, the relevant Apache/httpd server will also need some configuration to "do the right thing". I'd like to be able to have http://status.danbri.org/ be an alias for the excellent Identi.ca service. And I'd be happy to pay a little cash for doing so, or perhaps impose adverts on readers (if I have any!) when I'm feeling cheap. Right now, if I rig my local DNS to fake that alias, visiting http://status.danbri.org/danbri results in Identi.ca's Apache sending me "No such site.". I'd like to understand what changes would need to be made to make all this possible. Or if I've missed some practicalities that make an unattractive path to explore. Would it screw up caching? How to deal gracefully with sites that have been "un-docked" and moved elsewhere? What specs would make such migrations easier? How does all this interact with the conventions for @-messaging of other users, since it could mess up the notion that users come in large collections - ie. sites? If I undocked http://status.danbri.org/ from one Laconica installation and re-attached it to another, how - if at all - does this affect the experience of users who want to chat with me via the usual emerging microblog conventions? Would having common CSS patterns help with such migrations? Questions questions... StatusNet/Laconica seems the perfect place to explore this stuff. In 5 years time, I'd like to see Facebook/FriendFeed, MySpace, LinkedIn and the other biggies to be competing to host user-controlled mini-sites, and for their users to be able to migrate content/sites between these hosts with greatly reduced friction. IMHO the DNS piece is a much neglected part of the larger puzzle, so I'd love any feedback on these thoughts, especially from those who know the StatusNet codebase or who could implement it elsewhere. The general case of social-site content migration is pretty complex (cf. all the details in OpenSocial); by limiting this exploration initially just to microblogging (especially given the OMB work) at least we have a relatively core simple site structure that hangs everything together. If this can be made to work for microblogs, then more complex sites might follow. Apologies again for the crosspost, I'm happy to move this onto foaf-dev if it drifts away from StatusNet issues, but I wanted to air it in both places initially... cheers, Dan _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
