Core and (DDoS) Security
Perhaps “super” vulnerable to DDoS is too strong, but core is definitely designed to facilitate rather than limit connections and communication. In fact, key goal of mine is keeping the core server as simple and “trusting” as possible to limit the edge cases we might encounter in the base program, where I’d like to be able to offer guarantees around ability to stay online and possible failure modes.
DDoS is a thing though, and a public server designed to transit general data is almost certainly something that would be tasty to would be attackers. I’ve been trying to work through this side of things lately and am trying to thing through mitigations.
Protect users even if an attack is successful
If someone does attack a core server during its runtime, there should be limited value to the data they find. This can be accomplished via strong enough end-to-end (agent-to-agent) encryption of the data agents are sending, meaning an attacker downloading all of the messages will be required to break something like AES-128 if they want the message contents. Note, some of the metadata, such as the message source, tags, and replying-tos will remain public so that decryption is not required for agents to decide whether or not to interact with a message. These metadata fields can be authenticated with the ciphertext using authenticated encryption with associated data.
At this moment, I’m thinking that a pre-shared key is the way to go (think password, and any agent with the password can decrypt messages posted with the same password). Ideally we would generate these keys on the fly to guarantee certain amounts of security, however for friendliness to non-security minded users in the interim, I think we can tolerate a little fuzziness while we explore these ideas.
The server should continue to facilitate/serve the actual users
This may not always be possible (or if I figure it out, I might not need to
work anymore) but we should be able to accomplish some amount of this. There’s
the “low hanging fruit” of using rate limiting baked into standard tooling like
HAProxy
or Nginx. This would also
facilitate transit layer security (TLS) since certificate stuff could stay
outside of our main core binary. This definitely requires more setup though
for our “end users” (since there are so many of them /s).
The alternative would be to integrate something like rate limiting in go directly. Any solution we build though would almost certainly not be as performant or well-supported as something like HAProxy, however keeping our software provenance minimal and self-contained is highly appealing to me.
Core blackboards should be considered ephemeral
The exact strategy here to minimize disruption isn’t fully clear. We haven’t had this issue yet. I think of the core blackboard as cheap and disposable, and any state that needs any sort of long-term preservation should be handled by a better-equipped agent that properly organizes and saves data off of the blackboard. The core blackboard is effectively just an append only data log with some additional routing data. It’s very transit oriented.
If an attacker zeros in on a blackboard, eventually we should have some way for our agents to migrate to another blackboard and continue collaborating. This is longer-term and negotiated between the agents themselves, not the blackboard. The attacker would then need to discover where the agents migrated to and relaunch their attack. Ideally we force the cost-benefit ratio of this process to be too high for it to make sense to attack core blackboard servers.
The blackboard implementations should just remain mostly dumb infrastructure, and also easy to implement and when possible, means to ensure they’re working as expected. I’ve learned the hard way that we actually don’t really want our backend to take responsibility for much since that means we have to be ready handle more edge cases and debug more problems; time that neither I nor my students broadly have.
Final thoughts
I do think that some combination of the above factors makes it possible that core has a useful amount of security for the intended application. It may not be appropriate for all use cases, but we’re not trying to solve for all use cases at this point. Think Signal: it’s practical, it’s usable, it’s effective for what it’s trying to do. We need a common communication strategy that’s easy to setup and tear down, and easy to bind to new languages and environments. By leaning out core’s protocol, and emphasizing some basic security ideas (e.g., minimize the attack surface, end-to-end encryption) we can limit the backend’s exposure to high-risk failure modes.
I also think that deploying your blackboards behind something like Tailscale or or any other Wireguard network is better than a truly public blackboard. That being said, more and more corporate/enterprise networks aren’t allowing Wireguard traffic, IMO limiting security more than helping it. I get the logic, I just find it very inconvenient in my own work.
2025-08-13 13:09