frontpage.
newsnewestaskshowjobs

Open Source @Github

fp.

ElevenLabs, TwelveLabs, ThirteenLabs

https://quantumi.sh/public/labs.html
147•jemoka•3h ago•61 comments

A Friendly Introduction to Racket

https://geometridae.bearblog.dev/a-friendly-introduction-to-racket/
77•signa11•4h ago•25 comments

RF Cafe

https://www.rfcafe.com/
44•gregsadetsky•3d ago•7 comments

Hister – A private, full content search index that you control

https://hister.org/
40•auraham•3d ago•1 comments

Munder Difflin – Agent harness to run an office of your clones

https://munderdiffl.in/
209•simonpure•8h ago•84 comments

typ.ing

https://typ.ing/
31•bookofjoe•4d ago•9 comments

New MCP Roadmap

https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
133•pentagrama•5h ago•102 comments

Z80 – The 1970s Microprocessor Still Alive (2021)

https://www.computer.org/csdl/magazine/mi/2021/06/09623402/1yJTvlRLmhi
90•asdefghyk•8h ago•46 comments

Belgian car salesman becomes prince after DNA test proves royal parentage

https://www.cnn.com/2026/08/22/europe/prince-belgium-secret-son-scli-intl
47•MilnerRoute•1h ago•25 comments

Show HN: Public Muscriptor Instance (latest, most powerful Audio-to-MIDI model)

https://www.pianoify.net/
12•jardy•1d ago•0 comments

Why it might be time to rethink the human family tree

https://nautil.us/why-it-might-be-time-to-rethink-the-human-family-tree-1283985
17•Anon84•2d ago•11 comments

Ameliorate

https://ameliorate.app/
55•hakkikonu•1d ago•17 comments

ATProto spaces: A new extension to ATProto that enables non-public data

https://atproto.com/blog/atproto-spaces-alpha
14•grappler•1d ago•3 comments

The Creation of Abulafia

https://blog.veitheller.de/abulafia.html
9•saulpw•22h ago•0 comments

Conway's Game of Life in real life

https://blog.coredump.cx/p/conways-game-of-life-in-real-life
10•surprisetalk•2d ago•0 comments

Show HN: Rotation via Double Reflection

https://static.laszlokorte.de/rotor-reflect/
41•laszlokorte•1d ago•8 comments

Show HN: terminal-code – VS Code inside the terminal

https://terminal-code.com
15•robpruzan•3d ago•2 comments

Rust Glancer: Rust LSP using 100x less RAM

https://rust-glancer.github.io/blog/hello-world/
371•matklad•22h ago•84 comments

Dynamical dark energy and the week that broke cosmology

https://perimeterinstitute.ca/news/dynamical-dark-energy-and-week-broke-cosmology
22•rznicolet•1d ago•5 comments

Mythic's analog compute-in-memory architecture

https://www.mythic.ai
12•janandonly•3d ago•0 comments

One Night in Uzbekistan

https://statmodeling.stat.columbia.edu/2026/08/20/we-couldnt-reproduce-their-findings-and-realize...
10•paulpauper•23h ago•0 comments

Felony Bench

https://www.felonybench.com/
806•colinprince•1d ago•322 comments

What's in a PowerPoint File?

https://editide.com/blog/what-is-a-pptx-file/
18•danielochoa0620•3d ago•15 comments

Show HN: Zcomplete – Shell Typo Correction

https://github.com/omarfakih1/zcomplete
10•omarfakih•23h ago•2 comments

Guess which of these LLM outputs is watermarked

https://sgoedecke.github.io/watermark-quiz/
11•gfysfm•2d ago•6 comments

Protocol-Aware Deterministic Simulation Testing

https://tigerbeetle.com/blog/2026-08-20-protocol-aware-dst/
3•sebg•1d ago•0 comments

Kobo can run apps now

https://bandarlabs.github.io/Cobalt/
635•thepoet•1d ago•201 comments

Felony charges for citizen deleting phone data at US Border

https://www.nytimes.com/2026/08/21/us/politics/samuel-tunick-deleted-phone-felony.html
1019•floathub•1d ago•1234 comments

ProgramBench Vetted: Reverse Engineering from a Runnable Binary

https://vetto.ai/companies/programbench-vetted.html
13•rigelbm•2d ago•1 comments

Chinese robot runs 100M sprint quicker than Usain Bolt's world record

https://www.theguardian.com/sport/2026/aug/22/chinese-robot-runs-100m-sprint-quicker-usain-bolt-w...
19•bookofjoe•5h ago•6 comments
Open in hackernews

Show HN: Anonymous age verification with passkey-powered encryption

https://loginwithone.com/
20•mikeysight•3d ago
This project has been kicking around in my head since I first heard about the webauthn PRF extension in early 2024. I've slowly chipped away at it since, and finally got things to a shareable state over the summer thanks to a very fun parental leave. Headed back to work tomorrow, so I figure there's no time like the present.

tldr: A client-held encryption key derived during passkey authentication encrypts all sensitive user data prior to persistence so that only the user is able to decrypt and reuse that data on their device. This allows short-lived, privacy-preserving age proofs to be issued to requesting applications (18+, no PII shared) without requiring users to re-upload their documents. The SSO user experience is built on top of the OAuth 2.0 Authorization Code Flow.

https://loginwithone.com - demo video + high-level architecture + FAQ

I also made the parody demo apps from the video public if anyone wants to play around with the user experience:

https://demo.brainrot.loginwithone.com https://demo.dgnrt.loginwithone.com https://demo.kirby.loginwithone.com

I suspect most will choose to pass on the ID stage for now (no offense taken, doing so is low reward in this context) but if you navigate to https://app.loginwithone.com after onboarding you can demonstrate the passkey-powered encryption on your email via the lock/unlock button.

Very open to feedback and happy to answer any questions! I plan to pull the client-side encryption functionality into an open-source typescript library for general use, so any thoughts or suggestions on what you’d like to see out of that interface would be supremely useful. Thanks all,

Michael

Comments

akshay_akula•3d ago
If you could combine this with the google oath experience somehow like age verification of my google account? I would def use that.
mikeysight•3d ago
check out the demo video! I think you'll like it :) that's the exact user experience (it's built on the same OAuth protocol) but with all underlying data encrypted to your device.
mikeysight•3d ago
also google if you're reading this don't even think about it, patent is pending and my uncle is a lawyer
tangotaylor•2d ago
> When identity documents are uploaded, they are encrypted using a master encryption key derived from the user’s passkey during authentication.

ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes.

Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement.

Anyway I appreciate the consideration given to privacy.

mikeysight•2d ago
> ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes.

Yes that's correct, the identity documents are validated alongside the selfie before the selfie is discarded and the identity documents are encrypted by the passkey-derived encryption key prior to persistence.

> Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement.

Yes this is a great callout. ONE does know the client and relying party on each verification transaction and could theoretically store these records (and your point about strict avoidance of logging PII is very important), but implemented properly, identifying the "who" behind a user after initial verification (the coerced by law enforcement example) would require modifying the server or client-side code to capture plaintext during a future passkey-bound decryption. This is also why I have a goal of open sourcing the server side code that processes the plaintext identity payload and running it in an enclave with verifiable attestation.

> Anyway I appreciate the consideration given to privacy.

Thank you! I appreciate the questions.

quadhome•33m ago
I wonder if you could have the verification use something like the Privacy Pass protocol to emit a bunch of spendable anonymous login tokens.
mikeysight•2d ago
I wrote up more of the thinking behind this here for those interested:

https://loginwithone.com/blog/the-internet-should-be-more-li...

thcr•1d ago
"One stores ciphertext: encrypted blobs created with a key held by the user. Never the underlying identity data. This includes government ID and selfie data, as well as the verified email associated with the account. "

Why does it need to store even encrypted data after the result is +18, for example? Does ONE need to keep validating against the same documents every time?

mikeysight•1d ago
Great question, and also thank you for calling this out, because "selfie data" shouldn't be included in that description, since those images are not persisted at all, encrypted or otherwise (editing now). You make a very good point about being able to reissue valid proofs based on a previous verification (and I think that could even be a viable user opt-in down the road) but the identity data that is persisted serves two main purposes: 1. reusability across applications that require a proof scoped to a valid government ID for legal purposes (non-expired, for example) or with a recency requirement (fresh photo matching the ID photo to validate you're the person holding the ID), and 2. as a means for users to self-custody their identity documents for presentation as needed across the web (future KYC ambitions for the project).