🚀 go-pugleaf

--Sig_/kdEl=jz4yU.rowHhs+FhWrE
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 2 Nov 2024 15:58:50 +0100
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:

> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
> 
> > The main part of writing it into the code is making sure
> > authentication is correct. I can have it just depend on the upstream
> > server, but I try to avoid relying on other software to do stuff.
> > 
> > I appreciate that it's not standard (keeping both copies of the
> > article), but the software does not yet support Supersedes.  
> 
> Why don't rely on it?
> IIRC rslight needs an upstream NNTP server to reasonably work for
> usenet.

I won't pretend to speak for Retro Guy but I will say what seems obvious to me.

Rocksolid Light is not for Usenet. Rocksolid Light is for NNTP.

Usenet just happens to use NNTP. Rocksolid Light can peer with any other Rocksolid Light server without a Usenet peering.

With that minor point said I have a question.

If Rocksolid is to do 'Supersedes' should Rocksolid also do 'Replaces' or 'Replaced-by' headers? And do other NNTP servers honor these? And do they work like a cancel with a manifest? It's a bit fuzzy to me.

Just a question, not really a request. Any deeper explanation would be appreciated.

-- 
    Byrl Raze Buckbriar  .  OCTADE  .   < https://octade.net >
    Hacker Hotline  .  voice & SMS  .   (781) OCT-AGON
    KeyOxide  .  < https://keyoxide.org/keyoxide0@octade.net >

--Sig_/kdEl=jz4yU.rowHhs+FhWrE
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRneuMjkp+P7n1uq4moad1ZYOZmFwUCZyZy6AAKCRCoad1ZYOZm
F775AQCirQ7cUOaab1d8VxJFgmdAUmDh/+1le651oG7ONnraQgEA+YCsY+8dGy2K
bE2tO7IMJO56E7kwJ2aVz4pOJsjmOQI=ATiU
-----END PGP SIGNATURE-----

--Sig_/kdEl=jz4yU.rowHhs+FhWrE--

On Sat, 2 Nov 2024 11:47:25 +0000, Michael_Uplawski wrote:

> Good afternoon
>
> Is it standard-behavior in Rocksolid light that supersedes are ignored,
> i.e. additional versions of an original post appear in the thread?
>
> Otherwise, is there a way to impose that only the most recent supersede
> be available?

It's something I'm considering adding to RSLight, but right now it has
no idea of Supersedes, and just sees the new message as a new message.

The main part of writing it into the code is making sure authentication
is correct. I can have it just depend on the upstream server, but I try
to avoid relying on other software to do stuff.

I appreciate that it's not standard (keeping both copies of the
article), but the software does not yet support Supersedes.

--
Retro Guy

On 02.11.2024 um 13:55 Uhr Retro Guy wrote:

> The main part of writing it into the code is making sure
> authentication is correct. I can have it just depend on the upstream
> server, but I try to avoid relying on other software to do stuff.
>
> I appreciate that it's not standard (keeping both copies of the
> article), but the software does not yet support Supersedes.

Why don't rely on it?
IIRC rslight needs an upstream NNTP server to reasonably work for
usenet.

--
kind regards
Marco

Send spam to 1730552102muell@cartoonies.org

On Sat, 2 Nov 2024 14:58:50 +0000, Marco Moock wrote:

> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
>
>> The main part of writing it into the code is making sure
>> authentication is correct. I can have it just depend on the upstream
>> server, but I try to avoid relying on other software to do stuff.
>>
>> I appreciate that it's not standard (keeping both copies of the
>> article), but the software does not yet support Supersedes.
>
> Why don't rely on it?
> IIRC rslight needs an upstream NNTP server to reasonably work for
> usenet.

Yes, but rslight can peer through one or many rslight or other nntp
servers before hitting a Usenet facing inn server.

If any of the peer servers do not delete the superceded article, it
won't work. What I'm trying to avoid is making rslight dependent on a
peered nntp server. Right now it is not (it can run standalone). For
supercedes to be properly handled, rslight should support it internally.

I have a different view of Usenet moderated groups, as rslight does not
support moderated groups, and there is no plan atm to ever do so.

Maybe I'll make it optional for now.

--
Retro Guy

On Sat, 2 Nov 2024 16:07:25 +0000, Retro Guy wrote:

> On Sat, 2 Nov 2024 14:58:50 +0000, Marco Moock wrote:
>
>> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
>>
>>> The main part of writing it into the code is making sure
>>> authentication is correct. I can have it just depend on the upstream
>>> server, but I try to avoid relying on other software to do stuff.
>>>
>>> I appreciate that it's not standard (keeping both copies of the
>>> article), but the software does not yet support Supersedes.
>>
>> Why don't rely on it?
>> IIRC rslight needs an upstream NNTP server to reasonably work for
>> usenet.
>
> Yes, but rslight can peer through one or many rslight or other nntp
> servers before hitting a Usenet facing inn server.
>
> If any of the peer servers do not delete the superceded article, it
> won't work. What I'm trying to avoid is making rslight dependent on a
> peered nntp server. Right now it is not (it can run standalone). For
> supercedes to be properly handled, rslight should support it internally.
>
> I have a different view of Usenet moderated groups, as rslight does not
> support moderated groups, and there is no plan atm to ever do so.
>
> Maybe I'll make it optional for now.

I'm testing this now. I'll make it optional (overrides.inc.php).

Basically, simply checking if upstream remote has removed the superseded
article and, if so, remove it. Either way, the new article gets
inserted.

Other than that, without a cancel-lock, I'm not sure supersedes is very
secure, but I also never gave it a lot of thought.

--
Retro Guy

On 02.11.2024 um 16:07 Uhr Retro Guy wrote:

> I have a different view of Usenet moderated groups, as rslight does
> not support moderated groups, and there is no plan atm to ever do so.

Why?
It only means that the post isn't being added to the local spool, but
posted to the upstream NNTP server.

--
kind regards
Marco

Send spam to 1730560045muell@cartoonies.org

On Sat, 2 Nov 2024 18:43:52 +0000, Byrl Raze Buckbriar wrote:

> On Sat, 2 Nov 2024 15:58:50 +0100
> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>
>> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
>>
>>> The main part of writing it into the code is making sure
>>> authentication is correct. I can have it just depend on the upstream
>>> server, but I try to avoid relying on other software to do stuff.
>>>
>>> I appreciate that it's not standard (keeping both copies of the
>>> article), but the software does not yet support Supersedes.
>>
>> Why don't rely on it?
>> IIRC rslight needs an upstream NNTP server to reasonably work for
>> usenet.
>
> I won't pretend to speak for Retro Guy but I will say what seems obvious
> to me.
>
> Rocksolid Light is not for Usenet. Rocksolid Light is for NNTP.
>
> Usenet just happens to use NNTP. Rocksolid Light can peer with any other
> Rocksolid Light server without a Usenet peering.

This is my view also. RSLight uses nntp as a backend, but does not
necessarily support everything Usenet. For example, moderated groups are
handled by the upstream inn server, rslight just doesn't add to the
spool if there is a moderated 'm' flag. This should not conflict with
any rslight use.

I am not opposed to 'Usenet' at all, of course, just that I don't want
rslight to become dependent on it. It should always be able to be run
standalone, and not lose features (nntp features) when doing so. That's
my plan anyway. Whether I succeed or not, we'll see :)

> With that minor point said I have a question.
>
> If Rocksolid is to do 'Supersedes' should Rocksolid also do 'Replaces'
> or 'Replaced-by' headers? And do other NNTP servers honor these? And do
> they work like a cancel with a manifest? It's a bit fuzzy to me.

I am not familiar with these headers. Any links for more info?

--
Retro Guy

--Sig_/F5fjT+ALMx2aEBbg5fRCwj/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 2 Nov 2024 19:43:34 +0000
Retro Guy <retroguy@novabbs.com> wrote:

> On Sat, 2 Nov 2024 18:43:52 +0000, Byrl Raze Buckbriar wrote:
> 
> > On Sat, 2 Nov 2024 15:58:50 +0100
> > Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> >  
> >> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
> >>  
> >>> The main part of writing it into the code is making sure
> >>> authentication is correct. I can have it just depend on the upstream
> >>> server, but I try to avoid relying on other software to do stuff.
> >>>
> >>> I appreciate that it's not standard (keeping both copies of the
> >>> article), but the software does not yet support Supersedes.  
> >>
> >> Why don't rely on it?
> >> IIRC rslight needs an upstream NNTP server to reasonably work for
> >> usenet.  
> >
> > I won't pretend to speak for Retro Guy but I will say what seems obvious
> > to me.
> >
> > Rocksolid Light is not for Usenet. Rocksolid Light is for NNTP.
> >
> > Usenet just happens to use NNTP. Rocksolid Light can peer with any other
> > Rocksolid Light server without a Usenet peering.  
> 
> This is my view also. RSLight uses nntp as a backend, but does not
> necessarily support everything Usenet. For example, moderated groups are
> handled by the upstream inn server, rslight just doesn't add to the
> spool if there is a moderated 'm' flag. This should not conflict with
> any rslight use.
> 
> I am not opposed to 'Usenet' at all, of course, just that I don't want
> rslight to become dependent on it. It should always be able to be run
> standalone, and not lose features (nntp features) when doing so. That's
> my plan anyway. Whether I succeed or not, we'll see :)
> 
> > With that minor point said I have a question.
> >
> > If Rocksolid is to do 'Supersedes' should Rocksolid also do 'Replaces'
> > or 'Replaced-by' headers? And do other NNTP servers honor these? And do
> > they work like a cancel with a manifest? It's a bit fuzzy to me.  
> 
> I am not familiar with these headers. Any links for more info?
> 
> -- 
> Retro Guy

I don't know of any detailed reference for this. I couldn't find much but here is what I have:

RFC 5536 https://datatracker.ietf.org/doc/html/rfc5536#section-3.2.12

Supersedes & Replaces -- Updating and correcting articles
https://www.templetons.com/usenet-format/supersedes.html

Bare Supersedes and Replaces might not be widely honored by sysops but combined with Cancel-Lock and Key-Lock they may be:

https://news.individual.net/faq.php#1.12

AI told me this:
https://search.brave.com/search?q=nntp+supersedes+header&source=desktop&summary=1&summary_og=4e86b4a61a7d556961ab96

I think the point of the Replaces and Supersedes headers is that they allow the original poster of an article through some authenticated method to replace the article based upon message-id, with a new article and a linked message-id. I didn't find anything about how the cryptographic lock works on this, whether a pre-hash or signature or something else, whether it is the same as Cancel-Lock or modified. I have no idea how INN handles them. Is there an expert on this lurking?

-- 
    Byrl Raze Buckbriar  .  OCTADE  .   < https://octade.net >
    Hacker Hotline  .  voice & SMS  .   (781) OCT-AGON
    KeyOxide  .  < https://keyoxide.org/keyoxide0@octade.net >

--Sig_/F5fjT+ALMx2aEBbg5fRCwj/
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRneuMjkp+P7n1uq4moad1ZYOZmFwUCZyd3/wAKCRCoad1ZYOZm
F9wtAP4xtTvugS+IGN40ONGuhB4lqw69tiLTxCYiEVTWFhmsdAEAiRSCYyR+M87j
f0J1xzI/q1YCkeqy4paeWc1QNXHWjAo=Iv4i
-----END PGP SIGNATURE-----

--Sig_/F5fjT+ALMx2aEBbg5fRCwj/--

On Sun, 3 Nov 2024 13:17:51 +0000, Byrl Raze Buckbriar wrote:

> On Sat, 2 Nov 2024 19:43:34 +0000
> Retro Guy <retroguy@novabbs.com> wrote:
>
>> On Sat, 2 Nov 2024 18:43:52 +0000, Byrl Raze Buckbriar wrote:
>>
>>> On Sat, 2 Nov 2024 15:58:50 +0100
>>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>
>>>> On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
>>>>
>>>>> The main part of writing it into the code is making sure
>>>>> authentication is correct. I can have it just depend on the upstream
>>>>> server, but I try to avoid relying on other software to do stuff.
>>>>>
>>>>> I appreciate that it's not standard (keeping both copies of the
>>>>> article), but the software does not yet support Supersedes.
>>>>
>>>> Why don't rely on it?
>>>> IIRC rslight needs an upstream NNTP server to reasonably work for
>>>> usenet.
>>>
>>> I won't pretend to speak for Retro Guy but I will say what seems obvious
>>> to me.
>>>
>>> Rocksolid Light is not for Usenet. Rocksolid Light is for NNTP.
>>>
>>> Usenet just happens to use NNTP. Rocksolid Light can peer with any other
>>> Rocksolid Light server without a Usenet peering.
>>
>> This is my view also. RSLight uses nntp as a backend, but does not
>> necessarily support everything Usenet. For example, moderated groups are
>> handled by the upstream inn server, rslight just doesn't add to the
>> spool if there is a moderated 'm' flag. This should not conflict with
>> any rslight use.
>>
>> I am not opposed to 'Usenet' at all, of course, just that I don't want
>> rslight to become dependent on it. It should always be able to be run
>> standalone, and not lose features (nntp features) when doing so. That's
>> my plan anyway. Whether I succeed or not, we'll see :)
>>
>>> With that minor point said I have a question.
>>>
>>> If Rocksolid is to do 'Supersedes' should Rocksolid also do 'Replaces'
>>> or 'Replaced-by' headers? And do other NNTP servers honor these? And do
>>> they work like a cancel with a manifest? It's a bit fuzzy to me.
>>
>> I am not familiar with these headers. Any links for more info?
>>
>> --
>> Retro Guy
>
> I don't know of any detailed reference for this. I couldn't find much
> but here is what I have:
>
> RFC 5536 https://datatracker.ietf.org/doc/html/rfc5536#section-3.2.12
>
> Supersedes & Replaces -- Updating and correcting articles
> https://www.templetons.com/usenet-format/supersedes.html
>
> Bare Supersedes and Replaces might not be widely honored by sysops but
> combined with Cancel-Lock and Key-Lock they may be:
>
> https://news.individual.net/faq.php#1.12

We found the same things :)

> AI told me this:
> https://search.brave.com/search?q=nntp+supersedes+header&sourceÞsktop&summary=1&summary_ogN86b4a61a7d556961ab96
>
> I think the point of the Replaces and Supersedes headers is that they
> allow the original poster of an article through some authenticated
> method to replace the article based upon message-id, with a new article
> and a linked message-id. I didn't find anything about how the
> cryptographic lock works on this, whether a pre-hash or signature or
> something else, whether it is the same as Cancel-Lock or modified. I
> have no idea how INN handles them. Is there an expert on this lurking?

This is where I have difficulty with it. If I implement, I want it to be
secure, and I want to understand how it is meant to work. Reading the
individual.net link, which I saw yesterday, I'm not sure if it's secure
by design. Seems only if linked with cancel-lock (which is ok).

I don't really have a strong interest in implementing this, I'll just
leave it to the upstream nntp server (default false), but it would be
nice to understand it better.

I've honestly never been much of a fan of deleting or editing posted
content. Just write an updated message if need be. I've been
running/moderating forums for a very long time, and I don't have much
patience with users who want their stuff deleted. You shouldn't have
posted it. Sometimes I post something then think, "Oh shit. That doesn't
sound the way I want it to." Then I just send another article to
clarify. It's not that difficult.

--
Retro Guy

On Sun, 3 Nov 2024 14:41:36 +0000, Retro Guy wrote:
I don't have much
> patience with users who want their stuff deleted. You shouldn't have
> posted it. Sometimes I post something then think, "Oh shit. That doesn't
> sound the way I want it to." Then I just send another article to
> clarify. It's not that difficult.

I do not claim that anything were difficult. I do not even think to have
claimed just anything.

It is just that supersedes exists and reading posts in Rocksolid is
possible. Put the two together and you have the motive for my first
post.

Things can get ugly because I fail, because I do not care or because
things are working in a way that is not documented nor obvious.

But I know my alternatives. Thanks for the discussion.
Ω

--

On Tue, 5 Nov 2024 6:36:41 +0000, Michael_Uplawski wrote:

> On Sun, 3 Nov 2024 14:41:36 +0000, Retro Guy wrote:
> I don't have much
>> patience with users who want their stuff deleted. You shouldn't have
>> posted it. Sometimes I post something then think, "Oh shit. That doesn't
>> sound the way I want it to." Then I just send another article to
>> clarify. It's not that difficult.
>
> I do not claim that anything were difficult. I do not even think to have
> claimed just anything.

I wasn't referring to you, just to people who ask their stuff deleted.
I've had users ask that "all" their posts be deleted. My comment was not
meant to be directed at you at all. You simply asked a reasonable
question.

> It is just that supersedes exists and reading posts in Rocksolid is
> possible. Put the two together and you have the motive for my first
> post.

I agree, the question was/is reasonable, and has given me the incentive
to try to implement (partially). I appreciate the idea.

> Things can get ugly because I fail, because I do not care or because
> things are working in a way that is not documented nor obvious.
>
> But I know my alternatives. Thanks for the discussion.

I appreciate the input and your comments.

--
Retro Guy

On Tue, 5 Nov 2024 9:20:04 +0000, Retro Guy wrote:

> On Tue, 5 Nov 2024 6:36:41 +0000, Michael_Uplawski wrote:
>
>> On Sun, 3 Nov 2024 14:41:36 +0000, Retro Guy wrote:
>> I don't have much
>>> patience with users who want their stuff deleted. You shouldn't have
>>> posted it. Sometimes I post something then think, "Oh shit. That doesn't
>>> sound the way I want it to." Then I just send another article to
>>> clarify. It's not that difficult.
>>
>> I do not claim that anything were difficult. I do not even think to have
>> claimed just anything.
>
> I wasn't referring to you, just to people who ask their stuff deleted.
> I've had users ask that "all" their posts be deleted. My comment was not
> meant to be directed at you at all. You simply asked a reasonable
> question.
>
>> It is just that supersedes exists and reading posts in Rocksolid is
>> possible. Put the two together and you have the motive for my first
>> post.
>
> I agree, the question was/is reasonable, and has given me the incentive
> to try to implement (partially). I appreciate the idea.
>
>> Things can get ugly because I fail, because I do not care or because
>> things are working in a way that is not documented nor obvious.
>>
>> But I know my alternatives. Thanks for the discussion.
>
> I appreciate the input and your comments.

Note: This feature is now being tested live on my sites. Internal
testing was fine, but I'd like to see it actually work on some live
articles once a Supersedes shows up. We'll see :)

--
Retro Guy

On Tue, 5 Nov 2024 10:46:48 +0000, Retro Guy wrote:

> On Tue, 5 Nov 2024 9:20:04 +0000, Retro Guy wrote:
>
>> On Tue, 5 Nov 2024 6:36:41 +0000, Michael_Uplawski wrote:
>>
>>> On Sun, 3 Nov 2024 14:41:36 +0000, Retro Guy wrote:
>>> I don't have much
>>>> patience with users who want their stuff deleted. You shouldn't have
>>>> posted it. Sometimes I post something then think, "Oh shit. That doesn't
>>>> sound the way I want it to." Then I just send another article to
>>>> clarify. It's not that difficult.
>>>
>>> I do not claim that anything were difficult. I do not even think to have
>>> claimed just anything.
>>
>> I wasn't referring to you, just to people who ask their stuff deleted.
>> I've had users ask that "all" their posts be deleted. My comment was not
>> meant to be directed at you at all. You simply asked a reasonable
>> question.
>>
>>> It is just that supersedes exists and reading posts in Rocksolid is
>>> possible. Put the two together and you have the motive for my first
>>> post.
>>
>> I agree, the question was/is reasonable, and has given me the incentive
>> to try to implement (partially). I appreciate the idea.
>>
>>> Things can get ugly because I fail, because I do not care or because
>>> things are working in a way that is not documented nor obvious.
>>>
>>> But I know my alternatives. Thanks for the discussion.
>>
>> I appreciate the input and your comments.
>
> Note: This feature is now being tested live on my sites. Internal
> testing was fine, but I'd like to see it actually work on some live
> articles once a Supersedes shows up. We'll see :)

It looks like it works:

Nov 05 23:01:12 Found Supersedes:
<de-newusers-infos/einleitung/20241106-1@msgid.krell.zikzak.de> for:
<de-newusers-infos/einleitung/20241105-1@msgid.krell.zikzak.de>
Nov 05 23:01:13 Searching i2pn2 for
<de-newusers-infos/einleitung/20241105-1@msgid.krell.zikzak.de>
Nov 05 23:01:13 NOT Found
<de-newusers-infos/einleitung/20241105-1@msgid.krell.zikzak.de> on i2pn2
Nov 05 23:01:13 Will delete:
<de-newusers-infos/einleitung/20241105-1@msgid.krell.zikzak.de>

It simply checks to see if the article has been removed from the remote
server nd if so, removes it.

I'll have this in the next release as an overrides option. It's in devel
now)..

Thanks Michael, for bringing up this issue/option. There are plenty of
things I wouldn't think of unless someone else mentions it. While I may
not enable this on some of my sites, I'm glad to provide it as an option
to other admins.

--
Retro Guy