It was lauded for being made on Amigas. The Season 1 CGI really is rather rough compared to TNG, never mind DS9. But it improved considerably in S2.
Still, there are things like the starfield visible from C&C’s observation window never rotating because it was apparently too expensive to greenscreen it (presumably an actual physical rotating backdrop was also not feasible for whatever reason). On the other hand, I think B5 was the first TV series to use greenscreening to create large interior spaces like ship hangars.
TNG was using mainly practical effects early on, which had benefit of higher visual quality but meant not as much could be done within the budget.
Babylon 5 early and very enthusiastic use of CGI meant that the scope of what it could see was ridiculously bigger without reusing clips as much as some other places did.
One issue w/sci fi is that sci fi takes place in the future and/or has advanced technology then it is more likely to look dated than a typical sitcom where the sets are offices and living rooms.
One particular English-speaking country… The UK has issues with ASCII too, as our currently symbol (£) is not included. Not nearly as much trouble as non-English languages due to the lack of accents & such that they need, but we are still affected.
Was it ever revealed what the 2015 warning about common commercial service agreements was about?
Off the top of my mind I'd go with privacy policies: maybe their typical vagueness is exploited to the extreme, and rather than pointless legal mumbo-jumbo, they're actually a legal cornerstone of some extensive surveillance program. Hmm...
Author here! Fair point that I didn't dedicate a full section to privacy as a standalone topic. But "didn't even mention" isn't accurate either.
The entire "Why This Is Dangerous" section is about the security and data exposure implications of running a personal agent. I discuss the Lethal Trifecta (private data access + untrusted content + external actions), explain why I killed email integration after one experiment, and walk through every mitigation I run — network isolation, sandboxing, egress firewalls, approve-only mode.
I also explicitly note that right now, you have to rent frontier intelligence via API — your data leaves your machine for inference. Local models simply aren't good enough yet for this kind of agentic work, and they're significantly more susceptible to prompt injection on top of that. That's a real privacy trade-off I'm making consciously, not ignoring.
The post's angle is deliberately "here's what's possible and here's what's dangerous" rather than "here's why you shouldn't do this." I think we need both perspectives. But I'd push back on the framing that this is worse than social networks — with OpenClaw, your data at rest is Markdown on your own hardware, version-controlled in Git, deletable, portable. That's a fundamentally different posture than handing everything to a platform whose business model is monetizing your attention and data.
So, before sending a proposal I'd do everything possible to understand the reasons of the situation.
You think you know who's responsible for it; just ask him
You'll have a hard time at changing things without knowing the background of the situation.
I realized that in the microservices world this kind of duplication could be acceptable; are those apps meant to be microservices?
---
I disagree with the "data alone isn't valuable" paragraphs of your proposal; I was actually going to tell you to keep in mind DBMS, besides APIs: they're specifically built to provide data to many parties, efficiently and safely.
One concern of allowing APIs might be that it might be demanding for an app, it could require adjustments and fine-tuning.
Allowing direct access to a DBMS would largely avoid any such problem.
You might well not even need any read replica, if you don't have an enormous load of requests (but you might prefer to make them, for redundancy and decoupling).
Even some derived data could be handled by stored queries, although your team might not enjoy dabbling with sql too much.
> This architecture was designed to achieve loose coupling, high availability, and independent deployability. These remain valuable goals that any proposed changes should preserve.
Were you explicitly told that these were the goals?
If so, it sounds a lot like microservices; data duplication and very strong decoupling is encouraged, and it could be hard to convince your colleagues.
> Our current approach draws inspiration from event sourcing,
Are you sure? A core aspect of data sourcing is storing all the events, and deriving the current state from them. It might be just an event-driven architecture.
---
I agree with most of your document, anyhow, although it might be hard to convince the others, if they're all-in into microservices.
Maybe the Internet Archive might be ok to keeping some things private until x time passes; or they could require an account to access them
reply