npm is great for libraries, but what are the implications for publishing apps?
I have a node app that I'd like people to be able to get easily, but it's really meant to be modified to suit each person's needs. Right now I just have people clone/fork a git repo; what would be the process for that if they were using npm?
This question comes up often, we should all have a Federated Social Web FAQ we can point to. :)
There was a Federated Social Web summit in Portland in July 2010, organized by StatusNet, and possibly another one coming up this summer. We have a mailing list, and there's fledgling W3C working group involvement.
We're all interested in how to shape a protocol that we can all use. The territory is a little wild west at this point, so some of our approaches differ, but this is a major component of the work all of us are doing.
I'm aiming for happy users. We have enough unused protocols specs floating around.
Happy users come from good web and mobile clients and a good project goal (open, privacy you control, multiple server codebases, business friendly (they can spin up a social network without hooking their wagon to FB))
Good clients need good APIs: secure, realtime, mobile friendly (quick syncing, good geolocation). APIs also need to be easy to implement for people familiar with http (the core protocol leverages XMPP's message passing architecture)
And all this needs a good architecture that builds off good federated systems.
So the end goal is to build something the right way and for the right reasons. If we can execute on that, I believe we will make users happy.
A good solution will sidestep every potential fail moment. We've sidestepped a few so far and I'm really happy with the quality of developers that are contributing client and server work. The good protocol is incidental.
11 comments
[ 3.1 ms ] story [ 31.9 ms ] threadadd this to your /etc/apt/sources.list: deb http://debian.jones.dk/ sid freedombox
and execute "aptitude install channel-server"
I have a node app that I'd like people to be able to get easily, but it's really meant to be modified to suit each person's needs. Right now I just have people clone/fork a git repo; what would be the process for that if they were using npm?
Are we aiming for a protocol end goal or for an application end goal?
There was a Federated Social Web summit in Portland in July 2010, organized by StatusNet, and possibly another one coming up this summer. We have a mailing list, and there's fledgling W3C working group involvement.
We're all interested in how to shape a protocol that we can all use. The territory is a little wild west at this point, so some of our approaches differ, but this is a major component of the work all of us are doing.
Happy users come from good web and mobile clients and a good project goal (open, privacy you control, multiple server codebases, business friendly (they can spin up a social network without hooking their wagon to FB))
Good clients need good APIs: secure, realtime, mobile friendly (quick syncing, good geolocation). APIs also need to be easy to implement for people familiar with http (the core protocol leverages XMPP's message passing architecture)
And all this needs a good architecture that builds off good federated systems.
So the end goal is to build something the right way and for the right reasons. If we can execute on that, I believe we will make users happy.
A good solution will sidestep every potential fail moment. We've sidestepped a few so far and I'm really happy with the quality of developers that are contributing client and server work. The good protocol is incidental.