4 ms·

> Once an open protocol is established and popularized "popularized" is the most important and hardest part, you can't risk using it in an assumption. The prob

> Once an open protocol is established and popularized "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.

michaelchisari 16y ago
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.
- joe_the_user 16y ago
  Maybe I'm being patronize and you know all this all but I'll just note that a protocol is about one level of abstraction above a class library. 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 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.
  - michaelchisari 16y ago
    Nothing about the protocol is PHP-specific, but the initial implementation is written in PHP.

michaelchisari 16y ago

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.

joe_the_user 16y ago
Maybe I'm being patronize and you know all this all but I'll just note that a protocol is about one level of abstraction above a class library. 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 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.
- michaelchisari 16y ago
  Nothing about the protocol is PHP-specific, but the initial implementation is written in PHP.