2010/3/29 Carlo von Loesch <[email protected]> > Blaine Cook typeth: > | > actually optimized to do this job. There is a reason why chatrooms > | > are usually not implemented by HTTP POST orgies. > | > | Actually, increasingly they are. > > I've done my share of webchats myself, I used to run some of the > largest web chats in Germany ten years ago (although ten thousands > of people sounds harmless today), but using HTTP for that only makes > sense if the web browser is the chat client - not for interserver exchange > and distribution. 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? > > | It's appalling, it's horrendous, but developers love the HTTP, and > | most importantly, it's massively successful. So the wisdom I've gained > > 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. > > | 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. >
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? > > | Or do we want a successful technology that empowers more people and > | promotes and extends freedom to them? > > Yes, only it's not the one you mean. > > | You're welcome to create something entirely new, but I'd suggest you > | start by mocking up some designs as to how your P2P network is meant > > 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. > > | 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? > > | usability of the underlying technology as far as your target > | technological audience is concerned (in this case, your audience is > | almost certainly web developers - c.f., GNU Social targeting PHP). The > | technology is important, but the usability and desirability of the end > | result is far more so. Ignore this at your peril. > > 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. > > -- > ___ psyc://psyced.org/~lynX <http://psyced.org/%7ElynX> ___ irc:// > psyced.org/welcome ___ > ___ xmpp:[email protected] <xmpp%[email protected]> ____ > https://psyced.org/PSYC/ _____ > > >
