4 ms·

I agree my post wasn't coherent. Forgive me I just wrote down what came to my mind and posted it. That said, I don't understand what you are trying to say eith

by volaski 14y ago

I agree my post wasn't coherent. Forgive me I just wrote down what came to my mind and posted it. That said, I don't understand what you are trying to say either. It would have been nice if you discussed why my argument "by definition decentralized means no one is responsible" is "flat out wrong". Also regarding my statement "Realtime protocols like PubSubHubBub and RSScloud are there because that's the only way to make the Web work in realtime", maybe I didn't state it clear enough, but it's not as obvious as it sounds in my opinion. Before RSSCloud and PubSubHubBub, if you wanted to run an aggregator you had to actively poll sites, which was extremely inefficient. With these protocols now aggregators can deliver content in near realtime because they just have to implement those protocols. The point I was trying to make was, even these efforts will never be completely reliable because they are built on top of protocols and standards. Protocols and standards work only when "good enough" is good enough. For example, building a decentralized version of a stock ticker system sounds cool but in practice its performance will never be as good as the original centralized version.

andreasvc 14y ago
In a decentralized system like email or jabber there is responsibility, @example.com is responsible for delivering messages to its users, and for the necessary communication with other servers. And of course you'll want to use push messages for communication between servers. It really doesn't have to add all that much latency, a few roundtrips is perfectly doable. That's a very small price to pay for the benefit of being independent of the whims (or unreliability) of a single entity. That said, it's probably not going to happen soon, but not because of technical issues. I think it's just a matter of inertia among users, just like people are still using MSN messenger or skype instead of jabber.
- volaski 14y ago
  I think the when we talk about Twitter, the definition of "reliability" is entirely different. When we talk about emails, we can say it's reliable as long as my email gets delivered one way or another. For example, if I send a mass email to 20 friends, I don't assume anything about when each of them will receive my message. I just think that it will get delivered in a reasonable amount of time. However what Twitter brings to the table is this: It is safe to assume when I tweet, all my followers will be able to see it immediately. This is a huge difference not because of the delivery time, but because of the type of behavior it enables. Being able to assume that my message is delivered in realtime is very different from not being able to assume. And this is not a technical issue, so even if you build a "good enough" realtime system using decentralized architecture, it wouldn't be half as good as Twitter.
  - thinkingisfun 14y ago
    It is safe to assume when I tweet, all my followers will be able to see it immediately. Unless they do something else with their computer, or are doing some chores in room with the big blue skybox. And you can only assume this because you know Twitter has fast servers etc. - not because it's a proprietary black box. The same would hold true for your favourite, lightning-fast diaspora or OStatus pod of choice. Yes, ONLY those followers who ALSO care about super instant real-time speed, will be signed up to fast pods in turn -- but guess what, if you forced them to be on twitter they still wouldn't read, much less react, to your stuff in real-time. So you gain nothing. Is there a delay when updating to a status to identi.ca before it shows up on rstat.us for example? Have you even tested before you accuse people of "not getting it" --- ??
  - andreasvc 14y ago
    It think the difference between 0.1s and 1s, as I imagine it would be, is quite irrelevant. The immediacy comes from the push, adding another hop for a federated server does not have to add a significant latency.
thinkingisfun 14y ago
But the protocol used and the latency are not linked at all. You can use a proprietary protocol to run a centralized service, you can use a proprietary protocol to run a decentralized service, you can use a public protocol to run a centralized service, you can use a public protocol to run a decentralized service. And of course you can also mix them, insofar as they interface. For example, building a decentralized version of a stock ticker system sounds cool but in practice its performance will never be as good as the original centralized version. Well, yes - but the question is, how fast is fast enough, for most applications? And wouldn't it make more sense for the people who need to have really, really fast exchange of status updates, to sign up for the largest, fastest provider -- instead of everybody having to be there, just because some people need it real-time, all the time? Personally, I prefer some latency actually. I like being able to edit thoughts after I posted them, and so on. I like being able to search stuff and organize it -- Twitter fails dysmally in that aspect, if it wasn't for the "that's a joke, right?" limit of 140 characters. And if something really important happens, it will show up on blogs and news sites a few days later. Friends will tell me about it. Personally I need information I can ACT on, not just... stuff... that clogs me up. New software or knowledge is usually still fine when it's even a week old, or more. It's not like I can instantly learn it. And that something is popular is not something I need to know while it's popular, actually, a delay filters quite a lot of lame stuff out. And again, you can still build the exact same thing centralized and interoperable with slower leaf nodes, on open protocols. People just don't wanna because then they don't get to license it to others, and brand things that are much prettier and more useful unbranded. To me the proof that it's people problem is that the technical problems are more or less solved, or at least proven to be solvable (there's always room for improvement, none of our protocols are utterly fantastic). The people with the most energy are the ones that are kinda greedy. There are sparks of genius or excitement here and there, but they disperse too easily, while the ones that keep at it are the ones who should give it a rest, so the rest can think and build things that are by and for everybody, forever.
cmsj 14y ago
Stock tickers are decentralised. Trading houses 'subscribe' to ticker 'feeds' from many different exchanges and receive updates in 'real time'.

by volaski 14y ago

andreasvc 14y ago

In a decentralized system like email or jabber there is responsibility, @example.com is responsible for delivering messages to its users, and for the necessary communication with other servers. And of course you'll want to use push messages for communication between servers. It really doesn't have to add all that much latency, a few roundtrips is perfectly doable. That's a very small price to pay for the benefit of being independent of the whims (or unreliability) of a single entity. That said, it's probably not going to happen soon, but not because of technical issues. I think it's just a matter of inertia among users, just like people are still using MSN messenger or skype instead of jabber.

volaski 14y ago
I think the when we talk about Twitter, the definition of "reliability" is entirely different. When we talk about emails, we can say it's reliable as long as my email gets delivered one way or another. For example, if I send a mass email to 20 friends, I don't assume anything about when each of them will receive my message. I just think that it will get delivered in a reasonable amount of time. However what Twitter brings to the table is this: It is safe to assume when I tweet, all my followers will be able to see it immediately. This is a huge difference not because of the delivery time, but because of the type of behavior it enables. Being able to assume that my message is delivered in realtime is very different from not being able to assume. And this is not a technical issue, so even if you build a "good enough" realtime system using decentralized architecture, it wouldn't be half as good as Twitter.
- thinkingisfun 14y ago
  It is safe to assume when I tweet, all my followers will be able to see it immediately. Unless they do something else with their computer, or are doing some chores in room with the big blue skybox. And you can only assume this because you know Twitter has fast servers etc. - not because it's a proprietary black box. The same would hold true for your favourite, lightning-fast diaspora or OStatus pod of choice. Yes, ONLY those followers who ALSO care about super instant real-time speed, will be signed up to fast pods in turn -- but guess what, if you forced them to be on twitter they still wouldn't read, much less react, to your stuff in real-time. So you gain nothing. Is there a delay when updating to a status to identi.ca before it shows up on rstat.us for example? Have you even tested before you accuse people of "not getting it" --- ??
- andreasvc 14y ago
  It think the difference between 0.1s and 1s, as I imagine it would be, is quite irrelevant. The immediacy comes from the push, adding another hop for a federated server does not have to add a significant latency.

thinkingisfun 14y ago

But the protocol used and the latency are not linked at all. You can use a proprietary protocol to run a centralized service, you can use a proprietary protocol to run a decentralized service, you can use a public protocol to run a centralized service, you can use a public protocol to run a decentralized service. And of course you can also mix them, insofar as they interface. For example, building a decentralized version of a stock ticker system sounds cool but in practice its performance will never be as good as the original centralized version. Well, yes - but the question is, how fast is fast enough, for most applications? And wouldn't it make more sense for the people who need to have really, really fast exchange of status updates, to sign up for the largest, fastest provider -- instead of everybody having to be there, just because some people need it real-time, all the time? Personally, I prefer some latency actually. I like being able to edit thoughts after I posted them, and so on. I like being able to search stuff and organize it -- Twitter fails dysmally in that aspect, if it wasn't for the "that's a joke, right?" limit of 140 characters. And if something really important happens, it will show up on blogs and news sites a few days later. Friends will tell me about it. Personally I need information I can ACT on, not just... stuff... that clogs me up. New software or knowledge is usually still fine when it's even a week old, or more. It's not like I can instantly learn it. And that something is popular is not something I need to know while it's popular, actually, a delay filters quite a lot of lame stuff out. And again, you can still build the exact same thing centralized and interoperable with slower leaf nodes, on open protocols. People just don't wanna because then they don't get to license it to others, and brand things that are much prettier and more useful unbranded. To me the proof that it's people problem is that the technical problems are more or less solved, or at least proven to be solvable (there's always room for improvement, none of our protocols are utterly fantastic). The people with the most energy are the ones that are kinda greedy. There are sparks of genius or excitement here and there, but they disperse too easily, while the ones that keep at it are the ones who should give it a rest, so the rest can think and build things that are by and for everybody, forever.

cmsj 14y ago

Stock tickers are decentralised. Trading houses 'subscribe' to ticker 'feeds' from many different exchanges and receive updates in 'real time'.