What I was trying to get at in the article was that app designers need to think about the protocol at some point since questions such as "are we relying on long polling or will the user refresh pages" start to play a question on the UI side too.
Also, if a product is marketed as being distributed, some thought as to how this will work and scale become important.
It's really good that Diaspora are thinking about what the user sees and programming from the user's POV. I spend a lot of time in the XMPP community and there is not enough of this focus. But a good programmer has to balance design with functionality and focus on many areas and some more thought on the protocol side would not go amiss.
I don't think that the UI polling/refresh question affects the inter-server protocol. Your seed is not your browser, and it's seed-seed communication that's the part of the protocol that matters in the long run.
Scaling is the pressure we're feeling most right now, and we're talking about how to deal with the issue of a distributed cluster with a coherent namespace. There are some interesting things about the Dynamo pattern that might be really useful to make this work. But without a running system with load and users and remote pods to connect to, it's very hard to figure out what you want.
I think that were at the point where the protocol needs something of a refactor, and I will probably make a post about it on the Diaspora-dev google group soon. Maybe we'll get some good feedback and design help!
There's an old saying that you need to build three apps on your framework. That first app shows that your framework works for something. The second app shows that its more general than just the first app. The third app shows that you weren't lucky.
Curious, how was Facebook designed? Are there any post-mortem docs on it? I know that MySpace seemed really ad hoc. I wouldn't be surprised if Facebook was more ad hoc than we imagine it to have been
If I had to guess I'd say that both MySpace and Facebook were completely ad hoc, but the difference was probably that Facebook kept their technical debt down so that they never accumulated an area of code that was too hairy to refactor or replace. MySpace on the other hand probably got complacent in their success and didn't worry too much as their architecture calcified into an unmaintainable mess. By the time they saw Facebook nipping at their heels their code base was past the point of no return, and the company culture made it impossible to hire the level of technical talent they would have needed to right the ship.
Of course I'm completely talking out my ass here, but that's the impression given by the respective product histories.
Maybe just me. I don't know much about the history of the project, except Zuck started it in college.
As the OP points out, protocol cannot be truly decoupled from architecture, especially when it comes to things like routing. There's a huge difference between a Twitter-like @user, an SMTP-like user@domain, a URL-based system like OpenID, etc.
For instance, building around events ("posting a status update", "sending a friend request", "verifying an identity") and abstracting out those events into hooks is how Appleseed does it.
I have no misconceptions that this will hold up to every possible social protocol, past, present and future, but thinking about the protocol as an abstraction, and building the platform out from there, has already shown itself to be very useful.
The questions raised in that post are good, and we intend to address them as they become relevant to what we have build. Discovery, namespacing and routing are areas where we are starting to feel tension on in the product, and will probably be tackled quite soon. The point about affecting interface design is good, but we look at it the other way. We want our interface design to drive the protocol design, so we want to make protocol choices as late as is reasonable.
Finally, it's fantastic that people are reading and forking the code. The more people out there trying things, the better.