Standards Confusion and Harmonization
over at the IEEE is an interesting read for anyone in the jabber space, think pub-sub for a start ;)
Software engineers have long debated the practical benefits of standards. The argument against standards is that setting a bar creates the risk of it being far lower than it should be, resulting in a free pass to do less; without the bar, users would do more. However, proponents of standards claim that having a bar to be hurdled is better than no bar at all.
We are being discussed.
.. thus the tangled web is wo'n.
jid escaping for hatrack [at]
After some consideration, with nr's help, the following format seems sensible for hatracked things:
When rendering a hatracked jid, inserting "\nvia: " for ^'s (and maybe unescaped @'s) leads to enhanced readability.
Use JEP-0144: Roster Item Exchange, like a normal transport, to pass roster info from the hatracked jid.
id bound vs agnostic registration
Transports are either id bound or agnostic. An id bound transport only allows registration for one id in the domain the transport provides access to; an id agnostic transport allows registration of multiple ids from one jid.
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,
, 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:
or, in more human-readable form:
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:
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:
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.
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.
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.
Jidam and Jideve
And jidam and jideve strolled through the garden of jiden. And jideve was tempted by the serpent to eat from the wikedpedia. And jideve realised she was naked, her jid was bare and exposed. And they clad themselves in fig-leaves. And jidam wore a fig-leaf-hat. And the admin spake unto them thus: "Now that you've finally made yourselves decent feel free to roam to other domains; but please try not to expose your naked selves to too many people, it could come back to haunt me. And I might have to smite your user account."
The hat, the source of anonymous identity.
Someone arrives wearing a UPS hat, they work for UPS, you take your parcel, you have-a-nice-day-now. Did you get his name? Would you recognise him in a line-up? Should you?
The next day:
Someone arrives wearing a UPS hat, they work for UPS, you take your parcel, you see it is torn. "Hang on a sec, um..", quick glance at his badge, "Dennis. It looks like something is wrong with my package." Ooh! we got his name. Lucky us! Is that really his name? Did he borrow a badge because his aunt mavis put his through the drier? Does it matter? Well, maybe a little.
JabMark: delicious jabber
A jabber/xmpp driven online bookmark management system.
Drag link from browser gives string of form:
send this to jid of service, bookmark added, service returns list of suggested tags.
Transmit command "tag tagname1 tagname2" to service to tag the link.
Other commands include
"alltags": show list of all tags
"recent": show recently added sites
"pull 'num'": pull a site into focus by its number in the last returned result set
"search 'string'": search user's db for marks with matching substrings
table sites(user_jid, url, desc string)
table tags(user_jid, url, tag string)
Jabber/Interworlds What hat are you wearing?
Tokens are ambiguous, overused and confusing. Hand in your token, and take a hat!
Hats make sense (even though they're somewhat out of fashion irl) as a real-world analogue to all this pill/token hokey I've been spouting.
Your company can give you a hat to wear which, when you're wearing it will let denizens know that you are ready to work, answer questions, or be asked to debug your nasty code.
Spamgourmet-esque actually. Interact with people wearing relevant hats, 90% of the time they won't look beyond the hat, but you can at your discretion show them your other hats or your raw address.