Eric Abrahamsen <e...@ericabrahamsen.net> wrote: > Kyle Meyer <k...@kyleam.com> writes: > > > [ +cc Eric Wong, mostly to say thanks for all the work he puts into > > public-inbox, which is the software behind these archives, but also so > > that he can correct me if I misrepresent any capabilities of or plans > > for public-inbox ] > > Thanks for this response, Kyle (and thanks for public-inbox, Eric)!
you're welcome, both :> > You wouldn't really use one backend (nnweb) to provide search support > for another (nntp). nnir can assign different search engines to > different backends -- what a "search engine" boils down to is a function > that accepts group search criteria, and returns groups and article > numbers (and optional relevance scoring) for matching messages. So if > public-inbox had some sort of an API that accepted a query and returned > the above information in some sort of easily-digestible format, it > wouldn't be hard to write a engine for it. Articles referenced in the > search results would then be retrieved via NNTP, so the article numbers > would need to correspond. Fwiw, I've been trying to avoid exposing NNTP article numbers in the HTTP endpoint in favor of Message-IDs because serial numbers aren't decentralization-friendly. Of course, sometimes Message-IDs get reused, so public-inbox will return all messages which match a particular Message-ID in those rare cases. Btw, POST with the "&x=m" query parameter already allows search to return a gzipped mboxrd. And also what I just wrote about about JMAP/GraphQL in the other message. A read-only IMAP server is also coming with search support, and IMAP UIDs will be equivalent to NNTP article numbers.
