On 29 March 2010 17:56, Melvin Carvalho <[email protected]> wrote: > > 2010/3/29 Carlo von Loesch <[email protected]> >> Alright, it can be done. What for? Just because you >> don't have to implement a routing layer, or use an existing one? Having >> slow web servers in the mix of the whole system is a good idea?
No, because you don't have to re-educate hundreds of thousands of people who already know how to use HTTP. End of story. >> The number of fail whales that I the not power user have seen makes me >> wonder if a real backbone could have been even more successful. I agree 100% - I don't believe that a centralised infrastructure is the best way to build low-latency highly social websites. I said that when I built it, and I still stand by my statements; that's why I'm here. On the other hand, two years ago those fail whales were largely because Twitter had only one database server, for well over five million users sending tens of millions of tweets a day. I think that stands as a testament to the power of HTTP. >> | And isn't that the most important thing here? Do we want a highly >> | tuned race-car of a P2P decentralized network that has no users, that >> | concedes to Twitter and Facebook the bulk of users and their freedom? >> >> I don't see people flocking to see a brand new Facebook lookalike, >> but I can imagine people installing the blazing native social network >> client that lets you do the things we used to do on Facebook in a >> much more breathtaking and empowering way. And with all the headline >> news on data breaches over the last years, they might actually >> appreciate to hear, that such a desktop based social network application >> doesn't just do nifty things such as sharing files with your friends - >> it also keeps that data truly private. Something a server just doesn't >> do. I cannot underscore enough the fallacy that is privacy on the internet. You don't get to keep things private unless you work at it. No technology, no tool, no simple approach is ever going to be enough, because fundamentally people share data that you share with them, and once they've shared that data, you're never getting it back. If you can solve the data privacy problem, you've solved DRM. It's not going to happen, though, so we have nothing to worry about. The way that privacy will be solved for users is by giving them tools to learn how their data is being distributed and used. By way of analogy, when someone you know shares an important secret of yours, you have several options: at one extreme you can accept it, or you can privately or publicly censure your friend, cease communicating with them, or at the other extreme sue them for libel or under other applicable laws. Who you share the data with is up to you, and is a decision made by applying lessons learned through previous interactions with that person and others, the nature of the information, and so on. These decisions can only be made by people; those same people have to learn to take responsibility for their decisions. In that sense, you're trying to apply technological solutions to social problems. Those technological solutions won't work. > Why cant we do both and have the best of both worlds? I dont think there's > anyone that's said, 'hey lets NOT do a desktop client', just that with > limited resources the core project team wants to focus first on a GLAMP > solution. What's to stop you adding a blazingly fast native client in > parallel? That's what Twitter, Facebook, FourSquare, Status.net, etc, etc, etc have all done. All of those clients work via HTTP. As to promoting non-HTTP transports for those clients? Compared to custom protocols, OAuth is a trivial thing to implement, and yet so many client developers have unending difficulty implementing it. They get curl; take a look at this write-up: http://www.dashdashverbose.com/2010/02/curl-ing-up-with-webfinger-and.html >> No thanks. Each one of us here has already some prototype or product >> working. Just look at http://groups.fsf.org/wiki/Group:GNU_Social/Ideas >> there is a broad choice of projects for each design approach to doing >> this. Yes the web-based quickhacks lead the pack. Twitter started as a web-based quick hack. Facebook, too. Name any successful social network to date, and you can say with certainty that it "started as a web-based quick hack." >> | to work /for users/, and not just geeks. The same applies to the >> >> Users are still choosing Skype over web-based telephony. Why that? >> Don't underestimate the power of a sleek desktop utility.. How many >> Twitter users use desktop clients? How much do they enjoy Twitter >> more than the regular users? Web-based telephony is nowhere near mature, and as HTML5 apps become more feature rich and capable, I'm willing to bet that more users will turn to those technologies. That doesn't necessarily mean HTTP as an audio transport, of course (Websockets are more likely), but if we dig in a bit to your argument, *Skype* is more successful than, well, than any open telephony standard after SS7 and GSM, period. SIP hasn't fared well compared to Skype. Why? Because Skype has a better user experience than SIP. End of story. If you're setting out to re-invent social networking, I urge you to go back and take a closer look at what your user experience story is again, and again. Otherwise, your work is at best research, at worst geeky idling. Neither seems to be aligned with the goals of GNU Social. >> I see quite some potential with the backend of GNUnet, the experience >> in protocol design of PSYC/XMPP and several other nifty things that have >> been thrown into the pool on this mailing list recently. Working out >> the real thing looks very feasible in my eyes. That's encouraging. My concern is that in order to appropriately target the bulk of users (heck, even to target the bulk of *technologically-savvy users*), GNU Social must take advantage of technologies and models that those users already have experience with. Yes, Ford's "If I'd asked my customers what they wanted, they would have said a faster horse" adage applies here, but the crux of the transformation from horses to mechanical-horses to automobiles is that even early automobiles were *easier* to use than horses for the layperson; building a tool that's more difficult to use rarely ends well. b.
