The rewrite principle I’d use for both is:
Don’t organize around the technology. Organize around what you believed at each point in the investigation.
That turns “here’s how iptables works” into “here’s why I ended up needing iptables,” and “here’s how to configure Sunspot” into “here’s what I discovered after finally testing advice I’d been confidently giving people for years.”
Wyze currently contains two different posts fighting each other:
Post A: I restored an unsupported RTSP feature and used iptables to isolate a Wyze camera.
Post B: I bought a network camera, told it I wanted nothing except a local video stream, and discovered that the device simply did not possess the concept of “don't send my video to somebody else's computer.”
Post B is much more interesting.
The strongest moment is buried under the heading “Now What?”:
after getting RTSP working, you realize the cameras are constantly communicating with remote servers, and there's no setting to make the camera local-only. (RobSears.com)
That's where I would start the post.
Something like the conceptual hook:
I wanted one feature from my $15 security camera: send video twenty feet across my house.
Apparently this required the Internet.
Now we have a weird problem.
And it gets weirder: you don't object to Wyze having cloud functionality. The camera was built for it. Your objection is that cloud access isn't a feature you can disable; it's an architectural assumption.
That distinction keeps the post from becoming generic “cloud bad/privacy good.”
I'd restructure Wyze like this
| Beat | New narrative |
|---|---|
| Hook | “Why does a camera streaming video from one machine in my house to another need to talk to the Internet at all?” |
| Setup | $15 clearance cameras, bought for future hacking. Eventually you want OpenCV/Home Assistant/object detection. |
| First obstacle | Great, Wyze supports RTSP… except they killed it. |
| Investigation #1 | Find old firmware, discover Internet Archive/download survives, flash it. Small hacker victory. |
| Apparent success | VLC sees local RTSP. Done, right? |
| Uh… no | Watch the network. Camera is still talking outside constantly. |
| Clarify the threat model | Cloud access itself isn't evil. You simply don't want it. The disturbing thing is that the device provides no meaningful off switch. |
| Investigation #2 | Can I stop WAN access without killing LAN RTSP? That's the actual networking puzzle. |
| Firewall experiment | Build the custom chain. Explain only enough iptables semantics to make the experiment intelligible. |
| Unexpected breakage | Local RTSP works. Wyze's own app doesn't—even locally. Interesting! This tells you something about how “local” operation is actually designed. |
| Verification | Don't trust the firewall because you wrote three lines that look plausible. Observe traffic and prove nothing escapes. |
| Realization | You didn't add a privacy feature to the camera. You built an external containment boundary because the camera itself didn't give you one. |
| Kicker | Ownership isn't merely possession or access to a device; it's the ability to decide what that device is allowed to do. |
The huge improvement would be cutting maybe 60–70% of the line-by-line iptables explanation from the main narrative.
Right now the story pauses so you can explain tables, chains, INPUT, OUTPUT, FORWARD, -I, -m mac, --mac-source, -j DROP, CIDR notation, rule ordering, and so forth. (RobSears.com)
That's excellent material for:
Appendix: The actual iptables rules
or perhaps a collapsible <details> section if your site supports it.
In the narrative, I need approximately this much:
I created a chain that said: traffic from these camera MAC addresses may reach
192.168.1.0/24; everything else gets dropped. ACCEPT has to precede DROP because iptables stops at the first matching rule.
Then show the rules.
Done.
A technical reader can understand it. A less technical reader doesn't spend 800 words learning iptables before finding out whether the experiment worked.
There is also a better experiment hiding inside Wyze
Your current post says you did network analysis afterward and confirmed that the streams weren't escaping. (RobSears.com)
I would elevate that significantly.
Because it creates a nice three-stage epistemic progression:
I assume the camera is talking to Wyze. → I configure rules that should prevent it. → I observe the network to prove the rules actually do.
That is much more aligned with your newer writing.
You could even make the discovery more concrete if you still have any of the original observations: destinations, DNS lookups, packet counts before/after, connection attempts, whatever. Not because readers need packet captures, but because:
“The setting should work”
and
“tcpdump shows zero packets crossing the WAN boundary”
are very different levels of knowledge.
That's straight out of the worldview behind Trust Me Bro.
The real distinction between an A and B version of these posts
Neither one needs an artificially profound philosophy section bolted onto the end.
That's the trap.
The philosophical material is already latent in the events.
For Solr:
I trusted a metric's label → questioned what it measured → traced the whole system → tested my own long-standing advice → discovered the label was misleading.
Lesson: measurements need models.
For Wyze:
I assumed “local RTSP” meant local operation → observed otherwise → couldn't express my preference inside the device → imposed the policy at a boundary I controlled.
Lesson: control lives at the layer where policy can actually be enforced.
Those are very Rob ideas. They're not abstractions pasted onto tutorials. They're what actually happened.
And in both cases I'd use the same editing test:
At any paragraph, ask: is the reader learning this because Rob needs to know it next, or because Rob knows it and feels compelled to explain it?
If it's the second, cut it, compress it, or put it in an appendix.
That single rule would probably take Solr from B− to A− and Wyze from B to A/A− without changing their underlying subject matter at all.