Improve public key exchange while peering #26

New Issue

2026-10-05T03:08:34+02:00

adam commented

2026-10-05 03:08:34 +02:00

How can we reduce the friction from peering? Currently we need to exchange certificates (the self-signed ones created during config) out-of-band but we could instead have a well-known location for hosting this cert and having it pulled down automatically as long as the site has protected the resource with HTTPS (no good reason not to imo with Let's Encrypt out there). Ideas?

How can we reduce the friction from peering? Currently we need to exchange certificates (the self-signed ones created during config) out-of-band but we could instead have a well-known location for hosting this cert and having it pulled down automatically as long as the site has protected the resource with HTTPS (no good reason not to imo with Let's Encrypt out there). Ideas?

adam commented

2026-10-05 03:08:35 +02:00

what about an opt in CA that verifies each node's certificate?

what about an opt in CA that verifies each node's certificate?

adam commented

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

What I've seen being done (including by myself) is putting the cert in /static/. Maybe a standardized place there could be a thing.
Or maybe and owner of a node can send a signed post that includes the cert and some peering info (the feeds.ini section). The interested users or the daemon than picks that post up and adds it as needed. In daemons case there may be some sort of mod page where those posts are formed into a peering menu where the peerings are populated. From there they can be set up further and enabled o disabled.
(i have no idea how to deal with certs normally lel)

What I've seen being done (including by myself) is putting the cert in /static/. Maybe a standardized place there could be a thing. Or maybe and owner of a node can send a signed post that includes the cert and some peering info (the feeds.ini section). The interested users or the daemon than picks that post up and adds it as needed. In daemons case there may be some sort of mod page where those posts are formed into a peering menu where the peerings are populated. From there they can be set up further and enabled o disabled. (i have no idea how to deal with certs normally lel)

adam commented

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

thread on nntpchan also

[thread on nntpchan also](https://i2p.rocks/ib/thread-1524f496858f9693ca8204fcb0ad3317ed42efea.html)

adam commented

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

I like the idea of including the feeds.ini section (if only to confirm the port #), sorta an all-in-one bundle.
A CA might work but then we have to maintain it, could we not just make use of existing free certs? I was thinking of maybe integrating a lightweight let's encrypt client to make deployment even easier BUT they won't do .onion of course.

Maybe we could just pin the public key inside the feeds.ini? Small script to generate a copypaste-able block for people to copy into their feeds.ini and bam peering done?

I like the idea of including the feeds.ini section (if only to confirm the port #), sorta an all-in-one bundle. A CA might work but then we have to maintain it, could we not just make use of existing free certs? I was thinking of maybe integrating a lightweight let's encrypt client to make deployment even easier BUT they won't do .onion of course. Maybe we could just pin the public key inside the feeds.ini? Small script to generate a copypaste-able block for people to copy into their feeds.ini and bam peering done?

adam commented

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

Maybe we could just pin the public key inside the feeds.ini?

that's pretty much what we do anyways

the idea of using a CA is that it'd be a CA just for overchan nodes that are "authorized" but that is too centralized so nevermind, that's a bad idea.

> Maybe we could just pin the public key inside the feeds.ini? that's pretty much what we do anyways the idea of using a CA is that it'd be a CA just for overchan nodes that are "authorized" but that is too centralized so nevermind, that's a bad idea.

adam commented

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

thinking about this more, got an idea.

new newsgroup: ctl.ping

server signed messages only for server discovery.

every day server posts a list of all connected peers with their public key and address info.

thinking about this more, got an idea. new newsgroup: `ctl.ping` server signed messages only for server discovery. every day server posts a list of all connected peers with their public key and address info.

adam commented

2026-10-05 03:08:39 +02:00

existing nodes are only subscribed to ctl not ctl.* so it wouldn't be backwards compatible, especially with people who have set up their nodes and just left them running without checking on/performing maintenance on them

existing nodes are only subscribed to ctl not ctl.* so it wouldn't be backwards compatible, especially with people who have set up their nodes and just left them running without checking on/performing maintenance on them

adam commented

2026-10-05 03:08:40 +02:00

ctl is for moderation messages so older nodes will process them as mod events. That is my reasoning for new newsgroup.

`ctl` is for moderation messages so older nodes will process them as mod events. That is my reasoning for new newsgroup.

adam changed title from ~~Improve public key exchange while peering~~ to Improve public key exchange while peering

2026-10-27 13:30:59 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/nntpchan#26