in the middle there is pair programming with ai, see for e.g. aider: https://aider.chat/

I have found it very difficult to use aider as it makes many changes I don’t always agree with. Personally, I either use Cursor to make edits, or ask oh one to write a whole script or single-file module.

Aider is great. I file that (and similar tools) in the first category.

I agree there is an issue here -- btw, you would notice when eventually the server key changes.

User friendly and secure-by-default clients will leverage the domain HTTPS CA to solve this (fetching the server key using https). The downside is that it will require d/l and install

Best practice:

Use SSH keys for SSH connections and authentication

Use PGP keys for email encryption and file signing

Keep these systems separate as they're designed for different purposes

PGP is hairy and many developers don't have it installed and configured. It's full of non-obvious options and capabilities.

SSH is a common tool which most developers have installed, keep in a working order, use often, and reasonably understand.

Guess which tool is easier to piggyback on and achieve easier and faster adoption.

I like PGP keys for ssh auth because they can be hardware backed through openPGP. That makes it a great option (and also the actual crypto is then executed on the key itself, not by the gpg software)

You can do this with ssh keys too. And ssh keys can sign git commits. There’s no reason these days to even install a pgp suite. Stop using it.

a "server-rendered" CLI is exactly what `keypub.sh` is, and what many ssh apps are (some are more TUI)

Yeah, in retrospect, I'm an idiot. I wasn't considering `ssh foobar.io dothething` to be equivalent to what I was thinking in my head even though it is exactly equivalent.

there is email validation, and the public key is handled between the ssh client and server. If there is no valid public key this code would not even run. The fingerprint is prepared from this valid public key.

Regarding having the email in the ssh pub key: maybe it is there, but it is no validated. Anyone could write anything there

will add them both. Initially I looked at "about" and "why" as suitable only for the landing page

That's pretty reasonable, although the styling of the landing page makes it look like those are actual command outputs, so I expected them to work.

github public ssh keys are not connected to mails. and using the api from the terminal requires installing some tool.

I hope there will be lots of apps for the the terminal, for e.g. cde (cloud dev env) managing, task management, project management, compute as a service, etc.

> using the api from the terminal requires installing some tool.

It really doesn’t. It’s just a HTTP API. So basically anything that can form a TLS connection will work.

But the bigger problem here is that email addresses can be private in GitHub. Also you never know when GitHub might change their API.

it does have authorization with the `allow` and `deny` commands for granular control of who can can see what. Currently very simple, only for email but maybe other fields in the future

hi, good catch of the binary! (will fix)

`Wish` and also `terminal.shop` were both great sources of inspiration. I hope to see many more ssh apps in the future. I'm already working on the next one