I'm still reflecting on Ring and the role of client and server in a possible Ring solution. Ton Zijlstra has the hots for a client-based approach as he says in a comment:
I find I favour a client, not a webservice. It seems more fitting to have the Ring to rule them all in my pocket. Not stored in the vault of some jeweller's. I want to own my data, especially this type of network data (even more so if the relationship data is granular like you describe: don't want Google to datamine that!), and provide access myself.
It's a completely reasonable point of view. I want to own my relationship data too. There are some issues with it though which seem to hinge on some kind of push-based approach to existing SNS's. That's okay for those that provide any kind of decent API I guess. Something that worries me is that, in essence, it seems to perpetuate the walled-garden approach. You'll be writing endless plugins for one service after another assuming they bother to let you in at all. Ask yourself this: Amazon have had an API for years but who owns your purchase history?
What I had in mind was something that creates a new space for our relationships to exist in. By defining a space for relationships as a kind of abstract social network to which any application can get access and (with the individuals permission) see someones relationships. The permission aspect is critical to avoiding Ton's no-no situation of Google indexing his relationship metadata. Of course what's to stop Google and Facebook doing a deal to index your relationship data now Ton?
I completely agree with Ton that ownership of the data is vital. My ideals at PAOGA were just the same: individuals own their data, we act on their behalf and in their interests. Same thing for any Ring service: the individual owns their relationships, Ring acts on their behalf. In my mind I imagined that service that would designed to be a commodity: a kind relationship ISP if you will. But an ISP of the old school: providing access but not looking to make a buck off the content.
The individual owns the data about his relationships and can change it, or take it away at will. The service doesn't try and compete with SNS applications on functionality built over relationships. I think there are three keys to making this kind of service a reality:
- It should be run by a non-profit foundation with a charter that protects it from becoming a corporate asset some day
- It should have a board of trustee's who can make that work
- It should be funded by subscribers and donors (but it's a non-profit remember)
With a trusted service available we can shift the tectonic plates of the SNS world and create some new opportunities.
Note that I'm not opposed to the idea of a client in principle and I do see the possible advantages. It's just that I also see so many disadvantages. The entirely push-based, API dependent nature I mentioned above being just one. Ton seems to think a client could avoid issues of ID:
Having Ring would also bypass the need for universal ID's or login's I'd say. When I list my accounts in my client, so that it can connect to each of these services for read/write actions I'm ok.
And how to do you map your contacts to those id's? I think this is just going to be a complete mess. Skype is a distributed client, but they have a central directory to allow one client to find another.
In fact from a client side perspective I think the opportunity is to bypass the existing SNS infrastructure altogether and make the client the network. Ring clients all pushing information and content direct to each other (with maybe some kind of lightweight locator service a la Skype) without the applications in between. Done right this would take the heart out of services like Flickr and Facebook.
I'm still thinking through the client angles. For example: is a relationship a shared resource with an independent existence? I see it somewhat like a child of separated parents, it can't live with both of them although both have a vested interest in it. With a service this is less of an issue because the service can surface the relationship indepdent of the individuals involved. But maybe that's the wrong way of looking at it.
It's all interesting stuff.
No, not the things from Stargate but what Ring does.
I've recently read and enjoyed RESTful web services. It's not the kind of book where I walked away, shaking my head, a changed man. But it is a warmly informative book that talks a lot of sense and, at some point, the notion of what REST puts back into the web has sunk in.
There used to be a whole bunch of people doing data storage with a bunch of different web sites offering different kinds of interface for upload files and settings ACL's and so forth. Then Amazon came along with their S3 service and changed the rules. S3 created a platform for controlling arbitrary data with a simple RESTful API for storing, retrieving, and managing that data. They didn't care what the data was and they created a uniform interface for working with it charging by volume stored and transferred.
From this simple seed a thousand storage based ideas and applications have bloomed.
Isn't this exactly the kind of thing we are looking to happen in the SNS space? At the moment it is dominated by a bunch of big players who are, sooner or later, going to be owned by big media companies. They have little interest in working together or giving you ownership of your identity or relationships. By and large an API's, if it is provided at all, is a means to create sub-applications to further lock you in, not to open the walled-gardens.
I envisage a Ring service doing to SNS what S3 has done to storage, creating a fertile new ground. The Ring service would allow people to store and manages identities and relationships whilst being agnostic about those identities and relationships. It would provide a uniform, RESTful, interface that would allow any and all applications to play. Any walls in this garden would be those erected by users, around data that they think is sensitive not barriers to interoperability and profit generators.
Let profits come from building useful applications on top of this platform. MySpace, Facebook, they can all come and play here: if they have your best interests at heart.
I use TheyWorkForYou.com to track what my MP, Theresa May, says in Parliament. For example she asked a question about bonuses for Home Office civil servants, here is the answer:
2002-03 - 115 out of 185 SCS staff received performance bonuses. The total costs were £463,552.
2003-04 - 138 out of 215 SCS staff received performance bonuses. The total costs were £672,409.
2004-05 - 180 out of 219 SCS staff received performance bonuses. The total costs were £1,187,000.
2005-06 - 158 out of 232 SCS staff received performance bonuses. The total costs were £1,071,118.
I assume SCS means "Senior Civil Service". Given the stellar performance of the Home Office in recent years it seems only fair that 70% of senior staff should be rewarded with large bonuses taken directly from my back pocket.
Joel Spolksy has a good article on management books in which he quotes Michael Lopp:
The disagreement reminded me there are two distinct personalities when it comes to devising solutions to problems: Incrementalists and Completionists.
Incrementalists are realists. They have a pretty good idea of what is achievable given a problem to solve, a product to ship. They're intimately aware of how many resources are available, where the political landscape is at any given moment, and they know who knows what. They tend to know all the secrets and they like to be recognized for that fact.
Completionists are dreamers. They have a very good idea of how to solve a given problem and that answer is SOLVE IT RIGHT. Their mantra is, "If you're going to spend the time to solve a problem, solve it in a manner that you aren't going to be solving it AGAIN in three months."
I think the discussion that Paolo and I are having about Ring is neatly framed by this division. Paolo is, I think, a classic incrementalist and I am a classic dreamer completionist. If I've changed over the years it's that I've realised (due in no small part to acknowledging the things that people such as Paolo and Dave achieve) that I am a completionist and how much it colours my judgement. Realising that makes it easier to compromise.
Just a thought but we've been talking about relationships, content, and I wonder if comments - which are still a problem - might be solved as part of this problem?
We're talking about a client, or a service, that allows us to establish relationships with each other and maybe, in due course, attach metadata like trust to those relationships. Might this allow us to create a distributed solution to comment tracking (a la trackback) that isn't prone to spam problems?
Dunno, just musing.
I pushed another auto-update of Diffly to version 0.8.3. It contains a few more small, but meaningful, improvements. The most obvious is new buttons on the toolbar for selecting & deselecting files (to go with the keyboard shortcuts) and a toolbar field for filtering which changed files get displayed. This is something I've wanted for quite a while when working in a working copy with a lot of changes.
Note that updating alone may not get you the new toolbar items because toolbar configuration is saved as a preference. If you don't see them hit the "Customise" button on the toolbar and either drag the individual items or the default set onto the toolbar. After that you should be set.
There are also two more subtle improvements that, nevertheless, make Diffly a little nicer to use. In previous versions when you added or reverted an item it refreshes just that item. For things you are reverting this never made sense at all because, after being reverted, the item no longer has any changes and shouldn't show up at all! It wasn't a problem per se but it looked unpolished. Worse was when a folder was added. Subversion automatically adds everything inside the folder too but none of those items would show up, you had to manually refresh to get them, from 0.8.3 onwards you won't.
Assuming none of the auto-update guinea pigsusers report any problems I'll update the website version over the weekend. I also plan to do a screencast and maybe even write some help. Talking to people has demonstrated that, basic as it is, Diffly could still stand to be a little easier to figure out.
I have just one more feature that I plan to add before I call it 1.0, I want to be able to hide files with changes. Sometimes I make a change to a file knowing that I'm never intending to check it in. Yet the file still appears in the changes table which is a distraction and there is the risk I might check it in by accident. I think Subversion even supports this through the [Global Ignore] runtime option so it ought to be easy to add. One wrinkle is that I want it to notice if the file has been changed since it was added to the hidden files list in case I made a new change that I do want to check in.
I've registered another Google Code project for Diffly. I think 1.0 would be a fitting time to make it open source.
