On Mon, Mar 31, 2008 at 3:05 PM, Aaron S. Miller <[EMAIL PROTECTED]> wrote: > > 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.
My solutions thus far has been to look at ways that we can begin to expose more of this data via web services. Both at the XMPP server end (attempting to find ways that tools like oAuth can be made to help with exposing members data, and some basic api's for pushing updates down to the server can be made). Or by creating http middlewares that do that same kind of process for me (translate http requests into messages sent via clients spawned on login of a user). I'm not /super/ happy with either of these approaches. ~ Anders > > 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 >
