I guess it is not distributed (meaning I can run my own Quoddy server, and talk to users at friend's Quoddy server)?
Well... there's not exactly a notion of "distributedness" built in. That's on the wishlist (and, in fact, this project sprung out of a much older project that had that as it's core idea) but there is support for receiving and display messages from any other arbitrary system that supports the activitystrea.ms protocol. So modifying Quoddy to emit, as well as consume, activitystrea.ms messages would give you a way to achieve a degree of "distributedness." And that wouldn't be a hard change to make in and of itself.
The trickier part would be how to say "I want to receive updates from remote user $FOO when they come in" since $FOO is probably not a user on your local Quoddy instance. Once we have FOAF support implemented, it would be easier to talk about navigating the remote social graph and connect to non-local users... but a short-term way to achieve that could probably be hacked up.
Well... there's not exactly a notion of "distributedness" built in. That's on the wishlist (and, in fact, this project sprung out of a much older project that had that as it's core idea) but there is support for receiving and display messages from any other arbitrary system that supports the activitystrea.ms protocol. So modifying Quoddy to emit, as well as consume, activitystrea.ms messages would give you a way to achieve a degree of "distributedness." And that wouldn't be a hard change to make in and of itself.
The trickier part would be how to say "I want to receive updates from remote user $FOO when they come in" since $FOO is probably not a user on your local Quoddy instance. Once we have FOAF support implemented, it would be easier to talk about navigating the remote social graph and connect to non-local users... but a short-term way to achieve that could probably be hacked up.