On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon <a...@suugaku.co.uk> wrote:
> Why the name "HillaryMail", and why does the logo contain a picture of
> Margaret
> Thatcher? ;-)
very true (re: thatcher). now i cannot unsee the
thatcher in the pixel art. i have 2 options:
(1) rename protocol into thatchermail.
(2) find another pixel art that's actually for
hillary.
i got the thatcher pixel art from a site that
claimed it's hillary [1].
as for the name "hillarymail", nothing against
her. it's just that i heard so much about
hillary's mails up to a point all mails started to
feel as if they belong to her.
i also named my passwords manager after nsa [2]
for a similar reason (even though i find nsa to be
much more trustworthy than my neighbours).
> More seriously, do you intend to write a reference implementation, or submit
> this as a more formal R.F.C. in the event of it attracting more attention?
i intend to eventually write a reference
implementation either way (hopefully). specially
that this seems to me very easy to implement, yet
it seems also powerful.
not sure what "formal r.f.c." means.
(a) if it means a less ambiguous description,
then "yes, but at a natural pace based on
demand" (in the spirit of occam's razor).
(b) if it means an r.f.c. submitted to
isoc/ietf, then "no". i think we should
ignore standard bodies for awhile since they
seem to be ignoring us.
> Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the
> best way of attaining support; I must admit, I have never seen that in an
> initial protocol proposal.
imo that's a parsing error on your side. to me
"idiot" didn't refer to smtp/pop/imap users. it
rather referred to those those who can't use
address books or bitcoin.
either way i've just replaced "idiots" by
"people". "idiot" wasn't justified either way.
> I'm also slightly confused regarding the "goals" section. By "easy to
> install/use", do you mean "easy" for the people implementing the protocol, or
> the people making use of said implementations? "Traditional" SMTP mail clients
> have always been pretty straight-forward for me, although the difficulty
> involved in implementing an M.T.A. is another story. I find this point rather
> equivocal.
i mean easy for both, but subject to the
constraints specified under "goals" and
"non-goals".
e.g. if becoming easier would cause the protocol
to end up needing to trust a sys admin, then
that's not acceptable.
but if it is possible to make it easier while
still satisfying the constraints
(goals/non-goals), then that's a good step forward
(perhaps draft one?).
------
[1] http://pixelartmaker.com/art/dffec5c6b08b94e
[2] https://github.com/al-caveman/nsapass
note: trying to remove pexpect dependency as
it sometimes causes indefinite waiting. so it
is not ready for those who want a solid app
yet. that said, i really like it so far. imo
after removing "pexpect" it will be perfect.
