Small but significant announcement from Google today: the embedded Wave element
, which allows you to put a wave inside of a webpage, can now be configured to allow anybody read-only access, even if they aren't logged into Wave. You just inject a bit of code into the webpage, the Wave shows up there, and anybody can read it.
Which leads me to wonder: how much of CommYou is now doable with Wave? Things have advanced a lot in the past six months, with critical new features being added pretty regularly, and I'm beginning to think it could be done. Let's take a brief wander through that idea.
The core ideas of CommYou were similar to those of Wave, but with more of a focus on blogging in the LJ style, and (most crucially) tying into existing social networks. The notion is that you should be able to post these rich conversations, and they would automatically be visible to all of your networks. Wave has pretty solid conversation mechanisms -- if anything, it's a bit *too* powerful IMO, but the general flow is extremely close to the CommYou design: good but not excessive threading, easy navigation of conversation updates, stuff like that. What's needed to really make this thing hum?
First, there's the unified social network
. The idea was that you have an account in CommYou, but you don't actually maintain your network that way: instead, your CommYou account is the union of a bunch of "identities" on other social networks. So my CommYou account would be my LJ, Facebook, Twitter and Google identities, all rolled up. It would be up to me to decide whether these all *looked* like the same person -- I could choose to still present three different identities publicly or just a single one -- but I could go into CommYou and not worry too much about which friends were on which networks if I didn't want to.
This was a key concept of CommYou, and was always dicey, but for legal reasons rather than technical ones. Facebook had a long-standing rule that you can't cache any FB information for more than 24 hours, which makes this hard to implement. However, they've just rescinded that rule, which may make the idea entirely possible. What's needed is a network aggregator that has a good, subtle understanding of these different identities, and lets me manage what I look like to the outside world. I don't believe that's actually hard to write. (It might even already exist -- this needs some research. Plaxo *might* have all the necessary functions: in general, they've done more to push the open social network idea than anybody else.)
Next, there's what I'm thinking of as the Socialite Bot
inside of Wave. When I create a new post and include Socialite, that goes out to the social network system, finds out my identities, and asks which ones to post this conversation to. It posts a brief notification about the new conversation (maybe with some/all content) to each of those networks. It figures out which of my friends on the relevant networks have Wave identities, and adds them to the conversation. It sets appropriate "bloggy" permissions on the conversation, so that everyone can add comments, but can't edit the root blip unless I let them do so.
This bit is potentially tricky, since it should allow *them* to control whether they want to be added to my conversations by default or not -- I shouldn't be able to force it on them. That is, the reader determines what they read, not the creator. (This was one of the things I spent a long time getting right in CommYou -- the data structures are tricky.) Moreover, there's an issue here, in that Wave's Inbox is kind of a grab-bag of everything, but as a reader, I want to be able to group people into different buckets and read them at different times. Possibly Socialite could do something clever with Wave's Folders, letting me creates lists of people and put their posts into different filters that way?
Then there's the public blog site
. This would use the Wave Embed feature, to show all of my Socialite postings in traditional public blog format, so that non-Wave users could easily read it. (The links that Socialite posts to the external networks should probably point to here.)
Hmm; not perfect, but not a bad start. There are a lot of rough edges that would need to be worked on, especially WRT locked posts, and getting the identity-management right would be *very* important. Indeed, I'd probably recommend that the identity distinctions be baked not only into the APIs, but right down into the internal data structures, to minimize the risk of accidental privacy leaks. (That is, if I have friended Joe on LJ, what I see is Joe's LJ identity, *not* the underlying "person" of Joe, to avoid me being able to accidentally see information I shouldn't.) My guess is that getting these internal protocols right would not only be safer, they'd probably enhance scalability in some ways -- in a perfect world, Joe and I should be able to have different "identity servers", but still be able to work together in this ecosystem. This just *begs* for a new open-source infrastructure for identity management.
That's rather neat, and I think the world is getting to the point where it could be built. Hmm: I wonder if I can scare up a little time to start exploring this...