[JDEV] Jabber server in Java

Iain Shigeoka iainshigeoka at yahoo.com
Tue Jul 3 12:31:34 CDT 2001

--- Bill Abbas <zsa at expertq.com> wrote:
> On Sunday 01 July 2001 11:04, you wrote:
> >
> > For example, there seems to be
> > a built-in assumption that client's must trust their
> > server (a situation that seems obviously ripe for
> > exploitation) 
> I do think it's an important feature for a server to be 
> able to read the messages that pass thru it.  E.g. if the 
> clients are used to provide in-field support or sales 
> assistance for a business, you need to be able to log what 
> your support rep told your customer.  

I like the debate.  :)  I should put in the caveat that this is a
discussion of the "most secure" mode of the server.  Clients may relay
these requirements as needed (not all messages must be encrypted or
signed, you can send plain text messages as you like (however the server
on the recipient may refuse messages that aren't signed or encrypted)).

Second caveat being that my primary interest is JAM and not IM
specifically (IM only as an application of JAM).

I think the server should only have access to these pieces of information:

Sender (indicated by JID & signature)
Recipient (indicated by JID & signature)
Quality of Service Descriptors

If you want to log information at the "server" it can only be these three
items (and the size of the message).  If you want to log application
specific items, then the "recipient" should be a "chatbot" operating on
behalf of the application that has permissions to access the message.

My premise, which I've only discussed with some people here, is that I see
the server as having a much smaller responsibility than in the current
Jabber protocols.  It is essentially a security, QoS, store and forward,
and routing service.  All other activities are handled by "chatbots" that
can be implemented as internal functionality, modules, or external

My intent is to shrink the server's responsibility and create a solid
foundation.  All the other aspects of creating a working IM system are at
the "application protocol" level.  This includes things like presence,
chatrooms/conferencing, etc etc.  

Essentially, my goal is to create a JAM framework with the server only
providing the base foundation you can build on top of.  Standard JAM
services can begin with those that support IM such as presence/roster
management, pub/sub, user directory browsing, etc.


Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail

More information about the JDev mailing list