Anyway, thank you for the quick response.

If you define a useful set of conceptual entities and the canonical communications between them, then you have an interesting new tool for describing deployment scenarios where multiple entities live in the same “software body” vs. where they don’t.

A non-ProtectServe-related example is the concept of a “user agent” communicating with an HTTP server. By defining the basic communication mechanisms of a user agent, you can discuss browsers, RIAs, and various other software that embeds (maybe multiple) user-agent interfaces more intelligently.

This isn’t an original point, I’ll admit. :-) It’s just a consequence of protocol design.

In plain english, that means “we think that the thing to do is tie together the relationships between separate services and/or objects, rather than centralise them” – yes?

Yes indeed, the phrase “turning people into X” is a bit infelicitous, though I was just picking up on other usages I’ve seen in the VRM context. In a previous preso (see slide 13), maybe I did a better job of this, discussing the pair of asymmetries going on here: a customer needs to be able to face vendors more as if he/she were a big web server, and a vendor needs to face customers more as if it were an individual.

My intent is that our approach is compatible with the Mine approach, in that a Relationship Manager could itself be a service provider for any data the user cares to self-host, with Atom feeds in particular — even if their entries point to data residing elsewhere — being a natural fit. Our assumption has been that an individual’s data may continue to be multi-sourced for a long time, and so it’s convenient to get the benefits of an authorization hub even if the data isn’t kept at the same place.

In our work, we’re finding that, with a set of clearly defined entities and a clear protocol between them, it becomes possible to compare architectural approaches that choose to co-locate two or more of the entities. Stay tuned for some comparative diagrams on that very soon.

I am driven to respond to your “turning the customer into a platform” quote; something is bugging me about it.

I think it’s the difference between “turning people into predetermined X” versus “giving people new capabilities” – I go for the latter because I believe that VRM is not about turning people into robots which are better equipped to buy stuff – but instead I believe it’s about putting ordinary people on parity with the rest of the commercial world’s technology, and giving them control.

That may be phrased as turning them into a platform, I suppose – but I don’t see “platforming” as the predetermined or inevitable outcome.

As for the software I appreciate where you are trying to go and why, and I find it very interesting – for obvious reasons I prefer The Mine Project’s approach to the problem, as written-up at http://themineproject.org/index.php/mine-papers/ (though the paper needs a refresh to match the implementation) – because I don’t like unnecessary multiplication of intermediaries, in fact I prefer to reduce them. :-)

But it is very interesting.

Best wishes,

- alec