almost 10 years on 2009-02-19


...a case for separating 'i/o' and 'network'

over the last few days a mini saga has played out over the question of a seemingly small change to facebook's terms of use.  before going any further, i just have to say that i have the utmost respect for the fb folk and do genuinely trust them with information.  i think that the magnitude of the reaction people had to a slight and seemingly necessary change in the terms of use given their current and future business was far far over the top and unwarranted.

that said - the issue of facebook's terms of use strikes at a much deeper and more important issue around information ownership given different types of services and application architectures.  these issues are going to only get more intense over time.

facebook's service is designed to syndicate content.  it needs to own your data to push it out to the parties that the service is designed to serve....  this is because it is both a content host, and a network.  it actively takes your information and p ushes that data out to your friends.  as mark explained in a blog post --

"when a person shares something like a message with a friend, two copies of that information are created—one in the person's sent messages box and the other in their friend's inbox. even if the person deactivates their account, their friend still has a copy of that message. we think this is the right way for facebook to work, and it is consistent with how other services like email work."

that is one way to build applications, but it isn't the only way...'s approach to data ownership is very different, and it allows us to give you full ownership and control of your information and how others interact with it.  we simply allow you to put information in a drop, and then when you 'share' it based on the permission set you establish for content within a drop, you define specifically how the content can and does move.  check out our terms of use and you will see how this plays out - we don't duplicate your content into other people's 'inboxes'/spheres of control.

because we only handle the input, access, and ouput of content and have no associated 'index' or 'network' we simply don't face the same issues that facebook must wrestle with about data ownership -- the ownership parameters are totally clear in our case, we don't own any of the content being placed in our service, end of story.

so, what does it all mean....

when you want to 'share' something on you are not making and distributing copies, instead you are simply passing on links which refer back to your drop.  so, if you want to share content you own and have placed on, you can simply push out a link to your facebook network via facebook connect, or via our twitter integration, or via email, rss, and a bunch of our other 'output' options....  none of these 'networks'/distribution channels end up 'owning' or needing to duplicate anything more than url pointers.

we hope that this becomes the option of choice in the future, where data i/o is divorced from distribution networks instead of being conflagrated....  in an always connected world, there is no reason for i/o and 'network/distribution' to be encapsulated in the same entity, as it clearly only causes problems...

the model of content hosting and distribution of the future allows you to keep your information somewhere you can flexibly exert total control, and push out links/pointers across the social and searchable web.  that way, when you are done you can efficiently close shop, and you don't have to worry about others needing to 'own' your content to be effective.

i see this as a big part of the future of privacy and dealing with the control of massive amounts of asymmetrical data in a massively accessible environment

original swl blogposts and letters 2007-2010