[Wocky] SIPB Jabber

[Greg Hudson]

Hi, Timothy.  Here's what I know.

On Sat, 2006-06-24 at 21:33 -0400, Timothy G. Abbott wrote:
>  	- the lack of a useful "instance" feature

Do you mean the ability to subscribe to all or a part of a discussion
node, or the ability to tag messages with a topic field within a
discussion node?

The Jabber protocol includes <subject/> and <thread/> elements within
messages, and I believe our server supports them just fine.  This is
more an issue of client support; I think popular Jabber clients
generally do nothing with those fields.

>  	- the lack of something to fill the role of owl (a text-based 
> client that can reasonably thread several classes)

I would dearly love to see Jabber support within owl, and I think kretch
would also like to have that.  (He started working on it, in fact,
although I don't know if he gave up.)  At the moment, I don't know of
any plan to allocate IS&T resources towards making that happen.

jwgc can be used in text mode like zwgc can, and I expect to hack up vt
support for my own use using jwgc, but that's not really a satisfying
end-user solution.

>  	- the fact that one does not seem to be able to usefully log in 
> from more than one place at once.  (currently, it seems to send to the 
> most recent place you sent from)

We have a change in testing to send messages to bare JIDs to all
connected resources at the highest priority level.  I will try to get
that into production soon.  A more serious problem is not being able to
use the same nickname for multiple resources within a multi-user chat.
I believe that could be solved in practice by the MUC component, but I'm
not sure if JEP 045 has considered the problem.

>  	- the fact that jabber conferences don't really work like zephyr 
> classes: in particular, they don't provide an opportunity for anonymous 
> presence.  It should in principle be possible to have conferences working 
> both ways, possibly running on different servers/ports.

There may be movement on this front in the future, but I don't think I
can give details.

Certainly, the open source world could use a better implementation of
Jabber multi-user chats than the one we're currently using, and we could
as well.  I've heard of one project in this space (Palaver), but I think
it was stillborn; its dev list only contained traffic in the first month
of the project's life.

>  	- there doesn't seem to be support for inauthentic sending, or 
> logging in with a weird kerberos principal (such as one might want for 
> sending authentically as a daemon).

We're concerned about the spam potential of allowing unauthenticated
access; as a federated system, Jabber is more likely to attract spammers
than an obscure local system like Zephyr.  Jabber's solution to spam is
to filter at the domain level (as it's somewhat difficult to forge your
domain), and that only works if domains are authenticating reasonably
well at the user level.

Allowing logins with multi-component Kerberos principals is an easy
problem to solve at a technical level; the hard part is deciding what a
JID should look like for a multi-component principal, since you can't
have a / within a Jabber username.  We would ideally like that decision
made at a standards-body level, but it doesn't look like that's going to
happen easily, so we may just make something up.

>  	We would like to know which of these issues are likely to be 
> receiving active development within IS&T before a release.

We don't really have a roadmap at the moment; there are some big
unknowns which need to be resolved first.  I would suggest that effort
spent in the client space (working with the upstream client authors) is
least likely to be wasted.