{"thread":{"id":"42812","subject":"[ANNOUNCE] more archives of this list","startedAt":"2016-07-10T00:48:18Z","lastAt":"2016-08-06T23:41:32Z","messageCount":11,"participants":["Eric Wong","Jeff King","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"291114","messageId":"20160710004813.GA20210@dcvr.yhbt.net","threadId":"42812","inReplyTo":null,"subject":"[ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-07-10T00:48:13Z","receivedAt":"2016-07-10T00:48:18Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Very much a work-in-progress, but NNTP and HTTP/HTTPS sorta work\nbased on stuff that is on gmane and stuff I'm accumulating by\nbeing a subscriber.\n\nThe first two Tor hidden service onions are actually on better\nhardware than the non-hidden public-inbox.org one:\n\nnntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git\nnntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git\nnntp://ou63pmih66umazou.onion/inbox.comp.version-control.git\nnntp://news.public-inbox.org/inbox.comp.version-control.git\n\nhttp://czquwvybam4bgbro.onion/git\nhttp://hjrcffqmbrq6wope.onion/git\nhttp://ou63pmih66umazou.onion/git\nhttps://public-inbox.org/git/\n\nHTTP URLs are clonable, but I've generated the following fast-export dump:\n\n\thttps://public-inbox.org/.temp/git.vger.kernel.org-6c38c917e55c.gz\n\t(362M)\n\n\tgit init --bare mirror.git\n\tcurl $FAST_EXPORT_GZ_URL | git --git-dir=mirror.git fast-import\n\tgit --git-dir=mirror.git remote add --mirror=fetch origin $URL\n\nI recommend bare repos for importing, since the trees consist of\n2/38 SHA-1 paths of Message-IDs and there's nearly 300K messages.\n\nIn contrast, bundles and packs delta poorly and only get down\naround 750-800M with aggressive packing\n(And I haven't done that in a while.)\n\n\nCode is AGPL-3.0+: git clone https://public-inbox.org/\n\n\nAdditional mirrors or forks (perhaps different UIs) are very welcome,\nas I expect none of my servers or network connections to be reliable.\n\n\nI have the \"public-inbox-watch\" command running in screen\nwatching my Maildirs, it uses a config file which is parseable/writable\nusing git-config:\n\n==> ~/.public-inbox/config <==\n[publicinboxlearn]\n\t; spam gets moved here for auto-removal:\n\twatchspam = maildir:/path/to/maildirs/.INBOX.spam\n[publicinboxwatch]\n\t; optional, adds some additional spam checking\n\tspamcheck = spamc\n[publicinbox \"git\"]\n\t; git repo for this list\n\tmainrepo = /path/to/mirror.git\n\n\t; this removes the list footer signature:\n\tfilter = PublicInbox::Filter::Vger\n\n\t; this is where my git-related mail goes (some of it is from Debian)\n\twatch = maildir:/path/to/maildirs/.INBOX.git\n\n\t; only match messages with the correct List-Id header:\n\twatchheader = List-Id:<git.vger.kernel.org>\n\n\t; next 4 lines are only necessary for HTTP and NNTP servers\n\taddress = git@vger.kernel.org\n\turl = http://ou63pmih66umazou.onion/git\n\tnewsgroup = inbox.comp.version-control.git\n\tinfourl = http://vger.kernel.org/majordomo-info.html\n"},{"id":"291117","messageId":"20160710034745.GA20270@dcvr.yhbt.net","threadId":"42812","inReplyTo":"20160710004813.GA20210@dcvr.yhbt.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-07-10T03:47:45Z","receivedAt":"2016-07-10T03:48:05Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong <e@80x24.org> wrote:\n> \thttps://public-inbox.org/.temp/git.vger.kernel.org-6c38c917e55c.gz\n> \t(362M)\n> \n> \tgit init --bare mirror.git\n> \tcurl $FAST_EXPORT_GZ_URL | git --git-dir=mirror.git fast-import\n\nOops, that is missing zcat:\n\n\tcurl $FAST_EXPORT_GZ_URL | zcat | git --git-dir=mirror.git fast-import\n\n> \tgit --git-dir=mirror.git remote add --mirror=fetch origin $URL\n\nAnd I forgot to set a branch for fast-export and just exported\na ref, so importers will need to create master explicitly:\n\n\tgit update-ref refs/heads/master 6c38c917e55c\n"},{"id":"292452","messageId":"20160728205957.GA16391@starla","threadId":"42812","inReplyTo":"20160710004813.GA20210@dcvr.yhbt.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-07-28T20:59:57Z","receivedAt":"2016-07-28T21:00:02Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong <e@80x24.org> wrote:\n> Code is AGPL-3.0+: git clone https://public-inbox.org/\n> \n> \n> Additional mirrors or forks (perhaps different UIs) are very welcome,\n\nBtw, it's possible to do quote highlighting with user-side CSS:\n\nhttps://public-inbox.org/meta/20160709-user-side-css-example@11/\n\nWill probably add classes for diff colors, too, since a git\nrepository browser with mailing list integration will happen.\n\nFor the moment, cgit + examples/cgit-commit-filter.lua allows\nsearching subjects (at least non-merge ones).\n\nSo the commit subject below is a link:\nhttps://bogomips.org/mirrors/git.git/commit/?id=7b35efd734e501f\nto:\nhttps://public-inbox.org/git/?x=t&q=\"fsck_walk():+optionally+name+objects+on+the+go\"\n"},{"id":"293178","messageId":"20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net","threadId":"42812","inReplyTo":"20160710004813.GA20210@dcvr.yhbt.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-05T09:28:05Z","receivedAt":"2016-08-05T09:34:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 10, 2016 at 12:48:13AM +0000, Eric Wong wrote:\n\n> Very much a work-in-progress, but NNTP and HTTP/HTTPS sorta work\n> based on stuff that is on gmane and stuff I'm accumulating by\n> being a subscriber.\n\nI checked this out when you posted it, and have been using it the past\nfew weeks. I really like it. I find the URL structure much easier to\nnavigate than gmane.\n\nI do find it visually a little harder to navigate through threads,\nbecause there's not much styling there, and the messages seem to run\ninto one another. I don't know if a border around the divs or something\nwould help. I'm really terrible at that kind of visual design.\n\n> HTTP URLs are clonable, but I've generated the following fast-export dump:\n> \n> \thttps://public-inbox.org/.temp/git.vger.kernel.org-6c38c917e55c.gz\n> \t(362M)\n> [...]\n> In contrast, bundles and packs delta poorly and only get down\n> around 750-800M with aggressive packing\n\nI pulled this down. It is indeed rather huge, and git doesn't perform\nall that well with it. All the usual \"git is not a database\" things\napply, I think.\n\nI noticed in particular that traversing the object graph is _really_\nslow. This is very sensitive to the \"branchiness\" of the tree. I notice\nthat you use a single level of hash (e.g., d4/9a37e4974...). Since there\nalmost 300K messages, the average 2nd-level tree has over 1000 entries\nin it, and each commit changes exactly one entry.\n\nSo what happens during a traversal is that we see some tree A, look at\nall of its entries, and see each of its blobs. Then we see A', the same\ntree with one entry different, and we still have to walk each of those\nthousand entries, looking up each in a hash only to find \"yep, we\nalready saw that blob\".\n\nWhereas if your tree is more tree-like (rather than list-like), you can\ncull unchanged sub-trees more frequently. The tradeoff, though, is the\nextra overhead in storing the sha1 for the extra level of tree\nindirection.\n\nHere are some timing and size results for various incarnations of the\npackfile. The sizes come from:\n\n  git cat-file --batch-all-objects \\\n               --batch-check='%(objectsize:disk) %(objecttype)' |\n  perl -lne '\n    /(\\d+) (.*)/; $count{$2}++; $size{$2} += $1;\n    END { print \"$size{$_} ($count{$_}) $_\" for sort(keys(%count))\n  }'\n\nAnd the timings are just \"git rev-list --objects --all\".\n\nHere's the initial sizes after fast-import:\n\n  536339725 (291113) blob\n   63767736 (291154) commit\n  929164567 (582290) tree\n\nYikes, fast-import does a really terrible job of tree deltas (actually,\nI'm not even sure it finds tree deltas at all). Notice that blob\ncontents are bigger than the fast-import stream (which contains all of\nthose contents!). That's unfortunate, but comes from the fact that we\nzlib deflate the objects individually. Whereas the fast-import stream\nwas compressed as a whole, so the common elements between the emails get\na really good compression ratio.\n\nThere was discussion a long time ago about storing a common zlib\ndictionary in the packfile and using it for all of the objects. I don't\nrecall whether there were any patches, though. It does create some\ncomplications with serving clones/fetches, as they may ask for a subset\nof the objects (so you have to send them the whole dictionary, which may\nbe a lot of overhead if you're only fetching a few objects).\n\nAnyway, here are numbers after an aggressive repack:\n\n  628307898 (291113) blob\n   63209416 (291154) commit\n   44342440 (582290) tree\n\nMuch better trees. Ironically the blobs got worse. I think there are\njust too many with similar names and sizes for our heuristics to do a\ngood job of finding deltas.\n\nHere's what running rev-list looks like:\n\n  real    6m4.933s\n  user    6m4.124s\n  sys     0m0.616s\n\nYow, that's pretty painful. Without bitmaps, that's an operation that\nevery single clone would need to run.\n\nHere's what it looks like with an extra level of hashing (so storing\n\"12/34/abcd...\" instead of \"12/34abcd...\"):\n\n  628308433 (291113) blob\n   63207951 (291154) commit\n   60654550 (873339) tree\n\nWe're storing a lot more trees, and spending 16MB extra on tree storage.\nBut here's the rev-list time:\n\n  real    0m55.120s\n  user    0m55.016s\n  sys     0m0.096s\n\nI didn't try doing an extra level of hashing on top of that (i.e.,\n\"12/34/ab/cd...\"). It might help, but I suspect it's diminishing returns\nversus the cost of accessing the extra trees.\n\nThe other thing that would probably make a big difference is avoiding\nthe one-commit-per-message pattern. The commit objects aren't that big,\nbut each one involves 2 new trees (one with ~1000 entries, and one with\n256 entries). If you batched them into blocks of, say, 10 minutes, that\ndrops the number of commits by half.\n\nWhich I computed with:\n\n  git log --reverse --format=%at |\n  sort -n |\n  perl -lne '\n\tif (!@block) {\n\t\t@block = ($_);\n\t} else {\n\t\tmy $diff = $_ - $block[0];\n\t\tif ($diff >= 0 && $diff < 600) {\n\t\t\tpush @block, $_;\n\t\t} else {\n\t\t\tprint join(\" \", @block);\n\t\t\t@block = ($_);\n\t\t}\n\t}\n\tEND { print join(\" \", @block) }\n  '\n\nOf course that means your mirror lags by 10 minutes. And you lose the\ncool property of \"git log --author=peff\", though of course that\ninformation is redundant with what is in the blobs. I haven't looked at\nthe public-inbox code but I would imagine it's mostly operating on the\ntip tree.\n\nIf you're willing to give up the cool commits, we could also just squash\nthe whole archive into a single base commit, and start building there.\nWe'd run into problems in another 10 years, I guess, but it would be\npretty efficient to start with, at least. :)\n\n> Additional mirrors or forks (perhaps different UIs) are very welcome,\n> as I expect none of my servers or network connections to be reliable.\n\nI'm tempted to host a mirror at GitHub, but I'm wary of the Git storage.\nI don't think it really scales all that well. Bitmaps help with the cost\nof a clone, but they're not magic. We still have to do traversals for a\nlot of operations (including repacks).\n\n-Peff\n"},{"id":"293179","messageId":"20160805093544.scvl4yshkfg2l26p@sigill.intra.peff.net","threadId":"42812","inReplyTo":"20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-05T09:35:44Z","receivedAt":"2016-08-05T09:36:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:\n\n> On Sun, Jul 10, 2016 at 12:48:13AM +0000, Eric Wong wrote:\n> \n> > Very much a work-in-progress, but NNTP and HTTP/HTTPS sorta work\n> > based on stuff that is on gmane and stuff I'm accumulating by\n> > being a subscriber.\n> \n> I checked this out when you posted it, and have been using it the past\n> few weeks. I really like it. I find the URL structure much easier to\n> navigate than gmane.\n> \n> I do find it visually a little harder to navigate through threads,\n> because there's not much styling there, and the messages seem to run\n> into one another. I don't know if a border around the divs or something\n> would help. I'm really terrible at that kind of visual design.\n\nI took a peek at doing something simple like:\n\n  pre {\n    border-style: solid;\n    border-width: 1px;\n    background: #dddddd;\n  }\n\nbut it looks like there's no HTML structure at all to the current\noutput. It's just one big <pre> tag with various levels of indentation\nto represent the messages.\n\nSo I guess a potential first step would be actually representing a\nthread as:\n\n  <div class=\"message\">\n    parent message...\n    <div class=\"message\">\n      reply...\n    </div>\n  </div>\n\nand so on.\n\n-Peff\n"},{"id":"293181","messageId":"20160805095941.GA1875@dcvr","threadId":"42812","inReplyTo":"20160805093544.scvl4yshkfg2l26p@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-05T09:59:41Z","receivedAt":"2016-08-05T09:59:52Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:\n> \n> > On Sun, Jul 10, 2016 at 12:48:13AM +0000, Eric Wong wrote:\n> > \n> > > Very much a work-in-progress, but NNTP and HTTP/HTTPS sorta work\n> > > based on stuff that is on gmane and stuff I'm accumulating by\n> > > being a subscriber.\n> > \n> > I checked this out when you posted it, and have been using it the past\n> > few weeks. I really like it. I find the URL structure much easier to\n> > navigate than gmane.\n\nThanks :>\n\n> > I do find it visually a little harder to navigate through threads,\n> > because there's not much styling there, and the messages seem to run\n> > into one another. I don't know if a border around the divs or something\n> > would help. I'm really terrible at that kind of visual design.\n> \n> I took a peek at doing something simple like:\n\nI'm trying to keep the visual design consistent across browsers\nwithout CSS support (I mainly use w3m) and CSS scares me:\n\nhttp://thejh.net/misc/website-terminal-copy-paste\n\n(and JavaScript has me cowering in a corner behind a chair :x)\n\n> but it looks like there's no HTML structure at all to the current\n> output. It's just one big <pre> tag with various levels of indentation\n> to represent the messages.\n> \n> So I guess a potential first step would be actually representing a\n> thread as:\n> \n>   <div class=\"message\">\n>     parent message...\n>     <div class=\"message\">\n>       reply...\n>     </div>\n>   </div>\n\nThe, <ul><li>... in the /$MID/t/ (as opposed to /$MID/T/) endpoint\nmight be what you're looking for.  See the \"[flat|threaded]\" links.\n\nI run out of horizontal space with the giant fonts I like to\nuse, but it might be preferable for some folks.\n\n\n\nAnd about the 2/38 tree structure; I am starting to avoid it\n(for Xapian users, at least) but haven't performed the reindex\non all my servers, yet:\n\nhttps://public-inbox.org/meta/20160805010300.7053-1-e%4080x24.org/\n\nOf course, Xapian is only an optional dependency and won't\naffect git internals.\n\nI might end up having to nuke history occasionally anyways,\n(in case somebody invokes the DMCA, or there's enough spam\n to warrant permanent deletion)\n\n(Will try to digest the rest of your message later).\n"},{"id":"293194","messageId":"CACsJy8DkNUD_dKwnx9nZsgvSxgdA8MH=2+rEWzMFdkigmhpJ5g@mail.gmail.com","threadId":"42812","inReplyTo":"20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-08-05T15:04:27Z","receivedAt":"2016-08-05T15:05:02Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Aug 5, 2016 at 11:28 AM, Jeff King <peff@peff.net> wrote:\n> There was discussion a long time ago about storing a common zlib\n> dictionary in the packfile and using it for all of the objects. I don't\n> recall whether there were any patches, though. It does create some\n> complications with serving clones/fetches, as they may ask for a subset\n> of the objects (so you have to send them the whole dictionary, which may\n> be a lot of overhead if you're only fetching a few objects).\n\nI'm nit picking since it's not actually \"all objects\". But pack v4\npatches have two dictionaries (or more? i don't remember) for commits\nand trees :)\n-- \nDuy\n"},{"id":"293215","messageId":"20160805181957.GA24535@dcvr","threadId":"42812","inReplyTo":"20160805093544.scvl4yshkfg2l26p@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-05T18:19:57Z","receivedAt":"2016-08-05T18:21:22Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:\n> > I do find it visually a little harder to navigate through threads,\n> > because there's not much styling there, and the messages seem to run\n> > into one another. I don't know if a border around the divs or something\n> > would help. I'm really terrible at that kind of visual design.\n> \n> I took a peek at doing something simple like:\n> \n>   pre {\n>     border-style: solid;\n>     border-width: 1px;\n>     background: #dddddd;\n>   }\n> \n> but it looks like there's no HTML structure at all to the current\n> output. It's just one big <pre> tag with various levels of indentation\n> to represent the messages.\n\nI added an <hr> between each message so the /T/ view ought to be more\nreadable:\n\nhttps://public-inbox.org/meta/20160805181459.24420-1-e@80x24.org/\n"},{"id":"293226","messageId":"20160805202046.pd42xl76c2sbf272@sigill.intra.peff.net","threadId":"42812","inReplyTo":"CACsJy8DkNUD_dKwnx9nZsgvSxgdA8MH=2+rEWzMFdkigmhpJ5g@mail.gmail.com","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-05T20:20:47Z","receivedAt":"2016-08-05T20:21:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 05, 2016 at 05:04:27PM +0200, Duy Nguyen wrote:\n\n> On Fri, Aug 5, 2016 at 11:28 AM, Jeff King <peff@peff.net> wrote:\n> > There was discussion a long time ago about storing a common zlib\n> > dictionary in the packfile and using it for all of the objects. I don't\n> > recall whether there were any patches, though. It does create some\n> > complications with serving clones/fetches, as they may ask for a subset\n> > of the objects (so you have to send them the whole dictionary, which may\n> > be a lot of overhead if you're only fetching a few objects).\n> \n> I'm nit picking since it's not actually \"all objects\". But pack v4\n> patches have two dictionaries (or more? i don't remember) for commits\n> and trees :)\n\nI couldn't remember if that zlib stuff was part of packv4 or not. I like\nmany of the ideas in pack v4, but I do worry a lot about the\ncompatibility issues, as packv2 is the on-the-wire format.\n\nBeing able to send bytes directly off disk with minimal processing is a\nkey thing that makes running a large git hosting site practical. One of\nthe things that makes nervous is having to do on-the-fly conversion when\nserving fetches and clones (but to be clear that is just gut\nnervousness; I haven't done any actual testing with the proto-packv4\npatches).\n\n-Peff\n"},{"id":"293227","messageId":"20160805202250.d23na5xdkmtnjgey@sigill.intra.peff.net","threadId":"42812","inReplyTo":"20160805181957.GA24535@dcvr","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-05T20:22:50Z","receivedAt":"2016-08-05T20:22:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 05, 2016 at 06:19:57PM +0000, Eric Wong wrote:\n\n> Jeff King <peff@peff.net> wrote:\n> > On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:\n> > > I do find it visually a little harder to navigate through threads,\n> > > because there's not much styling there, and the messages seem to run\n> > > into one another. I don't know if a border around the divs or something\n> > > would help. I'm really terrible at that kind of visual design.\n> > \n> > I took a peek at doing something simple like:\n> > \n> >   pre {\n> >     border-style: solid;\n> >     border-width: 1px;\n> >     background: #dddddd;\n> >   }\n> > \n> > but it looks like there's no HTML structure at all to the current\n> > output. It's just one big <pre> tag with various levels of indentation\n> > to represent the messages.\n> \n> I added an <hr> between each message so the /T/ view ought to be more\n> readable:\n> \n> https://public-inbox.org/meta/20160805181459.24420-1-e@80x24.org/\n\nThanks. That's definitely an improvement. I still think the styling\ncould go further, but I don't expect you to do it. It's something I may\nlook into, but I should probably try to clear out my backlog of\n\"to-review\" patches before I go off spending time on it. :)\n\n-Peff\n"},{"id":"293311","messageId":"20160806234127.GA23580@starla","threadId":"42812","inReplyTo":"20160805202250.d23na5xdkmtnjgey@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] more archives of this list","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-06T23:41:27Z","receivedAt":"2016-08-06T23:41:32Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n> Thanks. That's definitely an improvement. I still think the styling\n> could go further, but I don't expect you to do it. It's something I may\n> look into, but I should probably try to clear out my backlog of\n> \"to-review\" patches before I go off spending time on it. :)\n\nHeh, and I've nearly been sidetracked into hacking w3m to\niframes, persistent connections, color-mapping, etc, too :x\nRight now, I'm just happy w3m supports piping buffers to\narbitrary programs (so one could run \"git am\" on the /raw\nendpoint).\n\nIt'll be tough to beat a good local mail setup some of us have\nwith mutt/gnus.  Being able to mark messages as read/unread\nwould either be intrusive (cookies/tracking users) or\ncause accessibility problems (frames), I think...\n\n...which is why the mbox.gz endpoints exist in public-inbox :>\n\nSo I think I'll try to do POP3 support, first...\n"}]}