Presence is not an Identity feature

I realized in my "Unique Visitors" post that I skipped some background - didn't "show my work" as every math teacher I had always said.

When Google released GTalk, I remember feeling like they had missed an opportunity to correct the Presence, Identity, Messaging and Accounts model - that they should have made "location" more than just metadata, but I don't think that's right, actually.

On the PC side of the Instant Messaging (IM) universe, Presence is exerted by an Identity, and (nowadays) often qualified by Location (for Location Based Services) and/or Network of Origin (for interoperation messaging systems), but I think Presence, especially for Comcast, is really a device feature, and Identities are transiently bound to those devices, generally with an (essentially) eternal TTL (time-to-live), though in the case of PCs, that TTL amounts to IM session length.

Identity is a kind of user virtualization construct (usually reasonably synonymous with "Credentials": username and password - at least for our purposes), while Presence advertises availability for messaging, and Messaging is generally a point-to-point session negotiation and communication pipe, though it may be one-to-many (broadcast), or many-to-many (chat). Note that Messaging and Presence need not necessarily be interdependent. Finally, Accounts are a billing relationship construct.

A typical use case in a househould is likely to involve multiple STBs (set top box or other consumer electronics device on the Comcast networks), multiple .net IDs (e-mail addresses), and multiple PCs in the house, where Presence, Identity, Message and Accounts overlap each. And of course, wireless, school/office, and multiple residences complicate the picture.

Usually, scalability for Presence is scale limited by subscription/notfication events, and by that I mean the "m X n" implied by the "Buddy List" construct, where any user may be subscribed to presence notification of any n users (effectively O(n^2) ). Messaging is bound by active simultaneous communication sessions (and type - multimedia for example) and is usually O(n).

In any case, I'm just rambling now - all of that's a roundabout way of saying that messaging is a service feature, not a product :)