The Don Box discussion about HTTP was a good read with valid points.
From a P2P, not a web services perspective, we need to guarantee certain capabilities in P2P services that we take for granted in more traditional client/server environments. This includes the following:
Transaction reliability — the old two-phase commit of database technology appears again, but this time in a more challenging guise.
Transaction auditing — a variation of the two-phase commit, except that auditing is, in some ways, more fo the business aspect of the technology.
Transaction security — we need to ensure that no one can snoop at the transaction contents, or otherwise violate the transaction playing field.
Transaction trust — not the same thing as security. Transaction trust means that we have to ensure that the P2P service we’re accessing is the correct one, the valid one and that the service met some business trust criteria (outside of the technology realm with the latter).
Service or Peer discovery — still probably one of the more complicated issues about P2P. How do we find services? How do we find P2P circles? How do market our services?
Peer rediscovery — this is where the iron hits the cloud in all P2P applications I know of. You start a communication with another peer, but that peer goes offline. How do you take up the conversation again without the use of some centralized resource? Same could also be applied to services.
Bi-directional communication — This is Don’s reference to HTTP’s asymmetric nature. Peers share communication; otherwise, you’re only talking about the traditional web services model.
The file transfer nature of Napster or Freenet, and the IM nature of Jabber don’t necessarily consume all of these aspects of P2P applications, so haven’t necessarily pushed the P2P bubble to the max. However, when we start talking about P2P services — a variation of web services one could say — then we know we’re going to be stretching both our technology capabilities and our trust of the same.
Fun!