nntpchan
nntpchan copied to clipboard
majestrate
Improve public key exchange while peering
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?
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)
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?
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.
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.
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
ctl is for moderation messages so older nodes will process them as mod events. That is my reasoning for new newsgroup.