Hacker News: danscan

New comment by danscan in "Show HN: Mochi.js: bun-native high-fidelity browser automation library"

danscan — Sat, 09 May 2026 22:04:33 +0000

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

New comment by danscan in "How David Sacks crashed and burned in the White House"

danscan — Wed, 06 May 2026 23:58:14 +0000

> I've never even heard of Sacks until now

Bless your soul

New comment by danscan in "OpenAI's response to the Axios developer tool compromise"

danscan — Thu, 23 Apr 2026 03:17:07 +0000

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

New comment by danscan in "Physics Girl: Super-Kamiokande – Imaging the sun by detecting neutrinos [video]"

danscan — Tue, 03 Mar 2026 16:57:39 +0000

TIL nobody can spell phyzix

Show HN: GithubDownfall – Track GitHub incidents and downtime

danscan — Mon, 09 Feb 2026 20:05:01 +0000

Hey HN,

I made a Github incident tracker in the style of Github's contribution graph.

We're all feeling Github's increasing issues lately, so I quickly threw this together today. It includes incidents since Jan 2025, trends, and current status.

Hosted on Fly, made with Astro, bun, bun:sqlite.

Comments URL: https://news.ycombinator.com/item?id=46950356

Points: 4

# Comments: 0

New comment by danscan in "Legitimizing Personal Software"

danscan — Wed, 03 Sep 2025 20:00:42 +0000

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)

New comment by danscan in "Legitimizing Personal Software"

danscan — Wed, 03 Sep 2025 15:56:18 +0000

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.

Legitimizing Personal Software

danscan — Wed, 03 Sep 2025 14:23:34 +0000

Article URL: https://www.selfref.com/personal-software

Comments URL: https://news.ycombinator.com/item?id=45116171

Points: 3

# Comments: 4

New comment by danscan in "Self-Signed JWTs"

danscan — Sat, 02 Aug 2025 05:22:09 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Sat, 02 Aug 2025 03:49:47 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Sat, 02 Aug 2025 03:44:07 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Sat, 02 Aug 2025 03:41:59 +0000

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)

New comment by danscan in "Self-Signed JWTs"

danscan — Sat, 02 Aug 2025 00:17:55 +0000

Valid

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 23:41:01 +0000

Ah, yes I agree

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 23:40:03 +0000

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)

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 23:34:18 +0000

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"

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 23:16:58 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 22:21:34 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 22:07:20 +0000

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

New comment by danscan in "Self-Signed JWTs"

danscan — Fri, 01 Aug 2025 21:56:54 +0000

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.