4 ms·

I agree - it's a fantastic thing to be forking the code. The side effect is that with each fork whatever protocol Diaspora have chosen becomes more entrenched a

I agree - it's a fantastic thing to be forking the code. The side effect is that with each fork whatever protocol Diaspora have chosen becomes more entrenched and difficult to change. 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.

mikesofaer 16y ago
We're very aware that we will be breaking interoperability with forks when we change the protocol, and there is a little bit of a worry that people won't keep their forks up to date and the protocol will fragment. I am optimistic that that won't happen, largely because the Diaspora product is the only part of the system actually visible to the outside world at the moment, and that gives us a pretty good way to draw a bright line between products that interoperate and products that don't. 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!

mikesofaer 16y ago

We're very aware that we will be breaking interoperability with forks when we change the protocol, and there is a little bit of a worry that people won't keep their forks up to date and the protocol will fragment. I am optimistic that that won't happen, largely because the Diaspora product is the only part of the system actually visible to the outside world at the moment, and that gives us a pretty good way to draw a bright line between products that interoperate and products that don't. 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!