You still need to know the hard parts: precisely what you want to build, all domain/business knowledge questions solved, but this tool automates the rest of the coding and documentation and testing.
It's going to be a wild future for software development...
> The Far Side is the only place in the Earth Moon system where you can hide military hardware and basically disappear. No optical tracking, no radar, no interception.
What prevents someone from sending a Lunar-orbiting imaging satellite to image everything on the Far Side? The Lunar Reconnaissance Orbiter has already been imaging the Far Side for over a decade.
I agree with your general points about it being a difficult location to get to, but if it's possible to put regular satellites in Lunar orbit, surely its possible to park some warheads too just in case...
If a big power gets there first, they’re not going to treat lunar orbit like some kind of shared international space. They’d treat it as their turf. At that point you can’t just assume you can drop an imaging satellite into whatever orbit you want they’d have both the motive and the capability to deny access.
Hi, curious, did you know about OpenRouter before building this?
> OpenRouter provides a unified API that gives you access to hundreds of AI models through a single endpoint, while automatically handling fallbacks and selecting the most cost-effective options. Get started with just a few lines of code using your preferred SDK or framework.
It isn't OpenAI API compatible as far as I know, but they have been providing this service for a while...
That would be a fun project. Capture some WiFi geolocation data and rebroadcast it later with an ESP32 that switches its BSSID/SSID/frequency/transmit power to match an existing fingerprint.
And then see if you can be magically transported somewhere else.
could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims.
I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.
You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers.
Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: <* or your domain>` and `Access-Control-Allow-Credentials: true` in its response.
Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content.
> I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol.
Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.
One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain.
Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite difficult.
I wouldn't mix OAuth and OIDC up when thinking about this. OAuth is a chaotic ecosystem, but OIDC is fairly well standardized.
OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.
The problem is that no one that mattered implemented them.
If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.
Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.
It's more of an invisible feature than a protocol.
The signup protocol and user flow is the same if the feature is supported or not. You just skip a step if the convenience feature is supported.
With SSO the user is inconvenienced with an additional option at sign up and login, and there's the risk of duplicate accounts. Also stronger vendor lock in.
Additionally, some corporate or personal policies might prefer to NEVER use SSO, even if it is sometimes accepted. I hate being presented with option to login with email or login with Google, and I don't know which I signed up with.
God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost when it goes south once
You can have both a gmail and a google workspace account with the same email, but I'm sure someone can do better than Google.
Also I'm pretty sure that since google is itself an SSO provider, this add another layer of clusterfuck that I don't even want to think about, regardless of whether there's a clean implementation or not, I don't even want that on my mental capacity.
reply