[Standards-JIG] Thought about serverside messages archives

Olivier Goffart ogoffart at gmail.com
Sat Apr 15 16:10:50 UTC 2006


Le Samedi 15 Avril 2006 14:10, Ian Paterson a écrit :
> We will need new server-side search features too (searching on subject
> and/or content). Do we want anything more than a simple word or phrase
> search? 

A simple search with some operators  (+ , - , or , "" ) could be enough.
(and the ability to select a range of date, the JID,...)

If more advanced search is needed (regexp) that will need the client to 
perform the search on the local copy.  I don't think the average user need 
that.

> If so then IMO Archive Search should be a separate JEP that 
> builds on JEP-0136. Jon Perlow might be in a very good position to
> author that. ;-)


> > I'd like to see [archiving] implemented in server as soon as possible
>
> Yes! IMO the only barrier to pushing JEP-0136 quickly to draft is the
> difficulty of the encryption section. Perhaps that could be separated
> out into another JEP too?

I think it should be for another JEP.

I personally think that the archive should not be encrypted, because
 - We should trust the server   (the server admin can log all message in plain 
text if he want)
 - It make impossible searching
 - More complex   (the need to push back message)

But I agree it is easier and more tempting to the server admin to look into 
the archive if it is freely available. Or if the server is compromised the 
whole archive could be get by the attacker.


Possible solution: Asymmetric encryption, The server know the public key and 
automatically encrypt message.  (the key is exchanged using JEP-0050)

And how to make a search ?
   - force to have a local archive
   - Send the private key to the server with the search request.
   - Use indexing on the server. 


> 2. Autoarchiving is not compatible with the evanescent keys used for
> secure end-to-end encryption - so you have to trust your server and your
> correspondant's server.

Agreed, if JEP-0027 is used, searching will not work fine.

> Autoarchiving is certainly more practical than Push Archiving, and
> legislation makes it necessary in some cases. So in practice people will
> use it. But IMHO, for the reasons above, the JEP should require
> autoarchiving servers to also support Push Archiving (not difficult). In
> line with Jabber's "simple clients" philosophy, clients could choose not
> to implement push archiving.

I fully agree.

> Trejkaz wrote:
> > I would rather opt for doing it as file transfer between clients
>
> I think that the file format could be defined in JEP-0136, but any
> client-2-client synchronization process would be outside the scope of
> JEP-0136.

I don't think the file format definition should be defined in JEP-0136.
Only the exchange format should be defined there
(see the JEP-0013 (Flexible Offline Message Retrieval) even  if it is not what 
we need, it is a protocol like that)

Another JEP could contains a file format. 
But file transfers between client anyway require both client to be running at 
the same time, which we can't assume in general.
And the average user doesn't change often his main client (and he doesn't need 
to download the whole archive on each client he use)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060415/2e1deb80/attachment.sig>


More information about the Standards mailing list