James Walker typeth: | On Sun, Mar 28, 2010 at 3:41 PM, Henry Litwhiler <[email protected]> wrote: | > On 3/28/10 3:35 PM, James Walker wrote: | >> On Sun, Mar 28, 2010 at 3:28 PM, Henry Litwhiler<[email protected]> | >>> On 3/28/10 3:21 PM, Matt Lee wrote: | >>>> On 03/28/2010 02:57 PM, Henry Litwhiler wrote: | >> | >> Blaine mentioned our work earlier, but I would strongly encourage you | >> to check out OStatus - http://ostatus.org/ . It already incorporates
PubSubHubbub uses a round-robin approach rather than multicast trees, that is bad for popular feeds. Also it only "pings" which means more traffic is generated by all recipients fetching the news in some overhead file format, an approach that again would be like a slashdot if some feed suddenly becomes very popular. My notion of efficiency is rather some minimal data structure and method containing exactly the new event, nothing else, delivered by steady TCP lines or even UDP where suitable to all recipients, even if millions. | >> both messaging as well as following/subscriptions. It's currently used | >> by StatusNet (http://status.net/) - but is built on the same open | >> protocol stack used by Google Buzz, Cliqset.com and others. These techniques may be sufficient for a system that intends to *publish* "status updates" but if you consider people may want to massively chat on each update, and have these conversations encrypted in such a way that only the intended recipients see it, not their ISPs, then something leaner and more streamlined may be in order. | >> I would strongly encourage you all to focus on adopting existing | >> (preferably, rather than creating) open standards. True decentralized | >> networking should be platform and language independent. Unsuited open standards are frequently the highway to inefficiency. | > I agree - we would probably be better off adopting something like OStatus, | > rather than developing our own format. If you compare the actual amount of data and complexity of TCP streams on the wire of OStatus vs. XMPP vs. other things you will see HOW MUCH this approach is far from efficient, and how much we could be doing things better than has been done before. Latency too can be a factor. | it's the only thing that really makes sense at the end of the day. | (Note: I don't think you need to use the protocol that I personally am | involved in- rather using something open / existing). Even that isn't obviously true. Considering that we have a use case roughly as intense as a chat technology, and the two leading free software chat technologies, IRC and XMPP, both do not deliver perfection, to use mild words. Additionally the future of privacy requires cryptography on the personal device, leading away from the web-based approach - unless we could do things using browser-based client certificates like foaf+ssl does. | Have a look at this list over the weekend - the people here can't even | agree on which language and base architecture. Once one is selected, It is pointless to talk of languages and architectures when we haven't agreed on the true requirements yet, and haven't fully understood the challenge before us. | trying to pick a user interface and experience model that works across | languages, cultures and fickle personal preference isn't going to | work. | | This is in large part why the twitters and facebooks of the world will | never achieve full ubiquity. | | *However* SMTP (warts and all) has come pretty darned close. Why ? | It's simple, open and completely platform and interface agnostic. That is another great and very logical point against the web-based approach. Real client applications can provide an experience that suits the personal device being used, possibly just providing access to a slice of the social everything, that fits. A mobile phone would only provide important status updates, while a desktop client would even accept an mp3 that a musician friend is sending to all of his peers. Web-based social interactions? Yes, you can have that. It's like checking mail or doing IM via the web. If we go for this, web-based social networks will be the way of the past. | If you're looking for decentralized networking - there are lots of | players already in the game. Many of which are idealogically already | aligned. I'd encourage you to contribute. There are lots of players already aligned for EVERY architecture and every school of thought. Each of us sits on some technology which somehow does something social. If we want the truly best, we need to consider the idea that something completely different from what we have always done may be it. So just because there is something that somehow works doesn't solve the problem of agreeing on what we really want to achieve - if a hack based on web hooks is enough, or if we want an infrastructure that could even allow for social video streaming. Considering that the difference in amount of work isn't all that huge, it's a pity to go for the limited hack. | >> Completely untrue - RSS& Atom are document formats ... they can be | >> pushed realtime (see above). See also PubSubHubbub - Document formats are not what we need when we transmit each event one by one. We just need a format for ONE event. Then deliver each of those continously, in real-time. | Hrm. Maybe spend a minute or two reading through pubsubhubbub. it's a | "push" mechanism for RSS & Atom. the entries are *explicitly* sent to | them. Why think in terms of "entries" ? | >>>> I think the UX would be similar to Facebook, but different in the ways | >>>> we encourage communication. Different for each language, each way of thinking, each personal device and each usage requirement (true end-to-end privacy vs. worldwide publishing) -- ___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___ ___ xmpp:[email protected] ____ https://psyced.org/PSYC/ _____
