-
Notifications
You must be signed in to change notification settings - Fork 14
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
encryption: false option? #21
Comments
if trivial, sure, go for it. Note that hypercore relies on the noise-handshake setup so the only thing you can safely disable is the transport encryption. Also the option should be something like |
You would need to impl noops of Push and Pull here so it doesnt impact any of the other code at runtime |
I have the second use case mentioned above:
It's in a browser environment trying to replicate hypercores and is erroring on the noise handshake. @gmaclennan did you work on this / advice to give? @mafintosh is there another solution for replicating hypercores without noise? |
No, I haven't yet. So far I've just been piping the whole encrypted noise stream over websocket, but it's still at the prototype stage so I haven't looked at the performance gains from removing the encryption (because the websocket is over TLS). |
Created a PR to implement this: #25 |
Thanks @gmaclennan that was quick! I've tried it out your PR in node and it works great. Still not working for me in webview though - it's the noise handshake that's failing as noted by others in this issue #13 |
Found an issue tracking browser compatibility. There's just one task remaining of 22 tasks! hypercore-protocol/hypercore-next#53 sodium-friends/sodium-javascript#65 @chm-diederichs is there much involved to get this across the line? 🙏 |
Hey, possibly not too much work. I will take a look when I can, but I'm a little swamped at the moment I have the methods implemented on this branch here though, if you want to test in the meantime. Just be aware it's an experimental branch. |
Sorry for the noise, just checking the view of the maintainers on this issue and the implementation in #25. I understand there is the separate question of browser compatibility, but this feature and solution does not need to depend on that. We can always just patch / fork, but it's easier to maintain into the future for us if this is integrated here. See the PR, there is significant overhead saved by turning off encryption. |
Hi @gmaclennan . For now rely on the branch. We are pushing a lot of changes through the stack atm with rocks, so dont wanna rock the boat too much and land this while that happens. Feature wise, ok to have the flag and it will land eventually |
Any interest in adding a
{ encrypted: false }
option? I could work on a PR.Use cases:
My specific use-case is hypercore replication over a secure websocket (e.g. TLS). The secret-stream handshake to confirm public keys is still useful, but the encryption/decryption adds CPU overhead and is not needed in this use-case.
I understand that this is an edge-case, so I can implement as a project-specific patch if you don't want to add to the API here.
The text was updated successfully, but these errors were encountered: