I think this is saying it's:
1) A JS chromium browser automation API targeting Bun (uses Bun.* or "bun:*" apis)
2) Engineered to interact with webpages in a way that evades bot detection
Axios, like Express, is something I'm shocked to see used in any modern codebase. I loved both in the 2010s. In JS/TS-land there are much simpler and better options these days. Depending on Axios suggests the devs don't know how to use fetch. I can't think of another reason it would be a necessary dependency
I’d say I have the opposite of a narrow view of software one can write, having written everything from typical web/mobile apps to DBs, network protocols and VMs :)
My initial explorations were focused on the web, but the network-level scheme I landed on does indeed do discovery on the backend.
Appreciate this feedback. I’ve been in the weeds of this stuff for some time, so it helps to see the rubber meet the road so I know what I missed.
Easy to imagine that haha. That’s part of the reason I’d lean on a standard like JOSE and make signing happen automatically for users who prefer to use an SDK
Fair. I assume you mean asymmetric key cryptography and not JWKs in particular? JOSE is a pretty good library if you need the latter and you’re already working in JS
IMO this is a tooling issue. You can make your SDK generate keys and even base64 encode them so they appear opaque to the uninitiated (like an API key)
It's interesting to imagine taking the pubkey as identity concept to its full extents in situations like this, for example if you could create a cloud account, spin up resources, and authorize payment for them all programmatically without having to enter payment details on a form (because your keypair can authorize payment with the whatever payment method you use)
Not sure which way of constraint you're referring to, but WebAuthn credentials are bound to a domain via Relying Party ID.
There's a proposal for cross-domain usage via Related Origins, but that scheme depends on the authority of the relying party, meaning you can't say "I'd like to be represented by the same keypair across this set of unrelated domains"
Yeah, I am sort of a fan of Passkeys in principal, but they are domain bound (you can't use them across domains).
I wish there were something built into browsers that offered a scheme where your pubkey = your identity, but in short there are a lot of issues with that
The key distinction I am getting at is: self-signed as in “signed with a self-issued key pair”, as opposed to using an API key/credential that has been issued to you
1. With self-signed JWTs, you could start consuming APIs with free tiers immediately, without first visiting a site and signing up. (I could see this pattern getting traction as it helps remove friction, especially if you want to be able to ask an LLM to use some API).
2. Compare this scheme to something like the Firebase SDK, where there's a separate server-side "admin" sdk. With self-signed JWTs, you just move privileged op invocations to claims – consuming the API is identical whether from the client or server.
3. The authority model is flexible. As long as the logical owner of the resource being accessed is the one signing JWTs, you're good. A database service I'm working on embeds playgrounds into the docs site that use client-generated JWKs to access client-owned DB instances.