From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/64003 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: hashcash - buffer modification Date: Thu, 16 Nov 2006 11:16:47 +0900 Organization: Emacsen advocacy group Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163643522 7916 80.91.229.2 (16 Nov 2006 02:18:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Nov 2006 02:18:42 +0000 (UTC) Original-X-From: ding-owner+M12526@lists.math.uh.edu Thu Nov 16 03:18:40 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GkWpr-0008Pi-KU for ding-account@gmane.org; Thu, 16 Nov 2006 03:18:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1GkWog-0002ub-D5; Wed, 15 Nov 2006 20:17:26 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1GkWoe-0002u0-GO for ding@lists.math.uh.edu; Wed, 15 Nov 2006 20:17:24 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.63) (envelope-from ) id 1GkWoa-0000tl-Jj for ding@lists.math.uh.edu; Wed, 15 Nov 2006 20:17:24 -0600 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1GkWoG-0008GQ-00 for ; Thu, 16 Nov 2006 03:17:00 +0100 Original-Received: from [66.225.201.151] (port=54061 helo=mail.jpl.org) by orlando.hostforweb.net with esmtpa (Exim 4.52) id 1GkWop-0004wv-RC for ding@gnus.org; Wed, 15 Nov 2006 20:17:36 -0600 Original-To: ding@gnus.org X-Hashcash: 1:20:061116:ding@gnus.org::rhqWBsqLRGoydiwD:00000UIB X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.0 (gnu/linux) Cancel-Lock: sha1:28+XMM57XCM3lC5oQVC/uQq1wFs= X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:64003 Archived-At: >>>>> In gdt@work.lexort.com wrote: > This could result in saving a draft and then having hashcash appear, > and then the +hashcash draft will not necessarily be saved. It's > arguable what the right behavior is. I see, but I have none to insist about that. So, I decided not to modify the behavior rashly. Karl, please keep using the advice for some time. > Given timestamps in hashcash, one could argue that hashcash stamps > shouldn't necessarily be saved in draft mode, but generated fresh > nearer to sending. >> BTW, how do you add hashcash headers when you write a mail from >> scratch (i.e., the case where To and Cc have not been filled yet)? >> I use `mail-add-payment', not `mail-add-payment-async'. > I think both work, but the former makes you wait. > It would be nice to have a keybinding for mail-add-payment-async in > Message mode. Perhaps C-c C-f C-h (for hashcash header), or just C-c > C-h. > It would also be nice to have a hook that runs when the cursor leaves > an address fields and remains outside it for 5 seconds and that > invokes mail-add-payment-async. I don't know how to do that. The fundamental problem is that generating of hashcach takes time, isn't it? I'm not troubled with it, though. I vaguely think it would be nice to lock To and Cc headers. Those headers are unlocked at the beginning if they are empty. A user fills them if needed, and locks them using a special command which is a trigger to start generating hashcash (it might be `mail-add-payment-async'). When a user wants to change some of them, one unlocks them using another special command, which removes existing hashcash headers. >>>>> In >>>>> Karl Chen wrote: > We could add an overlay on the headers with modification-hooks > that adds asynchronous payment for valid email addresses if the > user hasn't modified headers for (configurable) 30 seconds. I see. It would be nice too. The second question. What happens if a user modifies headers or types `C-c C-c' when hashcash is being generated? Or shouldn't those commands be inhibited or deferred then? Though it doesn't seem to be easy to implement. Regards,