Hello! diboard project released! Here is my suggestions. #41

New Issue

2026-10-05T03:09:36+02:00

adam commented

2026-10-05 03:09:36 +02:00

Hello! I am released my Java nntp imageboard project:
diboard

Here is what I found:

Because of different number of pages and threads per group at different peers some threads removed. When you receive article and REFERENCES header point to missing thread. You must request it to save integrity. I call it "partial threads" in documentation.
I made short links inside message. Do you remember short links and global links exchange? I wrote everything in documentation but in Russian. I need time to translate.
You have two names for web and nntp in your nntpchan. Make it one.

Take a look at diagrams I made dibd

Thank you very much for your project. I took a lot from your project.
I am in touch.

Hello! I am released my Java nntp imageboard project: [diboard](https://github.com/Anoncheg1/diboard) Here is what I found: 1. Because of different number of pages and threads per group at different peers some threads removed. When you receive article and REFERENCES header point to missing thread. You must request it to save integrity. I call it "partial threads" in documentation. 2. I made short links inside message. Do you remember short links and global links exchange? I wrote everything in documentation but in Russian. I need time to translate. 3. You have two names for web and nntp in your nntpchan. Make it one. Take a look at diagrams I made [dibd](https://github.com/Anoncheg1/dibd) Thank you very much for your project. I took a lot from your project. I am in touch.

adam closed this issue

2026-10-05 03:09:36 +02:00

adam commented

2026-10-05 03:09:37 +02:00

Very nice work, love to see this happening.

Some feedback on your 3 points:

we already try requesting a root post we don't have but it doesn't always work as it may be that all our neighbors don't have it.
translation would help, please do when you can
this is a historical design choice, it used to be that the web ui and nntp daemon were 2 separate daemons hence different names, i should probably change that.

Additional feedback:

The crypto signing is the key feature that makes everything sane, the problem is we use nonstandard signatures, perhaps you could chose a standard signature algorithm and i'll add that to my implementation so they can inter operate.
for flood mitigation we currently don't have much, hence why peering is sensetive information. we have something similar to DKIM to help with that in the future but that needs a lot more work.

Very nice work, love to see this happening. Some feedback on your 3 points: 1. we already try requesting a root post we don't have but it doesn't always work as it may be that all our neighbors don't have it. 2. translation would help, please do when you can 3. this is a historical design choice, it used to be that the web ui and nntp daemon were 2 separate daemons hence different names, i should probably change that. Additional feedback: * The crypto signing is the key feature that makes everything sane, the problem is we use nonstandard signatures, perhaps you could chose a standard signature algorithm and i'll add that to my implementation so they can inter operate. * for flood mitigation we currently don't have much, hence why peering is sensetive information. we have something similar to DKIM to help with that in the future but that needs a lot more work.

adam commented

2026-10-05 03:09:37 +02:00

I added explanation of getting missing threads

Please explain me "crypto signing". Why it is the key feature? It is Tripcodes?
Are you talking about flood inside nntp? To use digital signature for articles to prevent sly peer from modifying transmitted message? It is great idea. To make it we must add new field with hash sum based on private key. It require to share all public keys from all peers. It may be done late.

Suggestions:

When you receive for CHECK response "483 TLS required" do not send back: 500 Invalid command: TLS.
I close connection after idling It is requiring for protection. If you want to keep connection open you should send something periodically. TLS did not do it by itself. Send "500" every 1 min maybe.
Command NEWGROUPS date time [GMT] not newSgroups.
If there is TLS problem in connection (I mean no certificate after or during handshake) then stop trying or slow a little. Looking like a flood.
How you limit and quote message-ID?
I suggest following:
<[\w.$)]+@[\w.-]+> - < 0-9, A-Z, a-z, dot, $ @ 0-9, A-Z, a-z, -, dot >
In XOVER 0 many replays without existing thread.
Why you violate RFC and use '\n' instead of '\r\n' in multi-line block of article?
Last sender in Path header must be equal to host name.
when you receive push do not push back and do not push to any host in path.
Are you XOVER 0 every 5 min? Do it once in a day or half of a day. Why not?

Look at ours philosophy comparision. Please, do not take to heart it is with humor. Am I correct with your philosophy? Or it is totally wrong?

I added explanation of [getting missing threads](https://github.com/Anoncheg1/diboard/blob/master/protocol.md) - Please explain me "crypto signing". Why it is the key feature? It is Tripcodes? - Are you talking about flood inside nntp? To use digital signature for articles to prevent sly peer from modifying transmitted message? It is great idea. To make it we must add new field with hash sum based on private key. It require to share all public keys from all peers. It may be done late. Suggestions: 1) When you receive for CHECK response "483 TLS required" do not send back: 500 Invalid command: TLS. 1) I close connection after idling It is requiring for protection. If you want to keep connection open you should send something periodically. TLS did not do it by itself. Send "500" every 1 min maybe. 2) Command NEWGROUPS date time [GMT] not newSgroups. 3) If there is TLS problem in connection (I mean no certificate after or during handshake) then stop trying or slow a little. Looking like a flood. 4) How you limit and quote message-ID? I suggest following: <[\\w.$)]+@[\\w.-]+> - < 0-9, A-Z, a-z, dot, $ @ 0-9, A-Z, a-z, -, dot > 5) In XOVER 0 many replays without existing thread. 6) Why you violate RFC and use '\n' instead of '\r\n' in multi-line block of article? 7) Last sender in Path header must be equal to host name. 8) when you receive push do not push back and do not push to any host in path. 9) Are you XOVER 0 every 5 min? Do it once in a day or half of a day. Why not? Look at ours [philosophy comparision](https://github.com/Anoncheg1/diboard/blob/master/peering%20philosophy.png). Please, do not take to heart it is with humor. Am I correct with your philosophy? Or it is totally wrong?

adam commented

2026-10-05 03:09:38 +02:00

Suggestion how to filter empty articles:
If Message is empty there is must be Subject and Attachment.
If Message is not empty: for thread there is must Subject or Attachment,
for replay Message is enough.

new replay:

1 message.length() != 0
2 subject.length() != 0
3 file.getSize() != 0
( 1 or (2 and 3) ) or (2 and 3)
( 1 or (2 and 3) )
-( 1 and (2 or 3) )    negative form for "== 0"

new thread:

1 message.length() == 0
2 subject.length() == 0
3 file.getSize() == 0
( 1 AND (2 OR 3) ) OR (2 AND 3)

Suggestion how to filter empty articles: If Message is empty there is must be Subject and Attachment. If Message is not empty: for thread there is must Subject or Attachment, for replay Message is enough. new replay: ``` 1 message.length() != 0 2 subject.length() != 0 3 file.getSize() != 0 ( 1 or (2 and 3) ) or (2 and 3) ( 1 or (2 and 3) ) -( 1 and (2 or 3) ) negative form for "== 0" ``` new thread: ``` 1 message.length() == 0 2 subject.length() == 0 3 file.getSize() == 0 ( 1 AND (2 OR 3) ) OR (2 AND 3) ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/nntpchan#41