Questions for the Diaspora

So lots of friends were tweeting this morning about Diaspora, a project to raise funds to get a summer’s worth of hacking done on a distributed, Libre social network. A distributed, Libre social network would be a terrific thing to have; I’d love to support it. And I love the eager energy I’m seeing around Diaspora.


Questioned Proposal, by Eleaf, used under CC-BY

But I’m also keenly aware that distributed social networks are hard, and so I’d only give of my money (or my time) to someone who looks like they have what it takes to take a serious stab at the problem. They’re hard:

  • as a design question: how do you make a social network whose UI doesn’t suck?
  • as a technical question: the code involved is complex, particularly if you want to interoperate robustly with other platforms, and doubly so if you want to do that with proprietary platforms.
  • as a social question: getting users to migrate is not easy.

So here are some questions for Diaspora, or really for anyone working in this space. These are not questions with right answers, necessarily. But anyone serious about solving this problem probably has at least some answers for them, so showing that you’ve given them some thought will go a long way towards convincing people that you’re serious about attacking the problem. If you haven’t given them thought yet, I could think of worse places to start. :)

  • What do you think are the most important features a social network should have? How would you prioritize them? Do you plan to Build Less or go big? If building less, what is the minimal set of features you can get away with?
  • DiSo is now two-plus years old. Any ideas why it didn’t get off the ground? Bonus points: same question for Mugshot.
  • What standards, if any, do you plan to work with/build on? (just to throw out a couple, all of which have strengths and flaws to consider: webfinger, oauth, xauth, the buzz APIs.)
  • What other services, if any, do you want to interoperate with? why? how will you prioritize?
  • Any other Libre code bases in the same space you’d like to work with? GNU Social? StatusNet? What ones are you aware of, and why will you/won’t you build on/work with those?
  • Would a smarter client (like Mozilla Contacts) be useful to you? If so, how?
  • What is the strategy to get to a critical mass of users (or avoid having to get a critical mass?)
  • What are your three favorite books on software development? three favorite essays? what about on design?

I don’t mean to ask these questions to piss on anyone’s parade; I deeply want to believe. Heck, what I want to do is fly to New York, sit down in a room, and help you brainstorm and plan. But unfortunately I’m a pragmatist with a day job. I can’t directly help out. So instead I offer these questions. Answer these1 and you’ll begin convincing people that you are also pragmatists: that you’ve thought hard about the questions at hand and you are worth investing in. And I’ll be first in line to do that.

(I should note that unlike some I don’t need code; I think code that is created without much thinking is all too common and frequently damaging. But if you don’t have code, I suggest doing planning- and talking about it- before doing a PR week. :)

  1. or questions like these- you’ll note I skipped some hard ones like ‘business model?’ []

wesabe ‘data bill of rights’

Wesabe’s Marc Hedlund is speaking at the Princeton Cloud Computing seminar I’m at. Their ‘data bill of rights’:

This Data Bill of Rights is our promise to you.

  • You can export and/or delete your data from Wesabe whenever you want.
  • Your data is your data, not ours. Our job is to help you understand and act on your data.
  • We’ll keep all of your data online and accessible for as long as you have an account. No “archive access” charges.
  • Any data you want us to keep private, we will.
  • If a question comes up not covered by these rights, we will answer it remembering that your data belongs to you.

Interesting. My intuition is that this is a really good start in the right direction for web apps; he himself notes, though, that it isn’t legally binding. They are considering doing that- will be very interesting to see that if/when it happens.

Voting With Your Feet and Other Freedoms

This Post In A Nutshell (aka, the Murray Version)

No one should be surprised that social network users can’t ‘vote with their feet,’ because most users give up a portion of their autonomy when they choose to use web services. This post will suggest that protecting autonomy is desirable and should be designed in to software, and outline five qualities that such software would have.

[The rest of the post will not be brief; it is in part a draft of an essay for my class in ‘Law in the Internet Society’.]

Continue reading “Voting With Your Feet and Other Freedoms”

the Live Journal sale as something more than corporate transaction

A former co-worker of mine writes about the Live Journal sale; in particular, she has raised concerns in the past about content censorship on LJ and the impact that has on LJ users as citizens. Worth noting (from the comments) that LJ is free software, but that that only partially protects anyone- my friend’s network of friends and content is still tied up in LJ.com.

Heated Debate, by MrIcon, used under the CC BY-SA license (found by a flickr search for “russia you”)

This is just another example of a recurrent theme from our future: what happens when essentially amoral corporations own, and can sell, what amounts to significant part of our identities? Say what you will about Microsoft, but they can’t sell Office to someone and then retroactively turn over all your documents to the new KGB. (Or at least, we don’t think they can ;)

In the very long term, the answer may well be transparent protocols and self-hosted services (like we can choose for email already), but in the medium-term, we’re going to have to figure out something which doesn’t require people to host their own services, but still protects their data and their identities.

on ‘the cloud’

‘Trapped Clouds’ by Chris Kovacs, used under a CC-BY license

A wise and wonderful friend emailed me to say that he was glad my posts last night did not say ‘web 2.0’, as in his wise opinion ‘web 2.0’ is a pile of hooey. On this we are in deep agreement; there is no deep substance in web 2.0 that desktop apps can’t replicate.

He said that he preferred ‘the cloud’, but that he thought it was roughly the same thing as ‘software as a service.’

I’ve spent the rest of the morning intensely bothered by the phrase ‘the cloud‘, but I couldn’t quite put my finger on why. Now that I’ve breakfasted and am more lucid, some thoughts on why it irritates me so much:

  • the cloud’ implies that there is one, seamless pile of data into which your data goes. This could not, of course, be further from the truth- there are a pile of small clouds, most of whom have barbed-wire fences between them. When you go to the cloud, you go to a cloud, with particular rules, regulations, and behaviors, and a language which 9 out of 10 other clouds can’t speak.
  • ‘the cloud’ is white and fluffy and peaceful; the reality is that the various clouds are fighting each other to the death, and (typically) fighting you to make sure that you don’t leave their cloud once you’ve chosen it.
  • I think above all else, ‘service’ has known properties- we know it can be useful; we know it can also have catches and fine print. We have deep and useful intuitions about services. Focusing on ‘service’ brings these things to the forefront, instead of distracting people with a metaphor which brings no useful information to the table and which (as I pointed out above) can actually be substantially misleading.

I should note that part of why I picked google mail and not, say, yahoo mail, or some other solution, is that gmail is actually very good about letting you leave to other clouds. Despite being in ‘a cloud’, my mail was always available via POP and my addressbook in CSV, and now it adds IMAP and vcard. They have so much confidence in their software that they make it easy to leave, knowing you probably won’t. Still, this type of thing should be an expectation for services, not a pleasant surprise.

so Luis uses gmail. So what?

The lesson of this last post is not about gmail in particular; it is that web-based software, provided as a service, isn’t going away. If anything, it will keep expanding, because the user benefits are of a sort that traditional, user-managed software will have an extremely hard time matching.

It isn’t just that web-delivered software can be very flexible (especially once greasemonkey is involved), or as powerful as all but the most powerful rich client software, or that it can be really convenient to have access to your data at any time and any place, or that it is nice to be social and trivially share things with friends. All those things are very nice, but none of them are particularly exclusive to the software as a service, and traditional software either already does better or can catch up if it wants to. If these were the only questions, I’d put my money on locally managed software.

But these relatively shallow software features aren’t the only issues. The problem here for any provider of locally-managed software, be it the Free Software Foundation or Microsoft, is that software as a service is a different architecture; an architecture which provides features which go outside of pure software. Most importantly, this architecture abstracts away the most hated and unreliable parts of the self-managed software ecosystem- hardware, support, security, and maintenance. Those are someone else’s problems- all you have to do is log in and use the software. In Jesse’s words, ‘I no longer have to worry.’

In the locally-managed software world, those issues can be truly resolved only with redundant hardware in redundant locations, reliable bandwidth, complex mirroring setups, and the application of lots of manpower, both to set things up and to minister to them when they go wrong. You can improve every part of the system, but the need for time, maintenance, and redundancy will never be completely eliminated. Hardware and software will always require maintenance, and time and skill will be needed to resolve the inevitable failures. The million dollar question is whose responsibility these things are. Hosted software promises to make that responsibility go away, so that you can focus on other things and sleep easily at night.

In an age where everyone has gigabytes of data to back up, hundreds of pieces of software to keep up to date, and so on, this ability to sleep easily at night – to not worry – to put the responsibility on someone else’s shoulders – is not to be undervalued. People will make many compromises, in functionality and in other freedoms, in order to reduce that worry and get that security. Of course, the security provided by some (all?) of the hosted service providers is to some extent illusory. Hosted service providers can be subpoenaed, or fail, or decide to hold your data for ransom. But people strongly believe (with some reason) that software and hardware are even more likely to fail, and at high cost given the centrality of our data to our lives. So until that expectation changes (either because service providers get worse, or because self-managed software gets radically better) software as a service will only become more common.

The implications of this for personal freedom will be the subject of an upcoming post; suffice it to say right now that we need to start thinking about principled services now so that we can design and implement them.

why I use gmail (or, the list of daily worries of a self-hoster)

In class Thursday, during a discussion of privacy and security, Prof. Moglen asked me how I do email; I told him gmail. I was going to write a long post explaining why (which will probably form part of an essay in the near future) but Jesse nails a fair number of them in one sentence:

Now, I no longer have to think about keeping spam stuff up to date, no longer have to worry about that next security vuln …, no longer have to worry about having a decent interface for getting mail from mobile devices, etc…

I’d add no longer have to worry about storage space (at least not for future emails); not have to worry about data backup; not have to worry about hardware failure and reliability; not have to worry that I can’t leave (since I mostly ‘hide’ @gmail behind @tieguy.org).

Jesse and I are not alone in this- gmail is the most popular user-agent at gmane.org, and an lkml admin tells me that over half of current lkml subscribers are @gmail.com. (This bleg was unsuccessful in getting Debian data, but I imagine their numbers are similar.)

Prof. Moglen is right to worry about privacy and security, but for the vast, vast majority of us those are very irregular problems. If they have non-trivial impact, that impact is once or twice in a lifetime. The problems I’ve listed here are all daily problems with self-hosted email. (You can take steps to reduce some of the worry, but you still have to use your precious time to recover when things go wrong, and you have to do it on the hardware or network’s schedule, not yours.) Solving daily problems at the expense of once-in-a-lifetime problems is a tradeoff most people will happily make. So gmail and the like are winning, and will win for the foreseeable future, even amongst those like Jesse who are skilled in the fine arts of software maintenance.

This is principled software’s biggest challenge- not how to stay relevant in the face of google’s vast server farms (which are important but not insurmountable for many classes of service), but how to stay relevant in the face of how convenient centrally-hosted web software is for both users and developers.

[It doesn’t hurt that gmail is very nice software. The keyboard nav is very good, search is powerful, conversation view is the first real innovation in email in ages, archiving of IMs as emails is so blindingly obvious that I’m still shocked no other mail/IM pairs that I know of do it, and the intense scriptability (which is now officially supported) means I have more plugins for this than I used to have for evo. None of these were the things that pulled me away from evo, though- it was all about not having to have the responsibility of running my own server.]