From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-1.6 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: meta@public-inbox.org Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 8A37D20830; Mon, 11 Apr 2016 03:41:04 +0000 (UTC) Date: Mon, 11 Apr 2016 03:41:04 +0000 From: Eric Wong To: meta@public-inbox.org Subject: POP3 server? Message-ID: <20160411034104.GA7817@dcvr.yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: Thinking about it more, supporting POP3 would require no more server storage overhead than running a mlmmj/mailman instance. And unlike running mlmmj/mailman, it still goes with the "pull" model we favor with public-inbox and avoids the impedance mismatch of NNTP for reading and SMTP for posting. Users would "login" using the list address and a unique password they generate themselves. The password would be used as a cookie to keep track of which messages the user has fetched. All the POP3 server would have to do is keep track of is the cookie and which message (git commit SHA-1) they've seen in a key-value store. The caveat is if the server admin screws up and loses the key-value DB, then users will see all messages again :< The k-v store would probably be SQLite, though, to reduce installation dependencies since we already (optionally) use SQLite for Message-ID prefix matching in the WWW interface and NNTP article number mapping.