From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/62907 Path: news.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Hashcash on by default? Date: Tue, 18 Apr 2006 15:42:16 +0200 Message-ID: <8764l72e6f.fsf@latte.josefsson.org> References: <87d5ffrwi7.fsf@latte.josefsson.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145367898 10832 80.91.229.2 (18 Apr 2006 13:44:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Apr 2006 13:44:58 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+m11434@lists.math.uh.edu Tue Apr 18 15:44:55 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FVqVd-0006EA-PO for ding-account@gmane.org; Tue, 18 Apr 2006 15:44:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1FVqVY-0004YU-00; Tue, 18 Apr 2006 08:44:44 -0500 Original-Received: from nas02.math.uh.edu ([129.7.128.40]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1FVqTP-0004YP-00 for ding@lists.math.uh.edu; Tue, 18 Apr 2006 08:42:31 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas02.math.uh.edu with esmtp (Exim 4.52) id 1FVqTN-0005Rr-08 for ding@lists.math.uh.edu; Tue, 18 Apr 2006 08:42:31 -0500 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1FVqTH-00026u-00 for ; Tue, 18 Apr 2006 15:42:23 +0200 Original-Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3IDgGM0003724; Tue, 18 Apr 2006 15:42:17 +0200 Original-To: gdt@work.lexort.com OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060418:gdt@work.lexort.com::IM2zF93brUosD4+/:1TPR X-Hashcash: 1:22:060418:ding@gnus.org::gyxeUspyRLkjz5dZ:5LbE In-Reply-To: (gdt@work.lexort.com's message of "Tue, 18 Apr 2006 08:24:23 -0400") User-Agent: Gnus/5.110005 (No Gnus v0.5) Emacs/22.0.50 (gnu/linux) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -2.5 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:62907 Archived-At: gdt@work.lexort.com writes: > Simon Josefsson writes: > >> Lars Magne Ingebrigtsen writes: >> >>> I just switched on async hashcash generation: >>> >>> (setq message-generate-hashcash t) >>> >>> I think it's kinda neat how those payment lines appear in the buffer >>> asynchronously. :-) But perhaps we should just switch this on by >>> default? I mean, if you don't have hashcash installed, it won't do >>> anything, and if you do have hashcash installed, you probably want to >>> use it. And since the impact now is so low (what with it being >>> asynchronous and all), I think it makes sense. >> >> I like that. I've changed the default. > > I just updated and tested this. When following up to an article in > nnimap, I got two hashcash lines inserted (correctly) after a few > seconds. > > When sending mail by typing 'm' in *Group*, and then entering a name, > I found that hashcash was generated non-async when I hit ^C^C. Is > this the intended behavior? I think so. > It would be neat to begin generating hashcash once the user has > stopped editing the To:/CC: fields for a few seconds, and regenerate > any missing entries after the next edit/pause cycle, and then do a > final insert/generate on sending. This would always be correct, and > minimize delays - but sounds like a lot of work, especially for > something that could be done in the background as part of sending. Yup. I don't think it can be done in background though, ^C^C must be able to report errors to the user, and if the sending process is asynchronous, this will be more difficult. However, having it notice changes in the To/Cc fields would be good enough, I think. Do you want to work on it?