-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: create function for devs to customize patterns #3
Comments
@richard-ramos can we have more details please? :) |
We currently have these patterns available https://github.com/waku-org/js-noise/blob/master/src/patterns.ts with those specific protocolIDs
These are the handshake patterns defined in the RFC, but maybe we should refactor the code so it's easy for a developer to be able to create new patterns, and allow them to specify the hashing and cipher to be used instead of hardcoding the sha256 and chachapoly, as well as specifying the type of curve to be used (instead of only allowing 25519). |
cool, do have tests for those? The hardcoding seems fine because the RFC does not allow alternative hash or encryption scheme AFAIK |
@richard-ramos does the new description seem accurate? |
Problem
All patterns from the 35/WAKU2-NOISE RFC are available https://github.com/waku-org/js-noise/blob/master/src/patterns.ts
However, the API has not been reviewed and there are no examples to demonstrate their usage.
Acceptance Criteria
For each handshake:
Priority: do it on a need basis
Check list:
Notes
The hashing, cipher and curve are currently hardcoded (SHA-256, ChaChaPoly and ed25519). This is as per the RFC so seems find to leave as is.
The text was updated successfully, but these errors were encountered: