From: Eric Wong <email@example.com> To: firstname.lastname@example.org Subject: Re: Thoughts on search-based imap mailboxes Date: Fri, 2 Oct 2020 20:08:30 +0000 [thread overview] Message-ID: <20201002200830.GA17908@dcvr> (raw) In-Reply-To: <email@example.com> Konstantin Ryabitsev <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2020-10-02 20:08 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-02 14:34 Konstantin Ryabitsev 2020-10-02 20:08 ` Eric Wong [this message] 2020-10-03 14:50 ` Konstantin Ryabitsev 2020-10-03 19:40 ` Eric Wong 2021-02-05 22:37 ` James Bottomley 2021-02-06 0:01 ` Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://public-inbox.org/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201002200830.GA17908@dcvr \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Thoughts on search-based imap mailboxes' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
user/dev discussion of public-inbox itself This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/meta git clone --mirror http://czquwvybam4bgbro.onion/meta git clone --mirror http://hjrcffqmbrq6wope.onion/meta git clone --mirror http://ou63pmih66umazou.onion/meta # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 meta meta/ https://public-inbox.org/meta \ email@example.com public-inbox-index meta Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.mail.public-inbox.meta nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.mail.public-inbox.meta nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.mail.public-inbox.meta nntp://news.gmane.io/gmane.mail.public-inbox.general note: .onion URLs require Tor: https://www.torproject.org/ code repositories for project(s) associated with this inbox: https://80x24.org/public-inbox.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git