core dump

Welcome to the world of the hat. Right of admission reserved.

hat = hyper availability token

So how does a hat work? Right now, a hat is a jid. But..
.. but that jid is not necessarily the ultimate jid.

Woah, Nelly. Ultimate jid?!? What say who?

Let's start with a use case.

Okay, let's say I wish to deal with a forum, and I want to have a jid for that forum. I could register a jid, phycon@spqr.forum, set up my user-agent to connect to the server for that jid and be happy, except that this soon becomes unmanageable. Especially when I want to use another client.

So.. I ask my hat-rack to register the jid. The hat-rack is a bot, user-agent, whatever, that will then go forth and register the jid (if the server is open. otherwise user intervention required) and seamlessly forward messages, presence &c. between me and the spqr public.

hatrack = Hyper Availability TRAnsport Connection Kit

Like a transport. For jabber to jabber.

I then get messages from:
dude[at]ranch.com[^]phycon[at]spqr.forum@hatrack.jabber.server

or, in more human-readable form:
dude@ranch.com via hat phycon@spqr.forum served by hatrack.jabber.server
A mouthful it is, but it's a jid.

Then if we had a clever forum jabber server with a built-in hat-rack, I could have:
dude[at]ranch.com[^]phycon@spqr.forum
Where I would have had to register with that server's hat-rack with my own jid. But my jid would still be masked from forum users. Of course my 'own' jid could in turn be hat-racked.

So, what we then have is the use of jids which give specific identity away, and retain anonymity. This is something like the behaviour of spamgourmet.com or '+' addressing, except that having a jid on a domain implies some relationship between oneself and the domain. Said another way, one is using the domain of the jid to offer meta-identity; that of a relationship with the server.

Some more examples:
box291@6600.pobox.co.za
student001@myuniversity.ac
dennis@ups.com
mark@myetailer.com

Each jid is used where that identity has meaning. So we use our university jid to talk to professors, establishing from the get-go our affiliation. Likewise, requests for auth to a jid in a particular domain imply assumed affiliation and allow the user to scope a request.

Disposability

Then we have the issue of disposability of jids. As with e-mail, sometimes an address will become compromised, if we've been creating a number of jids, we have some notion of where the undersirable behaviour has originated. The compromised jid can then be discarded if necessary and all other domains (of course) remain active.

Presence

Another issue is when and what presence to be using. One option would be for hat-racks to have 2 modes: default-off and mirror. In default-off mode, the user needs to bring each hat online as and when required, in mirror mode, the hats mirror the status of the upstream jid. Possibly per-hat granularity is a good idea.





Interesting linkage:
http://www.passel.org/planet/

posted by The Elusive Phycon @ 5:01 pm