danscan

Very similar in principle, but I'm aiming for something very different in UX - namely, a polished client app built for creating and messaging with an agent that coordinates work across many subagents

I find Telegram, Messages and the like to lack the fidelity I'd want for managing such stuff. And the official OpenClaw app is ... well, it's weird that they shipped that

For advanced users, always-on agents that run on your computer where all of your files/apps already are are much more powerful. I think the big AI co's skip this bc it's a smaller market and not as casual

I'm working on an open version that runs agents on your machines and brings a polished UX, and good parallel divide-and-conquer coordination

The X3 stands out a bit more than the X4. The difference is small but mighty. I was at a restaurant in my small (not the forefront of tech) town, and had two people ask about it!

I use [Crossink](https://crossink.dev) and I absolutely love it. Have it both the X4 Pro and the X3, and surprisingly (to me) I prefer the x3 for everything but reading in the dark

There is no right way :)

SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery.

Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.

I think you may have meant to comment on another post :)

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 :)