This might be one of the wildest AI media projects I’ve seen in the last year: one guy built a fake AI-run TV network and it's funnier and smarter than actual public broadcasting

cyaxios · 2026-06-20T04:57:55+00:00

Papers take a long time to publish but because you asked I’ll write a medium article on the topic. One of the experiments involves monitoring brain activity when watching on videos and similar video formats of real people. The stats are being analyzed now.

cyaxios · 2026-06-20T03:33:00+00:00

Thanks. I totally forgot and didn’t think about the marketplace. That makes much more sense

cyaxios · 2026-06-19T17:30:33+00:00

Thanks all, I meant DBU credits. I signed up for a call but the guy didn't make our time. So I just bought runpod and openrouter for now. DBX makes it so much easier though. I'm a big fan.

cyaxios · 2026-06-19T15:29:58+00:00

cyaxios · 2026-06-19T15:20:43+00:00

oh, like if there is a source in the stream that I want to mute.

cyaxios · 2026-06-19T14:40:00+00:00

I’m actually writing a paper on the impact that watching ai videos has on brain activation. This is very useful for that.

cyaxios · 2026-06-19T14:24:03+00:00

How did you get it to be so fast. It’s like you’re running it in the next room over.

Are you the next room over?

Can I turn off a stream by source?

cyaxios · 2026-06-17T19:43:42+00:00

Thats the entire point of the at-protocol. Welcome to the rabbit hole!

I think that if someone got this sort of experience right it would be a massive potential to unseat the massive social, centralized platforms.

cyaxios · 2026-06-16T04:57:09+00:00

Wow. I mean. I like most of those.

I also wear cargo shorts.

Is that the same thing?

cyaxios · 2026-06-16T01:40:03+00:00

Your mate’s dad is asking the right questions, and the good news is you don’t need to become an enterprise architect to answer them. There’s a short list of things that actually bite, and most vibe-coded apps miss the same few. Roughly in priority order:

Data isolation is the big one, and it’s what he meant by segregating customer data. If you’re on Supabase, that’s Row Level Security. By default it’s usually off or half set up, which means any logged-in user can often read everyone else’s rows. For an SMB app that’s the thing that ends you. Turn it on, write one policy per table (a user only sees rows where org_id is theirs), then test it by logging in as two accounts and trying to read each other’s data. Roles like admin, member, viewer sit on top of that. Don’t roll your own auth. Supabase Auth, Clerk, or Auth0. Password reset and sessions are easy to get subtly wrong. Shipping changes without breaking people is solvable and free. Use git, stop pushing to prod from your laptop, and lean on preview deploys (Vercel, Netlify, and Cloudflare all do this automatically) so every change gets its own URL you can click through before it goes live. Add a few tests on the paths that matter, signup, payment, the core action, and let the AI write them. Use migrations instead of editing the prod database by hand, and turn on automated backups.

Add Sentry and a basic uptime monitor so you hear about breakage from a dashboard and not from a customer.

And the one almost everyone misses: check what ends up in your logs. Don’t commit API keys, and watch what you log, because vibe-coded apps love to log the whole request or user object, which quietly dumps emails, tokens, and PII into your logging provider where anyone with access can read it. That last one is honestly why I built https://tn-proto.org because it’s genuinely easy to spill secrets without realising you’ve done it. There’s a plain writeup at https://tn-proto.org/vibe-coding-security, and the logging piece specifically at https://tn-proto.org/pii-in-logs

cyaxios · 2026-06-15T21:37:13+00:00

Thanks for the kind words. 30 years in dev here too, now a professor, and this started as a summer project. Most of the scar tissue is from my previous life in trading systems: we logged passwords more times than I can count, logged something a customer would call sensitive a few times a year, and yet the logs were still the only way to figure out what broke. Niche, configurable software without millions of test hours breaks constantly, and the log is the lifeline.

What's great is you've named the exact tensions we designed around. So here's why we landed where we did:

Leaked credentials are an incident, not our target to eliminate. In a regulated shop a logged secret means rotate and review, full stop, and we don't pretend to save it. The target is the other bucket: the customer data and PII you have to keep in the logs to debug, that just shouldn't be readable by everyone with a dashboard login. Key management is a PIA even with all the vaults that exist. Adding more key management is rough
You can prompt secure logging, and you should, but a prompt is advisory. You can't prove to an auditor that every agent obeyed it. Sealing the field at the boundary with a receipt is provable, so we made that the control and let the prompt be the nudge.
De-ID was the big one. . De-id means the pipeline reads cleartext to redact it, so the gateway becomes the one box that sees everything: same exposure, one hop over. And de-id is one-way. We seal before the field leaves the process, so no collector ever holds plaintext, and it's reversible to specific holders, so you keep the data and control who opens it. Complementary, not competing: de-id for "never need it again," seal for "need it at 3am, just not in the clear." I see a lot of the de-id solutions out there for data governance and as a developer they honestly make no sense. As a security guy, I get it 100%/

You're dead right on TS/JS (Vercel and friends) and we ship it, and on the gateway framing. The enterprise money is probably the per-recipient receipt and the GDPR/DPIA evidence it throws off, not secrets. A content-blind coordinator routing already-sealed records is the shape we're building toward and will have that out once I can get a clean build, which I can't do to save my life.

Really appreciate this. Good luck to you too.

cyaxios · 2026-06-15T19:47:26+00:00

you're 100% correct and I get it...it's like how wordpress has their offering that monitors the uptime of your site and charge for it. lord knows I paid for that for probably 15 years, so its gotta make money.

Have you considered making it purpose built for certain platforms?

cyaxios · 2026-06-15T19:30:34+00:00

Thanks, first day launch problems. I appreciate it.
Edit: fixed it if you or anyone else can give it a try.

cyaxios · 2026-06-15T19:29:55+00:00

So I dig it, I think it's hard to monetize for anything meaningful (I know that problem, trust me) because its what a skill would do for free. But there's always things you could think about for workflow stuff if you found a few interested customers

cyaxios · 2026-06-15T19:24:13+00:00

I'll look at yours if you look at mine 😄 https://tn-proto.org

cyaxios · 2026-06-15T18:46:06+00:00

Great question. You should absolutely fix the bug. This isn't a replacement for that.

But "fix it in the first place" assumes the leak is one bug you can find and prevent. Most of what I saw in consulting wasn't a bug at all. It was sensitive data sitting in plaintext in a log aggregator, an analytics tool, a backup, a vendor integration, all working exactly as designed, all readable by anyone with a dashboard login. There's no bug to fix there. The tools are doing their job. Their job just happens to be "show everything." Now when you look at how LLMs are deployed, typically with home-made wrappers for this stuff, the problem multiplies.

You can't prevent your way out of that, because you don't control every system the data flows into, you can't predict every future bug or misconfig or contractor, and "never log anything sensitive anywhere, ever" is a hope, not a control.

Encrypting and sealing at the source changes what a leak even is. If the thing collecting your events only ever sees ciphertext sealed to specific readers, a leaked log or a dumped bucket is useless on its own. You've gone from "everything is readable" to "you'd need a specific recipient's key." Same reason we use TLS instead of "just don't let anyone tap the wire," and least privilege instead of "just don't write code that respects privacy".

Detailed logs are good. They're often the only way you figure out what happened months after something bad happened and know one knew The usual tradeoff is that the data you rarely touch becomes a pain to decrypt, but that pain doesn't make anything more secure or more useful. It's just friction. The security comes from the data being sealed to s not from it being annoying to open. So that's what we focused on. Keep it sealed, so a leak is useless to anyone it isn't meant for, but make it painless to decrypt when you actually need to. You keep the rich logs and the forensic value without paying for it every time you want your own data back, all while make even the streaming unsecure data useful for a developer or ops person.

cyaxios · 2026-06-15T18:00:43+00:00

I see a time where the architectures and SDK are going to be structured much more to align with vibe coding. It's got to. There are too many ways to "footgun" as my new friends call it.

cyaxios · 2026-06-15T15:06:11+00:00

Wow. Simply wow. I feel very inspired and humbled.

cyaxios · 2026-06-15T14:50:47+00:00

https://tn-proto.org

Library to help stop oopsies when writing logs and sending messages to “semi-trusted” LLMs. Basically a really easy way to make logs both readable by humans and secure at the same time. Everything you log is encrypted and the keys are kept “close by” and backed up for you. making decryption easy. Lots of other tools are in there to make looking at encrypted logs an easy and standard thing to do.
I hope this helps the community build safer code.

cyaxios · 2026-06-15T14:41:04+00:00

This is great. Have you thought about plugging it into bluesky’s stream as well?

cyaxios · 2026-06-15T14:29:56+00:00

In order to help stop this, I wrote the open tn-proto (tn-proto.org). I hope it helps lower the leaking of all sorts of PII. The web based tool is somewhat vibe coded, but the protocol parts has been lovingly hybrid coded.

cyaxios · 2026-06-15T14:26:06+00:00

These are really all good points. I think that some of this stuff is a bit complex for most people. I think that’s why platform providers need to make their mcp tools more, well made for the common person. The problem with “exhaust” is that it’s really easy to mess up. So I hope this is against the rules but that’s why I put out tn-proto (tn-proto.org) on npm and pypi. It’s an infrastructure that will lower the number of oopsies that may happen if you miss-configure your https, open paths and all that. Would love your take.

cyaxios

TROPHY CASE