Re: [Social-discuss] PHP-Based GNU Social structure

[Blaine Cook]

On 29 March 2010 17:56, Melvin Carvalho <address@hidden> wrote:
>
> 2010/3/29 Carlo von Loesch <address@hidden>
>> 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.