I'm running up against this too. What has evolved in this social
network are two parallel authentication systems, two web servers, two
databases, and parallel but different rosters and friendlists. It
can't continue this way, for us, and while I've known from the
beginning of ways to better integrate these two, unless I go
completely XMPP I can't escape the duality, and if I do, I lose the
advantages of the ease of implementation of the LAMP architecture. If
there were a simple abstraction, as Sergey mentioned, that would
allow me to use different transports, gateways, and authentications
under one umbrella, I would be in heaven.
Aaron
On Mar 31, 2008, at 4:56 PM, Sergey Nazarov wrote:
Anders, let me first note that I'd like XMPP to become an
infrastructure for the next-generation social networking services.
What I'm trying to do is to figure out, what is the best way to
implement such infrastructure. By "best way" I mean the approach
which will require less LOE, be scalable and service-independent.
On Tue, Apr 1, 2008 at 1:15 AM, anders conbere <[EMAIL PROTECTED]>
wrote:
Most social network services today provide tools for a set of people
with share interests. Be it TripIt, LastFM, or Facebook. For lots of
these networks they derive their valuation from a locked in user
model. But for smaller Social Network services they're value for the
creators is in (for the most part) the quality of the users
participating and the number of users participating. That means for
many services it behooves them to work on top of large pre-existing
social networks and leverage the mass of users and the low cost of
participation that affords them.
I'm suggesting that one of the most accessible and valuable networks
these social network service creators could leverage is the jabber
network.
Why?
1) it brings an API
Adding and removing friends is already taken care of, works across
networks, means you don't have to think about it. The authorization
type friend enforcement of XMPP rosters is perfect for social networks
and already designed
2) it brings tools that are harder to build
Creating your own messaging tools and systems is a pain, but they
are easy to build on top of XMPP. Presence is even harder, but is once
again elegantly handled with real time updates from XMPP servers.
3) it brings with is a large pre-existing network of users, tools for
management (chat clients), and it's distributed to interacting with
that network is easy.
4) it doesn't build value in other competing companies
That is, it's not OpenSocial on top of MySpace, and it's not a
Facebook app. The time and effort you put into it goes into a) the
network and b) your service.
so if you accept the premise that social network service creators are
looking for a tool like this (and you should based on the facebook app
and open social stuff), then it should be easy to see that XMPP is
bringing a whole slew of tools to the table for them. It's easy to
think of XMPP as only being about message and presence and forget that
they have a large pre-existing social network built in a powerful
distributed way, and that finding ways to use that network more
effectively is also an incredible purpose.
So to sum up
There are already tools out there, either in use or being created that
work to leverage the roster in XMPP (see importing contacts from
gmail). These services aren't getting the full power out of xmpp
rosters, they aren't pushing the data that the build in their networks
back into the jabber ecosystem, they are accepting users credentials
which means they can do "bad" things to users data, and more. That
means that xmpp is both missing out on providing those networks with
new tools, and ones that would be a net win for the ecosystem of XMPP,
but also not reacting to the new uses in ways the benefit the users of
XMPP.
This concept... for whatever reason is extremely difficult to sell to
XMPP people, and much easier to sell to social network creators.
~ Anders
Consider the following example. There is a social networking
service, The A. I've got a girlfriend and a friend. All of us are
"The A" users, and, of course, I have both my girlfriend's and my
friend's JId in my roster. Me and my friend are "friends" in terms
of "The A", but me and my girlfriend are not. In case our JIDs are
user IDs in "The A", XMPP will not know how to handle such complex
relationship between us.
On the other hand, using gateways will hide our real JIDs behind
aliases, making it possible to handle our relationships.
It would be very interesting to see the overall archetecture we
could use. Gateways seem to be the most suitable solution for me
now, but I'm eager to hear other suggestions.
--
Best Regards, Sergey Nazarov
