mailto: m at ooo-yay dot com
- No, Ergo doesn't have netsplits because there isn't anything to split with. The point does not apply.
- Ergo isn't a federated server, it's meant to scale vertically
- I was thinking that raw html might be too verbose, but canned components have signatures and types.
- Ah, I see
- If you play with A2UIs generator that's effectively what it does, just layer of abstraction or two above what you're describing.
- > The ethical side is up to you, but in a strictly technical sense I don't think there's much that Google could do to intrude on your users privacy as a result of them issuing your SSL certificate, even if they wanted to.
I'm not sure that's technically true. As a CA they definitely have the power to facilitate a MitM attack. They can also issue fraudulent certificates.
> AIUI the ACME protocol never lets the CA see the private key, only the public key, which is public by definition anyway.
That has more to do with HTTPS end to end encryption, not the protocol of issuance.
- Most every modern "big company" I have worked for is leveraging LetsEncrypt in some capacity where appropriate; some definitely more than others. I don't think you're completely wrong but I also think you're being a bit dismissive.
- What OS do you run? I was thinking of doing this with SteamOS.
- Collaboration and specifically collaboration with non git nerds. That's primarily what made GitHub win the VCS wars back in the day. The pull request model appealed to anyone who didn't want to learn crafting and emailing patches.
- Could be! I'll give it a shot
- I'm not going to link my blog again but I have a reply on this post where I link to my blog post where I talk about how I built mine. Most agents fit nicely into a finite state machine or a directed acyclic graph that responds to an event loop. I do use provider SDKs to interact with models but mostly because it saves me a lot of boilerplate. MCP clients and servers are also widely available as SDKs. The biggest thing to remember, imo, is to keep the relationship between prompts, resources, and tools in mind. They make up a sort of dynamic workflow engine.
- Heh, the bit about context engineering is palpable.
I'm writing a personal assistant which, imo, is distinct from an agent in that it has a lot of capabilities a regular agent wouldn't necessarily need such as memory, task tracking, broad solutioning capabilities, etc... I ended up writing agents that talk to other agents which have MCP prompts, resources, and tools to guide them as general problem solvers. The first agent that it hits is a supervisor that specializes in task management and as a result writes a custom context and tool selection for the react agent it tasks.
All that to say, the farther you go down this rabbit hole the more "engineering" it becomes. I wrote a bit on it here: https://ooo-yay.com/blog/building-my-own-personal-assistant/
- This was, in fact, typical for the Navy and Coast Guard before the Trump admin. As was due process.
- I'm not an expert but I was in the military a decade or so ago. The Coast Guard and DHS definitely do partner operations in international and state-run waters for interdiction; the Navy definitely did similar interdiction operations with their smaller boats usually with partner nations. The Navy shooting missiles at alleged narco boats is new. At most the Navy and Coast Guard would engage to defend or disable.
There's documentaries on streaming services where they put this on full display.
- The architecture the author is describing is called SOA and to me is much more optimal. There's variations of SOA that can occur in a monolith or as separate services but at the end of the day it stresses separation at interfaces that most people like microservices for. Microservices are really only architecturally necessary if certain parts of your application have outlier performance characteristics where it wouldn't make sense to scale the whole thing for any number of reasons (eg: database connection pooling or some other metric).
As for why microservices got so popular I think the answer lies in writing. The more a pattern is written on the more likely it is to be repeated and modeled.
Finally, the author also goes in after cloud usage in general. We're a decade and a half away from the first of these convergences. I was a systems engineer in those days and I remember how terrible they were. Software engineers requested a virtual machine, a pool of network resources, firewall rules, etc and eventually they got what they needed. The primary motivator of the cloud wasn't scale per se, to me it was that now a competent developer has an API to request those things on. They're operating on machine time instead of human time.
Some people extrapolate the same argument above and replace cloud with virtual machine and containers, "Why do I need containers when I can simply operate this load balancer, some VMs on an autoscaling group, and a managed database?!" Again, we quickly forgot that for many software engineer immersing themselves in image pipelines, operating systems maintenance, and networking details bogs them down in releasing the thing they really care about - the thing that logically gets them paid. Containers, again, traded that complexity to another team that solves it once for many people and lets software engineers live a relatively less complex life from their perspective.
There's an old adage I used to hear in the Marines that goes something like, "If you're not in the infantry then you're serving it. If you aren't doing that then you should question exactly what it is that you do here." The same can be said for software and those outside of product - we end up living to serve those that are building more closely on the product itself.
That's how I contextualize this history/evolution anyway.
- I've been working on an atproto side project. These are very much reasonable considerations when dealing in any atproto application. It is truthful to say that most BlueSky users do not use a personal PDS. It is reasonable to say Tangled will likely trend the same way. It is reasonable to say these are things anyone building on atproto must account for.
It's also factual to say that Tangled is substantially different from BlueSky. Their AppView is stateful, they synchronize via NATS, and PDSs are linked beyond that. Again, substantially more complex than your average atproto architecture.
- Coal has rising costs that occur on the facilities side and the aging facilities are becoming more unreliable on a modern grid that often needs to fluctuate power demands relatively quickly. It's also more expensive than alternatives like solar and wind, even if their subsidies are disregarded.
- Some things in life are just not that serious. People can have passion projects they plan on going nowhere.
- AtProto does have platform and user managed labelers for the moderation piece, so it's at least built into the protocol. The jury is still out on how well that concept will scale.
They probably do read that message, but they say to themselves, "Well when I did it it was for a good cause."