What Diaspora Should Do with their Newfound Fuckyoufacebook Money
blog.nextny.org
blog.nextny.org
What do you think?
But their plan seems really good - do as little practical themselves, produce a good protocol, go from there.
I'm look forward to their plan.
Get to work, build a product. Build a good product. The rest will fall into place.
As much money as they received brings its own responsibilities. They already have too much to just write something and then see what happens.
Writing some code isn't the first step here any more than "fire some bullets" is the first step towards invading a country.
I agree that it's easy, but it's also time consuming. They originally gave themselves 3 months -- that's a vanishingly small amount of time to produce any kind of fully working product.
The first revision of Facebook (then Thefacebook) was written in about one week, IIRC.
(Diaspora guys, if you're reading this: good luck!)
Yishan Wong, Worked at Facebook from 2005-2010.
"As it stands, based on available technical and product details, Diaspora is the dumbest idea since OpenID.
Whereas OpenID absurdly required you to login using a URL (luckily no longer a requirement) in order to preserve your privacy, which no one really cares about, Diaspora apparently requires you to run your own set of web hosting services in preserve your privacy, which no one really cares about.
However, there are a sizable number of people who think they care about privacy, so there is a market for Diaspora.
The main problems with Diaspora being a successful parallel social network are: Most women will not use it. See reason #1.
Instead, I will describe a product formulation for Diaspora that I believe could be successful and achieve reasonable user adoption, by exploiting interoperability with Facebook while providing user-driven privacy controls. Diaspora guys, are you listening?
First, dispense with the personal hosting solution. This is a non-starter out of the gate. Anyone who is willing to run their own hosting solution (virtual or not) should just erase the personal details from their Facebook account, put their content on a personal webpage, and list the address for the webpage on Facebook. In fact, that's exactly what the web was in 1999.
Rather, this is how you do it for Diaspora. There are two key ideas:
People are unwilling to share personal information according to Facebook's defaults, but there is nothing preventing them from having an "empty" Facebook account populated with none of this personal information. Facebook does not (and cannot, physically) pull information from user accounts on third-party applications. Facebook can do what it will with information entered by users into its website, but information stored by third-party applications can't be taken and used by Facebook. (Technically, Facebook may cache this data in intermediate formats when it is rendered, but they would have to be really deliberately evil to be intercepting this data and using it)
Therefore, what Diaspora should do is become a Facebook Connect app. The irony here is delicious - users who wish to use Diaspora as a "privacy-oriented" Facebook will then do the following: Delete all their personal information on Facebook except for their name and perhaps an innocuous profile pic. Use Diaspora to provide all other core Facebook-style services, including the profile info fields.
Then, Diaspora renders itself either as canvas page or a profile tab, and displays the user's profile info for the user when other Facebook users browse to that user's page.
What this does is it places all of the user's personal information on Diaspora servers, which Facebook can then no longer access and send to third parties. Access control is provided by Diaspora (rendering of the profile tab or canvas pages can be controlled depending on who is viewing it). Users can still interoperate with other Facebook users, so they don't need to migrate their social graph, which is the greatest hurdle to Diaspora's adoption.
Diaspora can then offer users the options to store their information in an encrypted format (accessing this smoothly on behalf of friended users will make the product somewhat more complex, but I think it can be done by delegating keys properly), and make available the application code for inspection. They will still have to trust Diaspora's hosting to be running the same code, but I will describe a way to handle that.
Diaspora can open-source the code and allow other Diaspora installations to be set up, in case users don't trust Diaspora itself - a particular group of real-life friends who mutually trust each other can just host their own Diaspora installation and store their own information there. They will need to create a new app on Facebook but that's pretty okay - it will become known as a "Diaspora-style" profile if it ever becomes widespread. People will even be able to keep accounts on multiple Diaspora services, for the purposes of segregating their data, if they wish. The codebases for these services will also inevitably evolve and advance.
Interestingly, Diaspora does not necessarily need to provide photo hosting, events, groups, and other core Facebook services (but it can). Users can already exploit this property of Facebook not being able to access third-party data by using other photo hosting applications that they trust, and the same goes for all other applications. In fact, this is true today. The irony is remarkable, because much of the privacy worries center around how third-party sites can now access user data, but by flipping this around and placing the user data securely on a third-party site that makes itself a Facebook application, Facebook cannot access that data and thus give it to any other third parties. This is even the case when these third-party sites use Facebook Connect for their authentication, because it still only credentials the site to access Facebook data via API calls; it doesn't give Facebook the ability to pull stuff off of a third-party app's database or anything - the app itself is in control.
What is more, users can select the amount of privacy they want to personally protect. To transition, a user doesn't actually have to delete all their profile data off of Facebook (say you don't care if Facebook shares your hometown with the world, but you do care about your relationship status) - deleting all your Facebook data can be laborious. The user just deletes the fields they want to make more private, and transitions only that data on to a Diaspora service. It can then be managed with whatever higher-granularity and/or opt-in access controls provided by that service; the remaining data on Facebook that the user doesn't care as much about can remain under Facebook's dominion.
By allowing open-source clone services, every "clique" of users only has to rely on the local nerd to set up an installation, and all of the users in that clique will be able to migrate some or all of their data from Facebook onto their Diaspora service, and continue using Facebook without having to migrate their social graph.
Lastly, based on my understanding of the views and temperaments of Facebook's executives (including Mark Zuckerberg), they wouldn't ban this app and would in fact tend to look rather favorably on it, if with a bit of initial chagrin."
>Diaspora apparently requires you to run your own set of web hosting services in preserve your privacy, which no one really cares about
To me, this reads the same as "having an email address requires you to run your own email server". If Diaspora takes off, I'm sure it will be another check-box on ISP features lists.
I think the idea of a Balkanised Facebook is a good one, esp. if was business related. Keeping in touch with customers and aligned groups in a relaxed place but without the threat of one of your personal friends posting pictures of what you did on your drunken weekend away.
Great services like Gmail only became possible because SMTP isn't tied to a particular proprietary service. Individuals can use the service that's most appropriate for them. For some people, that's Outlook, for others, a webmail provider. Competition works.
What we really need is a system that crosses social-networking-service providers in the same way that SMTP broke down the barriers between various mail systems.
Would you rather have Facebook employees, who don't specifically know or care about you have access to eg. personal conversations btw. you and your friends OR your friends, who might be the ones you're talking about?
The other solution is for the "local nerd's" set-up to never view unencrypted data. If you watch the Diaspora* intro video, they are talking about having encrypted content available for each friend… if this encrypted content were uploaded to the local nerd’s server, that solves the untrusted admin problem.
No, the greatest hurdle to Diaspora's adoption is that Facebook doesn't provide the user with any means to export their own part of the social graph -- and in fact takes legal action against people who do.
I'm not interested in the argument of whether Facebook legally can or can't do this; the point is, for many people, this is not a world that they want to live in. Your suggestion doesn't do anything to address the central problem.
My next social networking service is going to provide me control over my social graph. It should also allow me to port basic profile features from one hosted service to another, much as I might do with an email address or a web site.
You're right that moving people off Facebook is going to be difficult, as there is a sunk cost issue. However, I doubt that the establishment of a Facebook-scale social network is going to be a unique event in human history, any more than MySpace or Friendster were. It may not be Diaspora that coaxes people away, but people will take the trouble if there are benefits to be had, and Facebook can't entirely stop all the tools to export friend lists.
Diaspora does not necessarily need to provide photo hosting, events, groups, and other core Facebook services (but it can).
Once again, the whole point is to interoperate seamlessly with services outside anyone's walled garden, especially for commonly shared items like photos, events, and discussion. It is already deeply annoying to have to make separate invites for Facebook and non-Facebook friends. I can't believe that you are even seriously proposing a dual system this while touting your own expertise on what users really want.
BTW, I personally have tried to make an FB app that unified Facebook events with events from other services such as Upcoming.org, and FB's API thwarted me in this regard. Certain bugs made it impossible to distinguish between the user's private and public Facebook events, so my app was inadvertently publishing private events to their FB page. Some of my users complained loudly about this -- you know, that privacy stuff that users don't care about. So I determined this was due to a FB API bug, but amazingly the developers WONTFIX'ed it as a documentation bug (the assertion that the API provided privacy was the "bug"!)
But that's what we get for relying on a service provided by kids just out of college who think they're god's gift to programming.
So, no, I'm not buying that one again.
No matter how well-funded, Diaspora is just one team with zero track record, so they're not likely to be the solution to these problems. But I'm definitely looking for something that fits the bill, and I highly doubt it's going to be a Facebook app.
The private Events is a very good exemple of why cross-platform scuks, but I don't see any other option than trying anyway.
Why do I see the scene in the Matrix when Agent Smith would touch someone and they would become another Agent Smith when I read this?
Looking through the 'friended' pages of people with empty profiles can give a significant amount of information on the people whose profiles are blank.
I can't help but feel, uh, angry, at experts - Wong or Zuckerberg or whoever - who claim that no cares about privacy, they just "think they care about privacy". When employers, potential employers and potential-stalkers are all actively Googling people, a large portion of the population should care about privacy. I'd say the opposite is true to Wong's glib statement - the people will care more and more about privacy as they learn all the implication.
Anyone who's vulnerable in one way or another will care about privacy - the simplest examples are employees who's job situation is insecure and women and children who might face threats from stranger. Anyone that a state might look askance at would another example (and it's not just the US state).
Create a repo
Post code
Accept patches
Tag releases
Maybe set up bounties for feature requests? The money kind of fucks up typical OSS dev projects, now that I think about it. But there are more than enough OSS hackers out there that will help. And having a "blessed" project helps too.
I'm eager to contribute actually.
If I was them, I would spend the next few weeks figuring out what it is their building.
Having a blog is probably a great idea for them though.
Are there contractual obligations of raising money with Kickstarter, or can they use this for legal fees?
If they can't use the money for a startup, I doubt they'd have trouble raising money for a company separately, though investors know that any software product developed will be open source.
In particular, there is some real, actual, working code: http://www.socnode.org/code, using PubSubHub for near-instant updates across multiple distributed sites.
The code there is in Python, but there is a (my) half-Java implementation linked from there too.
It's a nice simple idea though, and perhaps it could be one layer of a solution.
1. Get organised.
2. Code for 3 months and then stop for some time and keep 10,000$ for the effort.
3. Start an Americal Idol/The Apprentice like program to create actual code in phases.
4. Setup a Jury with 3 luminaries like Bruce Schneier as judges.
5. Opensource projects can participate for bounties to create various pieces of the jig saw puzzle. The entire contest would not involve any actual travel. Just a mob of coders checking into GitHub and Google code and so on. Their own code also gets to participate in the contest ;-).
6. Try get guys like Larry Page involved... LOT of people apart from the poor geek on the street want to see FB dead ;-).
Note: These guys are celebrities now. They can easily become notorious. They are young. The best thing for them to do to themselves is to not get a bad name by blowing away the dough. If they keep the money away/use it as a catalyst for the FB killer, they will earn goodwill worth millions.
They can "encash that goodwill" over time. With their skills+goodwill they can at a future date start a real startup through a program like YC maybe even in an entirely different domain, and earn fortunes. Their greatest asset right now is that a LOT people will now listen to them for a short time. If they manage to pull it off, even more people who matter will LISTEN to them. That would translate to a lot more than the millions they may raise right now.
Wishing them luck. Hope they will be billionares some day. but not from donations, but from a real startup they create in either social networking or another area that really brings value to its customers.
Sudarshan.P
Then fill out the more distributy bits later.
----
[1] http://cloud27.com/ its BSD licensed (IIRC) so should be good to clone/fork immediately