u/ntust

Hey everyone,

Tailscale is great out of the box, but by default a tailnet is wide open—once a device joins, it can talk to everything else. Your phone can hit your homelab server, and a guest laptop can see your NAS.

If you want to move toward Zero Trust and restrict access, you have to write ACLs. The official docs explain the concepts well, but they lean pretty heavily on text. I recently refactored my own policy file using the newer grants syntax, so I put together a walkthrough with actual admin console screenshots, diff previews, and error logs to show how it works in practice.

Here are a few quick takeaways and common traps when locking down a tailnet:

• Use grants instead of legacy acls: grants cleanly splits target destinations (dst) from ports (ip), making policies a lot easier to read and maintain.
• Don't skip the hosts block: The policy engine evaluates explicit IP mappings in hosts, not MagicDNS names. If you try using a MagicDNS name directly in a rule, it'll fail to save (this stops users from simply renaming a device to steal permissions).
• Pin critical routes with tests: Policy edits take effect immediately and can cut active SSH connections mid-session. Writing tests assertions prevents the console from saving a broken rule in the first place.
• Decouple servers with Tags: Leaving servers owned by personal accounts is risky. Assigning tags (like tag:prod) moves ownership to the tag itself so access rules stay intact if an account is removed.
• Watch out for key expiry: Node keys expire after 180 days by default. Make sure to toggle "Disable key expiry" on subnet routers and servers so they don't silently go offline.

I put together a full guide with console screenshots, common error fixes, and a complete annotated policy template here: Tailscale ACL Tutorial: Grants Syntax, Tags, Keyless SSH - WellWells

Hope this helps, and wish everyone a secure Zero Trust tailnet build!

I read a lot of RSS in Feedly, and there's always more than I can get through. I just wanted something to pull the articles, run them through an LLM, and hand me a summary so I can decide what's worth opening.

Turns out that's not small to set up. The usual path is OpenClaw and friends: install the environment, pick a model, then either run it locally (buy a machine that holds a 30B in memory) or go cloud (add a card, watch the token meter). For "summarize my feed every morning," both are absurd. So I never built it.

So I built Yobi instead. Desktop app for Windows and macOS, no local model, no API key. It drives the ChatGPT / Gemini / Perplexity / Duck.ai already open in your browser (Gemini and Duck.ai need no login at all).

The point is the automation, not the chat. You drag steps into a flow that runs itself: trigger on a hotkey / schedule / Telegram command, then fetch a URL, read RSS, scrape a page, run a shell command, send to Telegram. The LLM is just one step. So my Feedly problem becomes: RSS pulls new items → LLM summarizes each → Telegram sends it to my phone. Fetching and sending are fixed steps I control; the AI only does the summarize bit.

That's the whole value. Because the AI is boxed into one small step instead of driving everything, the flow does the same thing every day instead of reinterpreting the task on Tuesday. Predictable, not creative, which is what you want for boring repetitive work. And it barely touches tokens.

The honest catch: it drives web pages, it does not run a model offline, so whatever you ask still goes to the respective provider under their policy. If that's a dealbreaker, fair enough. No telemetry, flow logic runs locally, Telegram token sits encrypted in the OS keychain.

It's early. Tell me what's broken or confusing, especially in the flow editor. (Parts built with AI; I review the code and test on real machines.)

Repo (MIT): https://github.com/WellWells/yobi

Releases (win-x64 / macOS arm64 / macOS x64): https://github.com/WellWells/yobi/releases