At first I was stoked to have a two letter domain, but then I looked into it and learned these companies will get you hooked with a low initial price, then jack up the prices as the domain becomes established.

Quite the grift. My plan is to tread lightly on that domain and be ready to back away from it when the rent seekers move in.

You’d think there would be some sort of rules to the neutrality of these TLD administrators, but nope.

The second time around I wised up and go ogplus.net for an API domain instead of ogplus.media. I’ll take neutrality over vanity any day.

Another idea I’m exploring is having agents write code for simple tasks. First example, if you run “hello world” with agent script, the first time an agent reads the text file, understands its simple, then writes a static memory.js file. When the program runs again, it hits that file and never invokes the agent.

Where things get interesting are the cases where a script works for some cases, but not all. When that happens, the memory.js script can call agent.resume() during a static run so the agent can take over.

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

Points: 3

# Comments: 1

It does this by taking a screenshot of the page, but before it does that, you can modify what’s displayed in the screenshot with CSS, tailwind classes, meta tags, or HTML templates.

If you connect your website to it, the only thing you need to deploy to your web app are a few meta tags. The OG+ servers do the heavy lifting of processing the meta tags to setup the page, take a screenshot of it, and serve it up to the consumer.

The other cool thing it does is generate a different Open Graph images per social network so they all get an image for the exact size they works best in their previews. The CSS or HTML templates are aware of this too so you can display different content to specific social networks.

To be clear, I think both censorship regimes are not good, but I can't say I'm surprised.

I wrote about it at https://beautifulruby.com/articles/portable-workstation-iter... if you want to see the setup.

It’s “Hotwire for command-line apps”, meaning you can ship a CLI in a Rails app without building an API. The dream is to make it work for all major web frameworks.

Terminalwire streams stdio, browser launch commands, and a few more things needs to ship a CLI for a SaaS quickly.

The best part is when you want to ship a feature for the CLI, you don’t have to worry about pushing out updates to clients and making sure it’s compatible with your API.

A more interesting development are companies that are using it as a replacement for MCP in AI stacks. They’re reporting less token usage and better overall results.

Slightly different issue involving the Apple credit card, but it’s just as insane that there’s no separation between the different parts of Apple.

For that reason I will never have an Apple Card, and I guess I won’t be redeeming Apple gift cards with my Apple ID.

Fast forward 12-18 months, after several new features ship and several breaking API changes are made and teams that ship CLIs start to realize it’s actually a big undertaking to keep installed CLI software up-to-date with the API. It turns out there’s a lot of auto-updating infrastructure that has to be managed and even if the team gets that right, it can still be tricky managing which versions get deprecated vs not.

I built Terminalwire (https://terminalwire.com) to solve this problem. It replaces JSON APIs with a smaller API that streams stdio (kind of like ssh), and other commands that control browsers, security, and file access to the client.

It’s so weird to me how each company wants to ship their own CLI and auto-update infrastructure around it. It’s analogous to companies wanting to ship their own browser to consume their own website and deal with all the auto update infrastructure around that. It’s madness.