On Wed, Aug 26, 2020 at 08:33:58PM +0000, Caveman Al Toraboran wrote: > 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.
Nothing wrong with Thatcher. Although, British politics are less amusing than their American counterparts, but there are exceptions. https://www.youtube.com/watch?v=HDVwidaHwSc More seriously, as Grant said, it's probably best to stray away from this politically charged area entirely. Mentioning leaked e-mails of an American presidential candidate in the title of an e-mail solution is akin to naming an SSL implementation something like Heartbleedin'. It just gives off the completely wrong "vibe". > 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. Yes, but (I assume) there were not many positive reports. It does seem an odd thing after which to name an e-mail solution! > 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). I meant (a), in the sense that you should probably write it up in a more presentable fashion than a GitHub README page. You might want to nicely typeset it in TeX or something to make it seem more serious. Just a suggestion... In which language are you intending to write the reference implementation? I'd suggest writing it in a relatively low-level language, so it's easier to read and port without making too many assumptions. > 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?). You really need to define more goals and non-goals; two non-specific goals, and one non-goal really isn't enough to form an entire specification. Additionally, I noticed that you have written that the "actual message" will be restricted to UTF-8 with no HTML/JS/CSS, which you collectively describe as "self-hating formats" (?). While I (and most on this list) despise the use of the aforementioned formats in e-mails to the appropriate extent, I struggle to see how you are going to prevent them being transmitted using HillaryMail. All of the control codes of HTML are fully representable in ASCII, which is a strict subset of Unicode. How are you going to prevent people transmitting HTML over the protocol? It is up to the client to parse the HTML into its intended aesthetic form; the server has nothing to do with it. The only solution I could imagine is rejecting all messages containing attachments with MIME types other than plain-utf8, but is that really a good idea? I am interested, but gravely skeptical. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA
signature.asc
Description: PGP signature
