Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Fri, 9 Nov 2007 08:11:00 +0900 "Daiki Ueno" <address@hidden> wrote: 

DU> You apperantly misinterpreted their non-negative opinions as positive
DU> supports of including encrypt.el.

DU> I think their opinions are neutral.   They should be considered as 0.
DU> Now the score is 1-2 (including you, RMS and me).  Are you alright?

As I said, I'm asking for votes from everyone, including Reiner and
Stefan, so we don't get mired in semantics.  If votes are conditional
("I'd want encrypt.el if it did X") that's fine, I can answer those
questions.

>> I think I have said enough on the topic to make up everyone's mind.
>> I will integrate with rijndael.el if anyone needs that.

DU> I think you haven't told enough.  I asked what kind of people do you
DU> think of your users, again and again.  You just told about your
DU> imaginary users.

Well, I've been supporting Emacs users for a while with various Gnus and
Emacs questions, so I have some idea of what they like.  I may be wrong,
but I am working in good faith to provide users what I think they want.
I have not advertised the library so I don't have user feedback.

DU> IIUC, your users must satisfy at least one of the following conditions:

DU> (1) They have some difficulties on installing GnuPG.
DU> (2) They are so interested in cryptography that they want to select
DU> ciphers or rather to implement them, and want to use their ciphers
DU> through too ristricted file-based API.

DU> I estimate the user base to be quite few.  

You're not exactly right.  I also want to help users who can't or won't
install GnuPG (this is common for me when I administer Unix systems; on
Windows machines users may not have permission to install it even for
themselves, etc.).  Furthermore, GnuPG is not the only encryption tool
available, so it's not fair to the users to assume (1) applies to them.

The encrypt.el API can change as needed.  The idea of a simple standard
encryption API is more important to me than the implementation.  I see
no reason why the API should not support string and buffer encryption;
if you or anyone else would like to see that in encrypt.el then let me
know.  The essentials, to me, are 

1) flexible models that can accomodate EasyPG and other libraries,
especially user-supplied ciphers and interfacing with external
steganographic tools.  I think these models should actually be
stackable, e.g. "hide and encrypt my passwords in this image."

2) easy configuration by the user (thus the file-based setup right now,
because it's familiar to Emacs users).

3) easy API for those who need to integrate it into their code (but this
should be efficient so we don't store data in memory unnecessarily, of
course)

4) non-invasive (no hidden hook action, etc.)

If you agree with these goals, great.  I apologize if they were not
clear before.

DU> Otherwise we should make GnuPG installation easier, or provide more
DU> flexible API for user-defined ciphers, including encryption of
DU> strings and buffers as well as files, support for public key
DU> encryption, or other many important features that encrypt.el lacks.

It's not clear if you are interested in working with me to improve
encrypt.el or only within EasyPG to achieve those goals.  Either way,
I'll be glad to assist you any way I can.

Ted