LibOQS JS/WASM wrapper

[openforge-kt]

Hello again!

We had to pause the development of our .NET wrapper because we had some shipping delays for RISC-V dev boards, so we can't complete testing, but that gave us time to finish our JS wrapper.

@baentsch suggested opening a discussion, to see if there's any interest in making this wrapper "official" by transferring ownership to OQS organization. We would be happy to take full responsibility over maintenance and updates to this wrapper. As with the .NET wrapper, we plan to use this for our own projects, and have no intention of dropping it. Unlike the .NET one, this one is actually complete and published on NPM. See GitHub repository, NPM package, and docs site for any additional information.

Let me know if you have any concerns, questions, missing or unnecessary features.

[baentsch]

Thanks @openforge-kt for all your work on this! Tagging @hartm @ashman-p for input as to what LinuxFoundation/PQCA would have as demands for such a change of ownership. Also tagging @vsoftco as the OQS "language wrapper" guru for feedback regarding this proposal.

[ashman-p]

We also need Douglas's feedback as well as a formal disposition from the TSC. I defer to Hart on the legalities pertaining to a transfer under the LF.

[baentsch]

What "TSC disposition" do you think is needed here @ashman-p ? AFAIK OQS is one project that governs its own sub projects. PQCA explicitly rejected the thought of vetting single sub projects within OQS (at least when I asked for making this possible more than a year ago). @dstebila 's opinion will surely be very relevant given UWaterloo is still the by far largest organizational contributor to OQS (as well as providing most funding of actual paid-for development time for all I know).

[ashman-p]

What "TSC disposition" do you think is needed here @ashman-p ? AFAIK OQS is one project that governs its own sub projects. PQCA explicitly rejected the thought of vetting single sub projects within OQS (at least when I asked for making this possible more than a year ago). @dstebila 's opinion will surely be very relevant given UWaterloo is still the by far largest organizational contributor to OQS (as well as providing most funding of actual paid-for development time for all I know).

Sorry for the ambiguity. I was referring to OQS's TSC. I think that body would be the one to undertake the consideration and make the request to LF to check the legal aspects.

[hartm]

The OQS project can generally take in any code it wants! The only requirements are that the contribution requirements themselves (as described in the charter) are met. This typically just means licensing and DCO requirements. You don't need to ask anyone else for approval for any of this as long as licensing and DCO are correct, and, in general, you don't even need the OQS TSC to do anything. You can just get the appropriate approvals from the appropriate set of OQS maintainers.

Since this code is already MIT licensed, there shouldn't be any issues there. To do the DCO, you can either squash commit and sign the DCO (not ideal, probably, but easier) or just have @openforge-kt acknowledge the DCO and have the TSC approve it (which has been done before for OQS, and which our lawyers have approved as a viable process).

If you want to transfer ownership of the repos themselves, please add @ryjones in the conversation.

In summary:

• The decision of whether to accept the code comes down to the OQS maintainers who are responsible for the "area" where the new code is landing. This could be the TSC in some cases (e.g. there is a new subproject coming in) but doesn't have to be.
• If you want a DCO exception for a big block of new code (so you can preserve commit history), ask the OQS TSC and they can approve it.
• Nothing here needs to be decided by the PQCA TAC or any other higher-level body.

Does all of this make sense? Thanks for your time!

[openforge-kt]

The code is indeed MIT licensed, and also includes OQS acknowledgement, see LICENSE.
I can manage or remake the repository with signoffs, it might be even easier since it's only me that's made any commits, but one potential reason to potentially include PQCA or LF in this discussion is also NPM publishing. Currently, as mentioned, it's published under @openforge-sh to clearly show there's no direct association, but presumably if this is recognized as "official" or officially-backed at least, you'd want it to be under something like @oqs/liboqs or similar, which, if my understanding is correct, is trademarked by LF? Just mentioning this in case it's relevant (whole lot of assuming, potentially, presumably, and "if my understanding is correct" there)

[hartm]

I can manage or remake the repository with signoffs, it might be even easier since it's only me that's made any commits

If you're OK doing this, then that is perfect!

one potential reason to potentially include PQCA or LF in this discussion is also NPM publishing. Currently, as mentioned, it's published under @openforge-sh to clearly show there's no direct association, but presumably if this is recognized as "official" or officially-backed at least, you'd want it to be under something like @oqs/liboqs or similar, which, if my understanding is correct, is trademarked by LF?

Yes, if it's a part of OQS, you can use an NPM name like oqs or liboqs. It's good practice to check with the maintainers that you're not stepping on anyone's toes with a particular name, but that should be fine in general as long as the OQS community is OK with it. You can ask @ryjones to help with NPM stuff as well.

I hope this helps! Please let me know if you have any other questions.

[openforge-kt]

Actually, my concern here isn't so much legal as it is reputational. I've already had a similar discussion regarding naming things (and even used that exact phrasing funnily enough), but my concern here is different. I neither am nor do I claim to be an expert in regards to anything I do, and it's very possible, if not certain, that there are things that could/should be done better, or at least differently. If OQS/PQCA team slap their "seal of approval" on this, and it's subpar, it's their reputation that suffers, and since they're part of LF, it extends there as well. That's where I was going with that

[hartm]

Yes, sorry for my lack of clarity here.

If OQS/PQCA team slap their "seal of approval" on this, and it's subpar, it's their reputation that suffers, and since they're part of LF, it extends there as well. That's where I was going with that

This should be the point of emphasis from the previous post:

that should be fine in general as long as the OQS community is OK with it.

It's up to the OQS community whether they are OK with this or not, and they have the power to make the decision. I'm just pointing out that they don't need to ask the PQCA TAC or any other LF governing body for approval to do this.

[openforge-kt]

Ah my apologies as well, that part didn't really sink in, my brain was stuck on the legal aspect mentioned earlier. Thank you for all your feedback!

[hartm]

No need to apologize! Happy to help.

[RafaelAPB]

Hello folks! I'm giving some feedback as a LF Decentralized Trust contributor. I'm a maintainer of Hyperledger Cacti.

IMO, the project is in excellent shape. Typically the main concerns are documentation (both explicit and in-line), but it is not a problem of this project. There are tests that cover the implemented algorithms, so that's also a very good thing. The API is very clean and elegantly exposed, this is refreshing to see!

Some questions / comments:

1. I understand this wrapper exposes some Typescript types. The choice for typed interfaces/untyped implementation seems beneficial in this context. Why do you not use these types for type safety on the codebase (e.g., client)? Perhaps for performance reasons?
2. It seems to me that you are using two different runtimes (Bun and Deno). Why?
3. I recommend adding notes on compatibility for bun and node in the engine field of package.json, to enhance self-documentation:

{
"engines": {
"node": ">=22.0.0",
"bun": ">=1.3.0"
}
}

4. The build script uses nproc, which does not seem natively availabe on MacOS. Possibly documenting compatibility of build.sh on the readme is useful for users.
5. JSDocs are really nice. Consider using @category to group algorithms in the generated documentation

[openforge-kt]

Hi there, I appreciate the feedback. While docs are fairly comprehensive, they do still lack quite a few things, but most of them are done, locally only though.

1. Best way to describe this is opinionated choice. I prefer clean JS over TS, but obviously I have to support TS
2. It's not really using 2 runtimes, it's supporting them, since I intend to have this on both JSR and NPM, and there are some differences, imports and tests mainly
3. This was omitted somewhat intentionally, this supports npm, pnpm, yarn, and bun (and deno of course, but not relevant for this list), so it was safest to omit package managers, not to interfere with others.
4. This is actually a very good catch, thank you, I honestly wasn't even aware nproc isn't a thing on MacOS
5. I hadn't considered this at all, it's definitely worth though

[dstebila]

Thanks @RafaelAPB for the review and feedback!

[RafaelAPB]

Thank you for the answers @openforge-kt. On 3 - why is it safest to omit package managers versioning?

[openforge-kt]

Hey @RafaelAPB I'm sorry I completely missed your message and the related email, I think safest was the wrong choice of words there, it'd be more accurate to say it doesn't really make a difference, node version is the only relevant engine there, pnpm and yarn don't enforce their own version from engines field, bun's support for engines is hit or miss, and npm is the only one that actually enforces it, but only with engine-strict set, so having each of the engines explicitly there would at best throw a few warnings for some people.

Node is really the only "hard" requirement here, for SIMD support, everything else... somewhat arbitrary. This entire project is pure JS, the only use for the package manager is the test suite and docs, and if you want to count it, TS.

Oh and since I'm commenting here, just to update on what I mentioned in open-quantum-safe/tsc#226 (comment) this org and account will be decommissioned, and @ktufekcic is the account that'll handle the updates and maintenance, Ry is already familiar with this account and associated email address, just to confirm from this side as well.

[ryjones]

If this moves forward, be sure to get in touch with me so I can help make the transition