[Wocky] SIPB Jabber

[Timothy G Abbott]

On Mon, 26 Jun 2006, Greg Hudson wrote:

>>  	- 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.

Agreed.  I guess we should probably talk to kretch, since there are all 
sorts of rumors regarding the status of his Jabber in owl efforts.

> 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.

Unfortunately, multi-user chat is one of the most important features of 
zephyr, and the one where having more than one resource using the same 
nickname is most useful.

>>  	- 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

That seems to be a quite reasonable concern.  Would it be possible to do 
some form of unauthenticated access that only worked inside the MIT 
domain, and required the accessor to be net18?

>>  	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.

Okay.  Thanks for the extensive information.

 	-Tim Abbott