waves in the aether

I just had an interesting chat with hawke about presence and transports. It may seem pedantic, but I think it strikes at an important point. A lot of clients assume that a jid must have a node; miranda,iChat,gtalk come to mind. If that jid lacks a node then it must be a transport, e.g. behave fundamentally different than a typical IM client connection. In other words the jid is being used to determine the basic functionality of an entity on the xmpp network.

Below is the chatlog, but it can be summarized as:

• hawke asserts that presence is a mutual agreement for communication
• I assert that presence is a reflection of an entities availability

This post is a solicitation for opinions.

Below is the chat log

[12:11] hawke> since most clients will show the quser
service as a transport, instead of (or as well as) sending the
message, just send offline presence.
[12:11] hawke> then they can just log back in
[12:11] hawke> instead of the ‘status on’ message
[12:12] zion> thats a bit client specific though
[12:12] hawke> How so?
[12:12] zion> quser is not intended to be a transport
[12:12] zion> just because it doesn’t have a node in the jid
[12:13] hawke> I’ve not seen a client that determines
transport vs. other contact any other way.
[12:14] zion> emacs-jabber ;)
[12:14] zion> yeah… that semantic is annoying
[12:14] zion> so I don’t want to encourage bad habits
[12:14] zion> the client should disco to find out what it is, not use
the jid to assume
[12:14] zion> to many clients to that, and it sucks
[12:15] hawke> True
[12:15] zion> the jid is an identifier, nothing more
[12:15] hawke> But even so, the same thing applies to
quser as actual transports
[12:15] hawke> you still log on and off by sending
presence
[12:15] zion> no… there is not log on/off
[12:15] zion> I added that ability because it was requested
[12:16] zion> its a presence aware node on the jabber network
[12:16] zion> it doesn’t proxy your messages to another network
[12:16] hawke> I think the distinction between
“list/delist” and “logon/logoff” is pretty unimportant for this
purpoose.
[12:16] hawke> too many “o”s.
[12:16] zion> it is important actually
[12:17] hawke> oh?
[12:17] zion> if you go ‘away’ on aim/msn/yahoo then you are still
reachable
[12:17] zion> you are still connected to that network
[12:17] hawke> How does that relate?
[12:17] zion> so there is a diff between list/delist and logon/logoff
[12:18] hawke> Going “away” is different from logging
off though
[12:18] zion> thats my point!
[12:18] hawke> If I send offline presence to a
transport, I am logged off not set away
[12:18] zion> exactly
[12:18] hawke> if I send offline presence to quser, I
am delisted/no longer reachable to the qunu web service
[12:19] zion> there is NO logoff from qunu
[12:19] zion> you will not be listed
[12:19] zion> but quser can still contact you
[12:19] zion> since you are still on the jabber network
[12:19] hawke> Obviously.
[12:19] zion> qunu is a jabber service, not a transport
[12:19] zion> there is a distinct difference and the semantics of a
transport do not apply
[12:20] hawke> I know that; the logic is the same
though — log off/on.
[12:20] zion> if you log off aim, can the aim network still contact
you?
[12:20] zion> no
[12:20] hawke> Only the terminology is different.
[12:20] zion> no its not
[12:20] hawke> but that’s “can’t” vs. “won’t” isn’t it?
[12:21] zion> presence is significantly different than network
connection
[12:21] hawke> if I log off of quser, it
won’t/shouldn’t be inviting me to rooms.
[12:21] zion> inviting is only one activity
[12:21] zion> and there is no ‘log off’ quser
[12:22] hawke> Sure there is
[12:22] zion> *sigh*
[12:22] hawke> if I send offline presence, I am logged
off
[12:22] hawke> am I not?
[12:22] zion> if you send me offline … does that mean I am a
transport?
[12:22] hawke> I am no longer listed in the web
service, and I won’t be invited to rooms any more.
[12:23] zion> just because your client forces those terms in the UI
does not define it
[12:23] hawke> No. I’m not saying it is a transport.
I am saying that the particular action of sending online/offline
presence that applies to transports also applies to quser
[12:24] zion> right. if you send directed offline pres to quser, then
it will think you are offline and treat you accordingly
[12:24] hawke> Yes.
[12:24] hawke> though it will still respond to
messages.
[12:25] zion> I lost track of where we are… we seem to be
disagreeing about something, but saying the same things
[12:26] zion> you want quser to behave like a transport by sending
presence offline instead of using status on/off
[12:26] hawke> Let me restate my suggestion: The status
of quser should reflect the user’s listed status on the quser web
service.
[12:26] hawke> yes
[12:26] zion> my argument is that is not appropriate, because quser is
not a transport
[12:26] hawke> quser is a presence proxy.
[12:27] hawke> (and metadata bot, but that’s not
relevant for this purpose)
[12:27] zion> so quser should send an offline presence to the user
[12:27] zion> which will hide it from the roster ui
[12:27] hawke> I think so, yes. Sending the message,
so that they notice is also valuable.
[12:28] zion> but quser is not offline
[12:28] zion> and the user is not offline
[12:28] hawke> True.
[12:29] hawke> Well
[12:29] zion> imo, pres should indicate the availability of an entity.
[12:29] hawke> the user is “offline” as far as the
website is concerned.
[12:29] zion> not exactly correct. the website is just a jabber
client.
[12:30] zion> so the user is delisted from results, but not offline
[12:30] hawke> and with transports, presence doesn’t
indicate whether the service is available either
[12:30] hawke> it indicates whether or not you’re
logged in to it.
[12:30] hawke> For the purposes of the website, what’s
the difference between being delisted and offline?
[12:30] zion> currently, nothing ;)
[12:31] hawke> QED.
[12:31] zion> qed?
[12:31] hawke> http://en.wikipedia.org/wiki/Q.E.D.
[12:32] zion> ex: we are going to be incorporating pubsub into the
service
[12:32] hawke> OK..
[12:33] hawke> Does the users presence have any effect
on pubsub?
[12:33] zion> it should
[12:33] zion> e.g. if they are really ‘offlien’ vs ‘away’
[12:34] zion> if pres != chat || online then they are delisted
[12:34] hawke> OK..
[12:34] zion> if pres != chat || online || dnd || away || xa then send
them pubsub events
[12:35] hawke> So, only send them pubsub events when
they’re offline, or am I missing a status there?
[12:36] zion> only send them pubsub events when they are connected to
jabber, if they are offline don’t
[12:36] zion> there is a diff between ‘I am connected’ and ‘I am
online/away/xa/etc..’
[12:37] hawke> but surely you can send pubsub events
regardless of quser’s status?
[12:38] zion> of course… we could set it to offline and still send
stuff
[12:39] hawke> As I see it, the user sending directed
offline presence [to quser] means “I don’t want you to talk to me any
more”; quser then sends its own offline presence confirming that.
[12:40] hawke> So when quser decides “I’m not going to
talk to you any more” it should do the same thing.
[12:41] zion> you assertion is that presence is a mutual agreement of
communication
[12:41] zion> my assertion is that presence is a reflection of an
entities availability
[12:41] zion> regardless of its role
[12:42] hawke> OK, so amend that to add “…unless you
talk to me first.”