From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id E2C111F4B4; Fri, 2 Oct 2020 20:08:30 +0000 (UTC) Date: Fri, 2 Oct 2020 20:08:30 +0000 From: Eric Wong To: meta@public-inbox.org Subject: Re: Thoughts on search-based imap mailboxes Message-ID: <20201002200830.GA17908@dcvr> References: <20201002143444.itpfbhg75wqy3eva@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201002143444.itpfbhg75wqy3eva@chatter.i7.local> List-Id: Konstantin Ryabitsev wrote: > Hello: > > While discussing something else on the kernel.org users list, the Btw, is this list public? > question of "virtual inbox folders" came up when talking about imap and > public-inbox. Here's how I imagine it could work in a way that doesn't > require any kind of real user management. > > - any site visitor can create a saved search against any index, which > would be generated with a random name (e.g. guid4) and stored on the > server via a simple guid->(index, search terms) mapping > - if imap is enabled, any user can also create an imap "account" that > would also be a guid random string, perhaps with a random password as > well (or no password, since guid4 strings should suffice) > - users can freely associate saved searches with these accounts, perhaps > optionally allowing them to save them with aliases, such that the > record is: > user_guid->(saved_search_guid, alias) > - when logging into imap with an actual random account name, the > associated inboxes would be displayed instead of the general listing > - accounts and saved searches that were not accessed within $DAYS would > be automatically purged > > What are your thoughts about this scheme? I like it because it respects > users' privacy, since we cannot map accounts to developers, and because > it doesn't require any kind of central identity gatekeeping. Anyone > setting up a public-inbox mirror can immediately start using this scheme > without needing to set up any kind of identity management backends. I actually considered something nearly identical several years ago with NNTP (and GUIDs or base-64-queries as NNTP group names). Maybe it can be done; but temporary storage + expiration policies would require more admin overhead and possible permissions problems if JMAP and IMAP are run as different users. The GUID/base64 mapping might also require a dedicated client-side tool and might not be very usable from normal MUAs. Right now, one of the most annoying thing for me with using public-inbox-imapd is the inability to mark messages as Seen using normal MUAs. A client-side tool is likely required anyways, I'm thinking having saved search functionality in a local tool writing to Maildir/mbox might be the best way forward as w.r.t. scalability and offline access (and reading + saving flags from the Maildir/mbox). External/detached index I'm working on for global search will also be appropriate for client-side tooling, I think, as it's being designed with non-public-inbox data sources in mind, too.