Closed rafaelbsky closed 2 weeks ago
@matthieusieben I think your 3 comments fall into the same concern, so I'll reply to them all here.
Your suggestion was to make the change in xrpc-server
so it would benefit more services at once. I think that's what we're trying to avoid: we want to only have it affect appview, to assess the performance difference. Once we confirm that, we will make the change directly in crypto
(which would benefit all services that use it).
Do you think it makes sense? LMK if I misunderstood something.
@atproto/crypto
currently does signature validation with@noble/curves
, which is a JS implementation.Our CPU profiling shows that validation takes a good CPU share, so we want to see how that improves by switching to the native
node:crypto
, but not yet changing the current implementation in@atproto/crypto
.The solution was to make customizable the signature verification function that happens inside the JWT validation, which happens on
@atproto/xrpc-server
.So in short:
@atproto/crypto
exports the utils to avoid duplication.@aproto/xrpc-server
allows customization of the signature verification function.@atproto/bsky
uses 1 to build a customization for 2, usingnode:crypto
instead of@noble/curves
.