| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:50:30 |
| Calls: | 583 |
| Files: | 1,139 |
| D/L today: |
179 files (27,921K bytes) |
| Messages: | 111,802 |
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?
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.
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.
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 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.
On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
=20
The main part of writing it into the code is making sure=20
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.
=20
I appreciate that it's not standard (keeping both copies of the
article), but the software does not yet support Supersedes. =20
Why don't rely on it?
IIRC rslight needs an upstream NNTP server to reasonably work for
usenet.
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.
On Sat, 2 Nov 2024 18:43:52 +0000, Byrl Raze Buckbriar wrote:
=20
On Sat, 2 Nov 2024 15:58:50 +0100
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
=20
On 02.11.2024 um 13:55 Uhr Retro Guy wrote:
=20
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. =20
Why don't rely on it?
IIRC rslight needs an upstream NNTP server to reasonably work for
usenet. =20
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. =20=20
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.
=20
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 :)
=20
With that minor point said I have a question.
If Rocksolid is to do 'Supersedes' should Rocksolid also do 'Replaces'=20
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. =20
I am not familiar with these headers. Any links for more info?
=20
--=20
Retro Guy
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?
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.
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.
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 :)