social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] Which of four projects are we doing?


From: Carlo von Loesch
Subject: Re: [Social-discuss] Which of four projects are we doing?
Date: Sat, 27 Mar 2010 18:07:32 +0100 (CET)

Melvin Carvalho typeth:
| I think HTTP should be supported, im not saying it's the only protocol that
| should supported, but it's something that's had some success in scaling in a
| decentralized way.

As a fallback option alright, but HTTP isn't famous for interserver
applications. You need to have two for proper bidirectional traffic
and you can't send messages without acknowledgements. You have plenty
of overhead and you have to trust your backbone to do persistent
connections. Also, is HTTP over PHP failsafe? What if a packet is sent
out to another server while this server just closed the receiving
socket because of inactivity? It's a problem we have in the XMPP world
that packets occasionally get lost this way, so I wouldn't want that again.

| RDF applies the same simple principle to data.  You give data a global
| identifier (you can make them local, but the real power comes from making
| them global), and each data point is allowed to have one or more key/value
| pairs (which in turn can also contain other links).  That's basically it.
| Simple but powerful.

Yes, RDF is a fine format. It makes sense with HTTP where actual content
has no format yet. With XMPP it is a bit cumbersome - XML markup needs
to be escaped or uuencoded to avoid it from colliding with XMPP's own
syntax. In PSYC you have two options, either just send the file as with
HTTP (PSYC is fundamentally similar to HTTP) or use PSYC's native
key/value pair syntax. You could also come up with a native RDF-like
extension for XMPP I presume.

| What makes you think the web is unable to do a web of trust?  There's over
| 100 million foaf profiles out on the web (including google foafs) each
| showing links to people that are known or followed.  That is a form of a web
| of trust already, and there's much more that can be built out quite easily,
| for example, with the proposed web of trust system : (

Er, sorry.. to me web of trust is always linked profoundly to privacy -
if it's a public trust network that anyone can see I am actually scared
by its existence. I don't want the world to know who I trust and who
trusts me.

The logical consequence of this is foaf+SSL, but in order to really
connect the information from the foaf profiles with the choice of SSL
certificates you need some server-side intelligence. Right? That to me
is the point where you leave the battleground of traditional web
servers. A web server that parses and understands FOAF goes beyond the
web. Maybe I'm old-fashioned and should update my views there.   :)

Okay, so I correct myself and say with foaf+SSL we might very well
have privacy and a web of trust. Still, what it enables us to do is
to use a web browser to see profiles. It wouldn't push notifications
of status updates and profile changes to us.

| Not 100% sure I follow this, I thought facebook was built mainly on PHP?

But you can't run it on an off-the-mill webhosting site. PHP is the
front-end, but there is a powerful distributed backend engine that
makes all that heavy event-oriented real-time messaging possible.

I have nothing against a great and powerful PHP web-based user
experience, but methinks we need a solution to link it up to a more
powerful networking backend than LAMP. Say we have one such backbone
router at a certain data center - PHP apps running in the same data center
could talk to it via UDP packets. UDP is usually safe within a LAN.
This would allow us to have dozens of commodity gnu social deployments
and still have powerful interserver networking as long as someone
pays for that one root server. Just a thought.

| It's an architectural and mathematical challenge for sure, perhaps one
| reason why no one has yet solved this problem.  I'm not saying HTTP is the
| best protocol for this, but sending an update to 40 friends is probably no
| more complex than loading a web page with 40 images on it, something most
| people probably do every day.

It's very different if those 40 people are on 40 different sites. It's
also different if you take realistic friendship numbers from social
networks. I have 400 on FB and 800 on Myspace, and I'm not a power user.
And then there is the question, are we going to do event notification
from the user's client? If so, then all things like comments to our
updates and such have to wait until we come back online to distribute
them. How would you even go about it. Would our server generate a page
that contains 400 embedded HTTP requests to our friends' servers using
javascript?

| I'm inclined to agree, but I think you have to start somewhere and do
| something really well, so the proposed PHP solution seems a good place to
| start, then allowing ports to other languages etc.

We already have StatusNet, Crabgrass, Elgg and Pinax. Even if these
projects reach the usability of Facebook, it would still be something
isolated groups use unless worldwide decentralized scalability is really
feasible. No? Yes?

Without the "web" aspect, and I mean the decentralized network, it
ain't got that swing.

-- 
___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___
___ xmpp:address@hidden ____ https://psyced.org/PSYC/ _____




reply via email to

[Prev in Thread] Current Thread [Next in Thread]