At work, i've got a fairly focused and reasonably simple task: Figure out a way to let users share their activities. This is because quite a few users like doing that and who are we to argue if they want to run little ads for our services on major social networks?
One would think that this would be fairly straight forward, but one forgets a few things. Little details like: There's No Standard Yet, Scale Hurts, and Companies Don't Like Each Other. Sadly, it also seems like i'm the first content provider that's actually interested in working with any of these systems, or at least asking questions about it.
Well, it's not really true that there's no standard yet. The standard currently is either Facebook, or A Handful of Bits That Look A Lot Like Facebook (a.k.a. OpenStack). Looking at things in detail i see:
- This is a way to indicate i have an account. That's it. That's all it does. The account doesn't have to be legit, it doesn't have to be authorized, about the only thing required is that it be unique. Why is this useful? Because by granting a bit of uniqueness to an otherwise non-unique world, you can avoid being "JohnQPublic819231912391051098479823987197-b". Facebook kinda/sorta has this by saying "Your account name is an email address" which is also by nature unique, provided you're not "[email protected]". Of course, since OpenID is only about providing a bit of unique to indicate "you", it really has no provision for specifying "you", therefore you kinda have to do that yourself. This is a pain to folks that want to use OpenID because for some reason people don't like being called "192Af9239saf9xv9aoiu1lkos9af09fjamnbal9sf97", so one of the first things sites do is ask you for your name.
- This is kind of a bucket of things that sites may or may not offer. One of these is a way for me (the site you're visiting) to get a list of your associates ("friends","family","people i hate",etc.). i don't actually get any information about them without making additional calls, but i do get reasonably unique identifiers for them. They're reasonably unique because they're unique to the service, not universally. Fortunately, i can store these identifiers. That means that if i already know about "Bob" (because he's already a customer of mine) and you have Bob's ID in your associate list, that means that i know you and Bob are friends, even if he calls himself Robert on your shared Social Network. Of course, if there's yet another Social Network you happen to share and you're not yet connected on, i might suggest you could ping Bob as "Thorax The Kitty Fiddler" (because, you see, he likes playing violins for immature cats) on said network. Granted, i'd guess that Thorax… err… Bob may not appreciate that sort of thing.
Facebook has the same thing, but not necessarily the Thorax problem. If you're not friends, you're not friends and you and Thorax can live happily ever after without you trying to unsee those pictures.
- Portable Contacts
- Of course, the other problem with all these is the fact that not everybody calls things the same. Do you have a postal code or a zip? Do you live in a city or community? Is it your last name or family name? That sort of thing. Portable Contacts is an effort to address that and a few other things which will make my life eminently easier because i won't have to worry about what new conditionals i'll need to add in when "Spiffy New Social Net 3.0" launches in six months. This is how i'll convert some long string of crap into "You", "Your Mom", "Bob/Thorax", etc.
Facebook doesn't have to worry about that because they stand alone. In fine Patrick Swayze style, it's
they had the time of their life and they owe it all to youtheir way or the highway.
Of course, that only addresses one part of the problem, getting stuff in. The other part that is equally interesting to me is getting stuff out. This, sadly, is where things get really crappy for me. There are two ways to do things. One spectacularly crappy way of doing it is a bit to create something like, say, an RSS feed for each individual user and have remote servers query for it. This translates into having several hundred thousand files being requested every second or so from several thousand machines only to find out that 95% of the files haven't changed since the last time they got queried a few seconds ago. While i'm sure there's one proponent of this approach, it's not me. This is a delightful way to replicate a Denial of Service attack and make colo and network providers rich. No, a better way is for me to tell the selected services that care what changes happen when a user makes them. Where it gets a bit crappy for me is that while it's less traffic than being e-raped by hungry servers, it still means me either confirming with the user "Hey, do you want me to publish this to Facebook?", "Hey, do you want me to publish this to MySpace?", "Hey, do you want me to publish this to Yahoo?", "Hey, do you want me to publish this to Ning?", "Hey, do you want me to publish this to Google?", and so on for every transaction they take; or having some global, blanket "Publish to all services" statement which the user checks, and then suddenly regrets when they get disapproving glances from their online church group over a movie they just rented.
i've got some ideas on how to do that, and i'm talking with some folks that are pretty smart about it too, but it's still kind of a sticky UI question, particularly since people often segment their rich, multi-faceted social network onto the various existing networks. (Not everyone is my friend in all occasions.)
The thing to remember is that none of this is perfect. Facebook is pretty easy because they're effectively a monopoly. Of course, being a monopoly, you're subject to their whims. The OpenStack crowd is more open, but far less organized. They're still working out the details and it'll take time before someone comes up with a unified solution that works as well as what Facebook currently provides. Eventually, i'm positive that all this crap will get abstracted out and the problem will go away, kind of like it did with "getting feeds" (where services use universal parsers to deal with the differences between atom and RSS and you don't care because it all shows up in Reader).
The other part that's kind of frustrating for me is that all of these sites seem to think that "Groups" shouldn't build applications (the bits that allow me to fetch stuff and put stuff). i don't know about you, but i like to go on vacation. i'd like to do other things with my life in the future. i'd like to know that if i were run over by an escalator next tuesday that someone could easily step in and take over. The EASIEST way to do this is to create a jointly owned account where i can post the information internally so when i'm forced from the building, someone else can easily step in and fix whatever damage i decide to retribute. Apparently, i am alone in thinking that tying an application to an individual is a bad thing for a company, but that's a battle for me to fight.
Damn these interesting times…