Several of us (Josh Kopelman, Brad Feld) are having deja vu around various notification schemes floating around the network today. We're seeing the exact same pattern that has haunted us at various levels in the past, emerge again today with all the UGC being created, and the ensuing discrete activities flying around by the billions.
Everything always boils down to Push vs. Pull (polling). It's a permanent pattern... it's part of life... as integral as the air we breathe. Therefore, the choices we make around whether to push or pull affect the whole system. As Brad points out, RSS is cool, but in the end, it's been over-engineered to include features for everything including the kitchen sink. Furthermore, there are at least two competing formats still causing trouble for end users (Atom, RSS). There are times when Push is the right thing to do, and there are times when Pull is. Heck, there are times when starting with one, then evolving to the other when things change, makes sense.
We're very early in the evolution of UGC activity aggregation and notification; five or ten years out from true app distillation I'd imagine. End users don't care about these things, yet they're still in the foreground of how apps behave and function.
The activity aggregators popping up, new ones by the hour, often provide a "dashboard," and they're doing a fine job thus far. That said, in the process, they're trying to build their consolidated front ends using infrastructure that fundamentally doesn't support them (as a collection) at scale. A SNMP for the network at large is indeed needed. One that knows how to manage both Push & Pull, and Async & Sync access patterns,
. The current state of affairs is collapsing around us (just talk to anyone who's building one of the aggregators). Not to mention, how we, as end-users, can't manage the information we ultimately want.
Brad's comments on namespace management scratch the surface of what will become one of the most significant nodes on the network in the coming five to ten years. Authoritatively managing a user's identity across services will be a bear; if not technically, then behaviorally on the part of the user. OAuth, and OpenID aren't there yet (even assuming widespread adoption). OAuth does a fine job ensuring the user is conscious of authZ and authT between applications, without sharing their credentials. OpenID does a fine job canonicalizing credentials across services for authT. However, I haven't seen anything that authoritatively aggregates a specific user's namespaces across multiple services (without the user having to divulge their credentials; which is a no-no). In the end, these username bindings will have to be managed by the actual end-user, as machines can only infer, at best, whether two usernames belong to the same user. First one to provide this namespace aggregator wins! If it can be done in a distributed/federated manner, even better.
PS - I'm going to start providing cool pictures in my posts that add a bit of poetry. Pete Warden does an amazing job of this on his blog! I'll be curious to see if I can pull it off.