Yeah exactly like this. I like being able to approve/deny requests or "learn" from a good run and apply that policy to later runs so I can leave them unattended and know they can't access anything aside from what I approved.

Ripgrep is used as the defautl search backend for ArchiveBox, such a good tool. I was on ag (the-silver-searcher) for years before I switched, but haven't gone back since.

There's also RGA (ripgrep-all) which searches binary files like PDFs, ebooks, doc files: https://github.com/phiresky/ripgrep-all

Doesn't HN prevent that? I thought edits lock upon the first reply.

Unfortunately, no. See https://news.ycombinator.com/item?id=27395320.

Weird, I dont have any edit option on my comment after you replied.

Maybe it's a karma-gated feature?

I don't think that it is karma-gated, but you can only edit the comment for two hours after it's posted. Then it's frozen.

Ah that makes sense.

The best part is that *.*.localhost is also supported, so you can finally just replace *.com for your prod domains with *.localhost.

ArchiveBox now uses this feature by default in the latest version to finally offer unique per-snapshot domain isolation, so we can safely replay archived JS without risking compromise of your whole archive.

Such an awesome feature, the barrier to do this used to be prohibitively high but now it "just works".

Does anyone know of watchdog agencies that do the research to document and litigate harmful algorithmic trends?.

I know https://www.reset.tech/ does really good work in this space, but are there others, and who is funding them?

It's ok, I hear they recently hit 5 9s of reliablility again! (89.9999%)

THis is not without servers, you still use a signaling server for TURN.

If you want true serverless you need a side channel to copy the offer/response, e.g. tell the user's to copy paste them as base64 thorugh whatsapp manually or something (https://github.com/pirate/webrtcchat).

I wrote a webrtc chat prototype once that used a blockchain contract for the offer/response.

It was cool but a little slow and I moved onto other side projects.

Could send the offer/response over Waku protocol, some people have experimented with that to good effect.

- ZFS snapshot all your state, makes it trivial to roll back changes

- gate access to secrets via external service that replaces placeholder values with actual secrets, e.g. something like agentvault.co

- have it perform the action on a staging env with fake data, then replay the recorded action on real data without the LLM involvement (e.g. use something like stagehand / director.ai to write the initial browser automation script, but then replay the recorded LLM actions deterministically after you see it work the first time)

Inspired by the recent post where Olivier Bourbonnais figured out how to read the private accelerometer APIs on Apple Silicon macs: https://github.com/olvvier/apple-silicon-accelerometer

I created a set of CLI tools that let you pipe mac sensor data around like modular synth audio. Sensor data is outputted via stdout as a mono audio signal, and then it can be piped through filters and sent to outputs like your speaker, screen-brightness, keyboard-brightness, a TUI visualizer, and more.

Some examples of silly things that are possible:

    lid-angle | speaker  # sounds like a theremin as you move th elid

    sudo accelerometer | metronome | screen-brightness  # tap on your palmrest and it will flash to the beat

    microphone | metronome | speaker  # play a tone in sync with whatever beat is audible to the microphone (syncs the phase too)

    microphone | bandpass 0.4 6 | volume-shift 2 | tee >(keyboard-brightness) | visualizer

    sudo gyroscope | sudo fan-speed

Lots more here: https://github.com/pirate/mac-hardware-toys

Having built production apps on SQLite I can say it's not all sunshine and roses, the complexity explodes the moment you need multiple workers that can all write.

You better hope you dont have any big indexes or your writes will queue and you start getting "database is locked" errors. Good luck queueing writes properly at the application layer without rebuilding a full distributed queue system / network interface / query retry system on top of SQLite.

I really really really wish SQLite or PGLite supported multiple writers, especially if the queries are not even touching the same tables.

Oh I didn't say that, but nor is postgres. Use the right tool for the job I agree with, just people are making their lives difficult (expensive as well) by just blindly picking postgres.