Volatile (ie., highly dynamic) supergraphs
Update: Chris Messina had similar thoughts a month earlier:
In fact, it’s no longer even in your best interest to store data about people long term because, in fact, the data ages so rapidly that it’s next to useless to try to keep up with it. Instead, it’s about looking across the data that someone makes transactionally available to you (for a split second) and offering up the best service given what you’ve observed when similar fingerprint-profiles have come to your system in the past.
Now back to my contribution…
Now that everyone’s frenzying over the gruffalo, I guess it’s as good a time as any (at least) to expand my graph post [also] a little. The post isn’t anything notable but it gives some context, if interested.
For the topic’s current initiation, see TBL on Giant Global Graph:
[Internet] made it simpler because of [instead?] having to navigate phone lines from one computer to the next, you could write programs as though the net were just one big cloud, where messages went in at your computer and came out at the destination one. The realization was, “It isn’t the cables, it is the computers which are interesting’.
[...]
The WWW increases the power we have as users again. The realization was “It isn’t the computers, but the documents which are interesting”.
[...]
Now, people are making another mental move. There is realization now, “It’s not the documents, it is the things they are about which are important”.
(See also a nice roundup on ZDNet, Who is afraid of the GGG?)
My views next.
Dynamic graphs
Put it simply, my approach to building a next-gen SNS would be to extends the current feed polling capabilities to the graph aspects as well (social networks etc). For example, I have Facebook ‘importing’ my Jaiku feed currently, so why FB couldn’t just as well import changes to my Jaiku contact list and apply them to the FB domain?
The underpinning aspect here is that the future services should not try to be exhaustive by themselves, but to present the whole graph from their point of view as well as possible — be that ‘entertainingly’ or whatever is their beef. More generally, services should fetch data all over the web, and decorate it in their own, valuable way. Services would be much more interesting if they combined all the data and not just tried to hold on to that very tiny fragment (eg., the FB account) of my overall graph so fiercely.
This implicates that services would need to adapt to whatever changes in the user’s social graph, and that happens to be exactly what I want at a very personal level — ofcourse, this is also professionally highly intriguing. In practice, it’d be even somewhat trivial; just import the damn changes as you read the feeds. The difference to feed polling here is that it’s not new content per se that is fetched, but changes to existing data. So, services need to delete stuff (relationships etc.) as well. For implementation details, see for example “Dynamic Graph Algorithms” by Eppstein et al., 1999, which appeared among the first google hits (can’t remember for what; try out). (‘Someone’ should probably adopt those to rails so we could get the ball rolling…)
Of course, the most prohibiting problem currently are the walled gardens. (I expected the Open Social to do something about this, but Google failed me.) There are however at least a couple of sites that publish more data, but it’s very little still. And note that the data here comprises is the basic building blocks of the semantic web, but semantic web drafts completely ignore the fluctuating nature of data; which is why I think the semweb is born retarded.
Supergraph instead of a flat global graph
Then there was my notion about ‘supergraphs’ in the title; volatile was just to emphasize the true dynamism — if you don’t store external data, you don’t need to synchronize it. (Keep it simple.) With supergraph I mean that different kinds of graphs should not be bluntly blended but the metadata should be used accordingly. Social networks provide a fine example here, too.
This ‘supergraph’ thing should be very intuitive also: if I ever wanted my LinkedIn contacts to be mapped to Facebook, it’d be extremely nice if the LI contacts were presented in a different style than my Jaiku contacts. And, perhaps, there could be some different tools available for each kind of network — please, no vampire stuff (like, wtf…) for the business contacts, aight?
And, just to note, not all contact networks should be mapped to every service (of course), but that’s a whole another graph story and I’ll leave it for later.
So, this ‘volatile supergraph’ thingy should be rather easy to implement (no hard non-trivialities) if you was a systems designer (and not part of the 80%) and I’d be very excited to have it working. I bet a few googol other zimboes would be as well.
Expect next: dynamic, rich graphs. (Or probably not. But still,) Thanks for listening!
Dynamist artists used the concept as part of a way of representing the complexity of processes, rather than be limited by the discrete and static moments within change, which also illustrated the limits of human perception.
— found in Wikipedia
Tags: Internet, Social networks, Standards, Theory, Future



This all sounds nice, but… :)
All services mentioned above are more or less like teenager boys. Insecure, and highly unaware (guess so is the mentioned 80% after their puberty too).
Starting to share more would need a change in the mental state of many instances.
FB is no more open or sharing or modern than Angelfire was, or is :)
Like you said, the technical obstacles are trivial to the willing. Just that the money is on the camp that does not think it provides something that important that it would be significant or monetizable when shared.
Guess this is all obvious and trivial and somehow implied in your entry. I just had to say something :D
Miika Niemelä
November 30, 2007 at 9:25 am
Yeah, absolutely correct! So immature, as is the whole industry. And yeah, a fine reference; nothing’s changed since the beginning!
Let’s hope that the ‘money’ (investors, markets) learns that they’ll profit more if people will find the services more useful. (Uh, did I really need to say that?)
All new, all good, very much appreciated. :)
Sorry for taking awhile.. playing with all mercurial and buildr.
Janne Savukoski
December 11, 2007 at 12:20 am
[...] Utterances of a Zimboe Programming the Internet. (Web’s for the n00bs.) « Volatile (ie., highly dynamic) supergraphs [...]
Social features « Utterances of a Zimboe
December 29, 2007 at 9:54 pm
Dunno if you’ve seen it, but what you’re describing is essential the model we’re employing for the DiSo Project (diso-project.org). The goal is to embrace a distributed graph and thereby increase competition through the proliferation of the adoption of a few core open technologies. ;)
Chris Messina
January 27, 2008 at 7:47 pm
Yeah, I’ve certainly heard about DiSo—seems like a very interesting project indeed—and I was just studying how you’ve used/planning on using XMPP there. For me, XMPP’s been one of the most interesting pieces of technology in “recent years”. (It’s just so sad to talk about stuff that’s been laying dormant for such a long time.. gladly, there’s been some awakenings in the XMPP field lately.) Currently, I’m getting into designing one sns and naturally we’re considering all aspects of how to create a relevant system that’ll fit into the future landscape of social services.
We’ll be releasing/contributing to open source projects as much as possible, and we’ll see which projects happen to be suitably aligned to our projections. It’s just too bad that our platform is django while your initial focus is on wordpress.. But, on the other hand, it’d only broaden.. well, we’ll see. :)
Btw., a very nice ‘introview’!
Janne Savukoski
January 27, 2008 at 8:12 pm
[...] means the implementation of volatile Social Graph. Go, ruskies! No Comments Leave a Commenttrackback addressThere was an error with your [...]
Volatile Social Graph, implemented « Utterances of a Zimboe
July 9, 2008 at 8:01 pm