I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a git protocol proxy and native solutions for each of these.
Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent.
First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup.
So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all.
Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr".
Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs.
I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!
LLM proxy for containerized AI agents. The daemon proxies LLM API calls and remote MCP tool calls through a unix socket. The runtime drives the agent loop inside the container. Credentials never cross the socket boundary.
American living in France for 5 years. Previously worked in NYC startups earning a similar salary to you. Made lots of mistakes that, if I had known better, I could've saved myself some time and money. That being said, I am doing far better financially even if I make less on paper and I just bought my first place (unthinkable in NYC). I work as a software contractor technically, though I work full time for an American company.
Your first question is what your longterm goal? Permanent relocation or experiment for a few years? In other words, where are you planning to retire? You want to make your social security payments to the correct country. Your tax paperwork will stress you out for the first few years if you don't figure that out.
In either case, I'd suggest you try to keep your American job and go fully remote. You don't need a work visa if you don't work for a European company. But if you move permanently, you should do the paperwork to replace your American employment contract with a European contracting company like I did. It's more paperwork but earning an American salary in Europe gives you a significant purchasing power advantage even if you pay more in taxes. The real killer is the paperwork. European bureaucracy sucks.
If you don't keep your American job, you should apply for jobs before moving ideally. Most EU countries have reasonably low bars for skilled worker visas. Spain and France I know are very simple. The Netherlands are a bit more confusing. Regardless, you roughly need an offer of 50 000 € and a college degree to get one.
EDIT: saw discussion about housing shortages. France has tons of housing (https://pap.fr). I had a two-bedroom apartment with a balcony in Paris proper for 1 900 €.
I confirmed that if you explicitly set the Content-Type response header to application/rss+xml it seems to work with Cloudflare Proxy enabled.
The issue here is that Cloudflare's content type check is naive. And the fact that CF is checking the content-type header directly needs to be made more explicit OR they need to do a file type check.
I wonder if popular software for generating RSS feeds might not be setting the correct content-type header? Maybe this whole issue could be mostly-fixed by a few github PR's...
Correct might be debatable here as well. My blog for example sets Content-Type to text/xml, which is not exactly wrong for an RSS feed (after all, it is text and XML) and IIRC was the default back then.
There were compatibility issues with other type headers, at least in the past.
Sounds like a kind samaritan could write a scanner to find as many RSS feeds as possible which look like RSS/Atom and don't have these content types, then go and patch the hosting software those feeds use to have the correct content types, or ask the webmasters to fix it if they're home-made sites.
As soon as a majority of sites use the correct types, clients can start requiring it for newly added feeds, which in turn will make webmasters make it right if they want their feed to work.
Not even Cloudflares own blog uses those, https://blog.cloudflare.com/rss/, or am I getting a wrong content-type shown in my dev tools? For me it is `application/xml`. So even if `application/rss+xml` were the correct type by an official spec, it's not something to rely on if it's not used commonly.
I just checked Wikipedia and it says Atom's is 'application/atom+xml' (also confirmed in the IANA registry), and RSS's is 'application/rss+xml' (but it's not registered yet, and 'text/xml' is also used widely).
'application/rss+xml' seems to be the best option though in my opinion. The '+xml' in the media type tells (good) parsers to fall back to using an XML parser if they don't understand the 'rss' part, but the 'rss' part provides more accurate information on the content's type for parsers that do understand RSS.
The number of feeds with crap headers and other non-spec stuff going on; and loads of clients missing useful headers. Ugh. It seems like it should be simple; maybe that's why there are loads of naive implementations.
Even outside of RSS, the injected scripts often make internet security significantly worse.
Since the user-agent has no way to distinguish scripts injected by cloudflare from scripts originating from the actual website, in order to pass the challenge they are forced to execute arbitrary code from an untrusted party. And malicious Javascript is practically ubiquitous on the general internet.
This is exactly the situation my company ran into. Don't hire a contractor, their incentive won't be aligned with your company and you'll overspend.
My company hired me to replace their terrible software vendor and by their own account it's been a clear success. I visit the factories and stores and work with the employees to tailor make the software for their needs.
We're finally about to hire our second developer next year using the money we've saved by ending out contract with our old software vendor.
Makefile and docopt. No muss, no fuss. No "works on my machine" issues.
I'm running a hand-rolled monorepo with ansible, terraform, and several language projects (JS/TS, Swift, Ruby) that each have a makefile to standardize entrypoints for CI/CD. Docopt is nice because it's self documenting so you can better understand how all your apps are deployed.
The hard part here is idempotency. Ansible is great for a programmer because it's learning for fun. And you just have to spar with your machine to get good.
But for a non-programmer, it's understandable you don't want to be bother with the inner workings of your OS and how to maintain Ansible script idempotency.
And for every piece of software you want to run on your server, the idempotency task grows more difficult.
My honest opinion? Tolerate the learning curve for docker-compose. Each application you need can be managed and tweaked in isolation. Troubleshooting "works on my machine" problems will cost you more time in the long-run. You can't anticipate all the weird interactions between your programs and the os. Being able to nuke the setup and rebuild from scratch is your most valuable tool.
- thin base os (install just enough to run docker-compose)
- maintain images for each of your apps you need.
- mount the essential volumes of each image to well known location on your hard drive to make manual backups easy.
Funny enough I'm on my way to Noirmoutier right now. My wife's family has a house there on the northeast side of the island near where a lot of the oldest houses are. The Passage du Gois is very convenient when driving from Paris because it saves you about 40 minutes. Otherwise you need to take the bridge. The problem is that it's only for about an hour during low tide. It's peppered with towers for those unwise enough to overstay their welcome too. Happens every once in a while. You'll often find people parked all along the Passage hunting for mussels.
The town definitely has rules about how your home must look (if it's a new construction). Old houses don't though.
The town definitely empties out during the colder months but my wife and I still enjoy going there because it beats city living. Also they installed fiber optic internet not too long ago. Since we WFH, we try to go there as often as possible.
The chimneys are likely real but sealed because of climate change related rules.
There's also a castle that dates back to the 12th century built to protect monks from vikings. They've recently finished some restoration work there too.
Thanks! I'm using this as an experience to teach myself mainly. I'm not an expert cyclist but I prefer to DIY when I can.
For example, I looked at tires and wheels as a good litmus test. What were the minimum pieces of information that you need to know to pick the right tire or wheel and make those the only filters on the site.
In terms of expertise, I've mainly farmed out to the cyclist community on Mastodon and served requests on a first-come-first-serve basis. For example, one person pointed me to sheldonbrown.com for their article on tires and it was really illuminating.
https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock
This is literally the thing I'm trying to protect against.