Think of it in terms of SMTP and e-mail. Mail providers come and go, but nobody has to move email providers because all their friends changed emails.

"popularized" is the most important and hardest part, you can't risk using it in an assumption. The problem domain you are working in is the exemplar of the chicken-and-egg user growth difficulties.

Also if it really was just a protocol: the only thing being developed would be QuickSocial, it would not be called a social network because a protocol is not the place creating the social experience, it would be marketed to developers and bloggers as an improved and easy to add replacement for OpenID, 50% of the work would be on rigorously defining QuickSocial specification, the other 50% on developing plugins for all platforms and languages.

That's part of the plan. QuickSocial is being developed as an abstracted PHP class library that's quite easy to implement.

I'm biased because I'm working with c++ but I'd suggest the protocol be developed like most protocols - in a language neutral fashion. This involves writing it in a fashion akin to an abstract language. Normally, such a protocol spec simply say what byte means what and where each byte goes. Then the protocol can be implemented in any language.

For example: http://en.wikipedia.org/wiki/Http

Also, I'd suggest only creating a new protocol for things that really can't be done existing protocols (such as Internet mail). You always layer your application on top of an existing protocol if it serves your purposes.