[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)
ogoffart at kde.org
Sun Sep 10 08:01:40 UTC 2006
Le dimanche 10 septembre 2006 05:13, Ian Paterson a écrit :
> Anyway, simple client isn't really an issue here, because it is
> absolutely trivial for clients to switch on auto-archiving (just send
Yes, but what if i use an old client which doesn't support the feature at
Message are then not logged -> data loss
> If the user's client doesn't know how to switch auto-archiving on, then
> it certainly doesn't know how to retrieve the messages!
I may just use some web client or tiny client when I'm out of my home, and a
smart client when I'm at home
> [...] You can't achieve OTR
> without JEP-0155 (or something else that does the same thing). Even if
> you implement OTR on the server, you've still got to ask your contact
> not to log messages in any of the numerous other ways that are possible.
> So you always need JEP-0155. So the question becomes: "What is the point
> in having server OTR if you've already got JEP-0155?" IMHO it just adds
> unnecessary complexity to both client and server.
So the server is supposed the analyze JEP-0155 messages ? ok
And if the other client doesn't support OTR (but his server does) ?
Maybe could work if a <otr/> tag is added in messages so the server know it is
> With manual archiving the idea is you don't trust your server (the
> messages hopefully arrived through an end-2-end encrypted session). So
> the client should perform both encryption and decryption.
> > - Else, how are the secrets keys shared between clients ?
> That is beyond the scope of JEP-0136. But perhaps we could add a note?
> Since the private keys are long-lived, they could be transported via
Not really user friendly.
Or is encryption reserved to geek ?
> Alternatively, they could be password encrypted and then stored
> on the server using a to-be-defined standard protocol (on my list of
> protocols to write in 2007).
> With auto-archiving things aren't so clear. [...]
The problem i see in the current implementation is that each client must have
the private key in order to encrypt. or to enable automatic archiving wioth
The possible solution is to let the server aware of the public key, so it can
generate secret session keys himself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards