-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve public key exchange while peering #57
Comments
what about an opt in CA that verifies each node's certificate? |
What I've seen being done (including by myself) is putting the cert in /static/. Maybe a standardized place there could be a thing. |
I like the idea of including the feeds.ini section (if only to confirm the port #), sorta an all-in-one bundle. 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? |
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: 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 |
|
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?
The text was updated successfully, but these errors were encountered: