Hello world. Day 2 of biking to work, better than Day 1, but still tiring. I'll need to give myself a break at some point soon - "Don't make yourself hate the bike," said a friend / co-worker - but I think I need to push hard enough to get past inertia and convince myself that this bike thing will really, actually be a new habit.

Dan Saffer (via Bill Seitz): "With many people trying to figure out how to stitch our social networks (and thus our online identities) together, it occurs to me that we already have such a thing, although no feed reader that I know of is really up to the task yet."

This is actually something I've been thinking about and taking baby swipes at. Feed polling and aggregation - but with a specialized UI - is the way to go for distributed social network messaging that can be enabled pretty much web-wide. For more immediacy, the ultimate layer could be XMPP-based at some point. Taking a layered approach could fold in a huge number of existing services, while allowing gradual enhancement where more capable nodes can interact with each other.

Further thinking: A web-based layer between feed polling and Jabber/XMPP could be mutual private atompub. Alice and Bob make contact (somehow) - this entails trading bespoke APP drop-box URLs and some auth details or secrets. Alice can use the URL and auth details to POST messages to Bob, and vice versa.

In more detail: Say that Alice authenticates at Bob's site with her OpenID URL. Maybe she wants to comment on a blog entry that Bob's published. As part of the validation process, Bob's site asks permission to contact Alice in the future. Along with asking permission, Bob's site extends a private APP drop-box URL - thereby pre-emptively offering Alice reciprocal permission to contact Bob in the future.

If Alice agrees to be contacted in the future, her OpenID provider includes an APP drop-box for Alice's in the OpenID validation return trip. This process is similar to the OpenID Simple Registration Extension. Or, Alice's provider could use Bob's APP drop-box right away by POSTing details of an APP drop-box for Alice. Thus, in either case, Alice and Bob can talk in the future by POSTing Atom entries at each other via the exchanged drop-boxes. Not quite Jabber / XMPP, but more immediate than feed polling.

There could be spam potential here for Bob, but Bob's site could throw away the APP drop-box it offered and any messages recieved through it if Alice never validates her identity or never agrees to be contacted. Conversely, Alice can cut Bob off at the drop-box at any point. Private APP drop-boxes that can be thrown away are essential to this.

The above, of course, assumes a mutual connection. Following someone could still be done with feed polling. But, for one-way private subscription, the process flips - Alice's OpenID provider extends an APP drop-box upon validation to allow Bob's site to send her newsletters. Alice can't send responses to Bob unless he POSTs a reciprocal drop-box, but maybe that's fine for this use case. Spam could be controlled in this channel by cutting off the private APP drop-box Alice extended to Bob's site.

Now, consider Jabber / XMPP servers as gateways to the above system of APP drop-box exchange not entirely unlike the IM bot run by Twitter. Web-based archival and optional publishing of messages, but with desktop notification and message transmission.