Path: ...!news.nobody.at!news.mb-net.net!open-news-network.org!news.gegeweb.eu!gegeweb.org!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: news.software.nntp
Subject: Re: Adding something like IWANT to innd?
Date: Sat, 08 Mar 2025 09:34:37 +0000
Organization: terraraq NNTP server
Message-ID: <wwvh643n9w2.fsf@LkoBDZeT.terraraq.uk>
References: <20250307043708.28794700@wibble.sysadmininc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
	logging-data="158584"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:IyPjTCEGb3CKD5IrW3TzymGzA8o=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Bytes: 3996
Lines: 66

Nigel Reed <sysop@endofthelinebbs.com> writes:
> When adding a new peer, it's possible they will have groups that none
> of your other peers have. I've been trying to think how I can get the
> old articles with minimal bother to the peer admin.
>
> What about adding IWANT ?
>
> Something like IWANT [GROUP [<from> <to>]|[last xx articles]]
>
> The peer then can simply mark the server as IWANT friendly with maybe
> an optional throttle so they're not sucking up all the bandwidth.
>
>
> Good idea? bad idea? improvements? 

I think there’s two related things here:

1) Peers should be able to advertize their desired group patterns via
   NNTP, rather than operators having to communicate it out of
   band. (This much isn’t about backfill, just about the receiving peer
   advertizing what group patterns it can accept from the sender.)

   This would be easy to address with a new capability.

   Concretely the capability might have label ACCEPT-GROUPS, with the
   subsequent tokens being RFC3977 s4 wildmat patterns defining which
   groups are to be accepted.

   Senders are free to ignore this (and existing ones will) but for
   those that honor it, it would act as an additional restriction on
   what appears the sender’s peering configuration.

   The group pattern would be taken from news server configuration. It’d
   be appropriate for there to be per-server adverts and a global
   default (but this is an implementation detail as far as protocol
   design goes).

2) Backfill when a new peering is estalished (or re-established after a
   gap). While this can be addressed manually with a pull feed, there’s
   also no reason right now that a sending server can’t backfill as far
   as it likes, without any prompting from the receiver.

   That suggests another new capability, documenting the maximum age of
   article they’d like to see in backfill, if the sending server
   supports backfilling.

   Concretely the capability might be BACKFILL with a single token given
   the oldest date that would be accepted, using the date syntax from
   RFC3977 s7.1.1.

   The expected usage pattern would be:

   - for a completely new peering the receiver advertizes a backfill date
     based on its own maximum article age.
   - for a peering re-established after interruption the receiver
     advertizes a backfill date a bit before the last successfull
     communication with the receiver.
   - a sender may choose to use a backfill date either to ‘go back’ and
     feed older articles that would normally have been skipped, or
     alternatively to prune a queued feed (in the case of an
     interruption).

   This one would require a lot more implementation effort - feeders are
   not really designed with backfill in mind.

-- 
https://www.greenend.org.uk/rjk/