danscan

How does the directive bound what it applies to? I imagine they could be in compliance by renaming the model

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

I've never even heard of Sacks until now

Bless your soul

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

TIL nobody can spell phyzix

It’s not about doing discovery _from_ personal apps, but the inverse: doing discovery _of_ personal apps.

For example, an app that uses an AI chat API can discover and route requests to your preferred provider (ollama, etc)

Fair that this post lacks background.

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.

Ah, and just the subtle crypto API to generate keys? Or are you not generating them on the client?

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)

Valid

Ah, yes I agree

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

For sure. Would likely need to be combined with another mechanism like IP rate limits

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

The things that change are:

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.

Haven't heard of PASETO, but I'll check it out. I'd say JOSE is an implementation detail of what I'm advocating for, so very open to alternatives.

Bummer. Not sure what I can do about that, but I assure you it is not pornography!

In some apps, the client may be the signing authority (e.g. it owns the resource it's accessing).

In that case, the client can possess the JWK keypair and do its own signing.

(Author here) The JWT signer should be the authority setting claims, so if your server is the authority and the client is untrusted, the server can provide the client a pre-signed JWT with the claims it needs, and the client can send that along with requests to the API.

But this scheme is flexible. You could also have the client send "requested" claims for the server to consider adding if allowed when getting a JWT.

You could also reverse-proxy client requests through your server, adding any claims the server allows.

Came here to say this :)

People will argue with an individual as if that individual is the spokesperson for a larger group. People will call someone a hypocrite not for contradicting themselves, but for contradicting other people.

This sums up what's become so exhausting about online discussion

Locked up, locked in!

On a serious note, I think inmates should have 24/7 laptop computer access with (at least) limited sessions of internet connectivity.

This page is a great example of why FCP perf is important. It took a scenery long for any content to appear, and I bounced off the page pretty quickly a few times thinking it was down.

I can’t be the only one

Ah, so you can bullshit a bullshitter

I did a year long project to build a flexible engine for materialized views onto 1-10TB live event datasets, and our architecture was roughly converging toward this idea of "ship the code to where the indexes are" before we moved onto a different project

I'm very compelled by Rama, but unfortunately won't adopt it due to JVM for totally irrational reasons (just don't like Java/JVM). Would love to see this architecture ported!

Thanks for sharing :)