Why We Use ed25519 Keys with Nostr
Technical Documentation of our decisions. Why not JUST nostr keys?
Note:
You do not need to read this to use HydraVeil.
This is the longer-form in-depth documentation for Nostr users who are confused as to why we use ed25519 with Nostr Schnorr keys, and not just Nostr direct. There is an short easy version found here.
Overview
Our system is we have a directory downloaded to the user’s client on sync of all the Nostr keys and their matching ed25519 keys. Along with this is the Nostr note where the operator declared their ed25519 “HydraVeil” key.
Then the Wireguard configuration files have the ed25519 signature, where they sign that Wireguard endpoint’s public key (which is also ed25519 in the same format).
And the client verifies this ed25519 signature prior to connecting every single time, unless it’s turned off in the options.
Big Question
This raises the question of why have the ed25519 key at all? Why not just have Nostr users post their server’s Wireguard public keys?
These are the reasons our team made this decision,
Wireguard Endpoints Change
First off, there may be multiple Wireguard endpoints for a single IP address or larger influencer. And in fact, the larger the influencer, the more likely they are to need more computers with more traffic. Second, even if there’s only one, then it may change all the time to switch computers. Remember, sometimes computers go down, or the need to switch may arise. Also after periods of time, the keys should be rotated for security. This constant change would cause spam issues. And in fact, the more famous the Nostr influencer, the more they’d have to spam to deal with new PCs for the Wireguard traffic.
Spam
If the Nostr influencer has to broadcast to the whole network every single time the server’s Wireguard key changes, we have the recipe for spam. But it’s even worse than that, because in order to get the key, it would require the Nostr user to post ONLY the Wireguard key. This is because any extra characters would create issues with parsing it, and it would be difficult to discern all the time random letters of a public key from the Nostr user’s posts. Further, it is slower to parse giant JSONs, which for Nostr have to be signed all at once. Parsing is the process of going through the text, to discern the relevant information to verify. The more text it has to parse, the slower this verification would be.
Performance
The webservice gives the user the Wireguard configuration file, which is the most logical place to put the operator’s signature, since the client is checking this to do the connection. Remember, Nostr events are an entire huge JSON, as opposed to ed25519 which has single line public keys without sacraficing security. This is why Wireguard originally uses them to establish tunnels, so it can read it off a config file.
Because our client has to parse through the Wireguard config text, it would be much slower to parse through huge JSONs with Nostr events, especially when it’s trying to read the actual Wireguard connection information after the signature is verified.
Separation of Concerns
Many Nostr users may not trust putting their private nsec in our new software. This creates issues as there are not many tools for offline Nostr signatures, as there are for PGP. So this would create pressure to have Nostr users post live to the network all signatures, which again gets into the spam issue.
Control
Also there is a control issue. If the Nostr user wants to have their key on an iPhone, stock Google, Windows, or Apple, then can we realistically dictate how they have to live their life? They may want to use a variety of clients and devices with the same nsec.
But if we have a separate key in the same format as Wireguard, then we can control what we expect operators to do. (Keep it on Linux).
Nostr Adoption
It may seem confusing at first, why would having a non-Nostr key improve Nostr adoption? Simple, because many non-Linux influencers may get involved with HydraVeil, and delegate the task of setting up the node to a Linux professional they hire.
By separating the core HydraVeil functions from the Nostr key, it would improve Nostr adoption to have a technical professional do their node setup. And then after they can enjoy the social network on a non-Linux daily-driver device.
Why ed25519?
We picked the same key format as Wireguard’s initial handshake to establish a tunnel, because it’s widely accepted and used for this use-case of fast performance from reading from config files prior to setting up a tunnel. Ed25519 keys are known for their speed, without sacrificing on security.
Privacy
Getting notes directly from Nostr relays has privacy concerns, especially if it’s done prior to a VPN connection. Often Cloudflare and Hetzner are the hosts, and it broadcasts to the public network your IP address. Instead, we have our webservice give the user the attestation event, so they can verify on their own with live relays.
Chain of Trust
By declaring a ed25519 key on Nostr, it still establishes the Nostr identity as linked to the Wireguard node, while not having any of the negatives mentioned in this article. Anyone can verify with the Nostr event, and our webservice can serve these events up with any relays in the event.
If you really want to learn and take your privacy to the next level, Learn about HydraVeil, Access our VPN, and subscribe to our new content via: Arweave Video RSS, Podcast RSS, Session list, Nostr, Bastyon, Article RSS, or join the Signal Group
Related Posts
Why a Nostr VPN?!
How should node operators identify themselves?
[SP]
Dec 17, 2025
How a Nostr VPN Works
Node operators verify their identity?!
[SP]
Dec 17, 2025
Why Run a HydraVeil Node
Get Paid, Help Nostr, Help Privacy, & Be Part of Something
[SP]
Dec 17, 2025
Node Operator Checklist / Overview
Start Here if You're Interested in Hosting a HydraVeil Node
[SP]
Dec 17, 2025