The Go-pher's Guide to Messaging Simplicity (Why I Wrote Nexus)

I've had to take a brief step back from working on DANI recently as I needed to tackle some challenges for work projects. So, instead of leaving you all hanging, I thought I would give you an update on something I've been working on in my "day job" that I thought was an interesting side project.

In today's fast-paced digital world, connecting different services and applications is a challenge. Many organizations rely on complex, costly messaging platforms that introduce significant operational overhead and vendor lock-in. What if there was a better way? A messaging solution that was secure, easy to deploy, and gave you full control?

Welcome to Nexus, a secure, observable, and extensible event distribution platform designed to connect publishers and subscribers with minimal operational overhead. Built with simplicity and control at its core, Nexus is a compelling alternative to traditional cloud-managed services and heavyweight message brokers.

Key Value Propositions

Nexus stands out by focusing on a few core principles that deliver immense value:

• Operational Simplicity: Nexus is a single Go binary with zero external dependencies by default. This simplifies deployment, which can be done in hours rather than weeks or months.

• Security-First Design: It uses RSA-based authentication, constant-time cryptographic comparisons, and replay attack protection. Metrics are also protected with an optional token.

• Observability: With built-in health checks (/healthz, /readyz) and Prometheus-compatible metrics, Nexus provides the necessary tools for monitoring and debugging.

• Cost Control and Portability: Nexus offers a predictable infrastructure cost, a significant advantage over the pay-per-use model of many cloud services that can become expensive at scale. It is also cross-platform, working identically on Linux, Windows, and macOS.

Nexus vs. the Alternatives

From the work I've done, I've had the chance to see how Nexus stacks up against other systems.

• Compared to Cloud-Managed Services (AWS SNS/SQS, GCP Pub/Sub): While these services offer massive global scalability and immediate access, they come with high vendor lock-in and can get pretty pricey at scale. With Nexus, you get full control over your deployment and data, a predictable cost structure, and zero vendor lock-in as it is open-source.

• Compared to Enterprise Message Brokers (Apache Kafka, RabbitMQ): These platforms are powerful but have a steep learning curve and high operational complexity. Deploying a complex cluster can take weeks to months. Nexus, with its single-binary deployment and low operational complexity, offers a gentle learning curve and a time-to-market measured in hours.

Behind the Scenes: Technical Highlights

Nexus is a scalable pub/sub messaging system with both HTTP and WebSocket interfaces. It uses a pluggable persistence layer (SQLite by default) to store client and message state.

For high availability and scale, Nexus nodes can be run in a multi-node cluster with a load balancer. Each node maintains its own local database and synchronizes client registry changes with peer nodes through a lightweight cluster sync endpoint. This architecture provides graceful degradation and error handling.

Effortless Management with Built-in Tooling

I'm a big believer in good tooling, and Nexus comes with a suite of command-line tools to simplify common tasks:

• nexus-add-client: To provision a new client.

• nexus-add-cluster: To register a new node with the cluster.

• nexus-list-clients and nexus-list-clusters: To view existing clients and nodes.

• nexus-serve: To start the Nexus service.

These tools, combined with comprehensive documentation, make managing your Nexus deployment straightforward.

Conclusion

Nexus offers a pragmatic approach to event distribution, balancing simplicity with enterprise-grade features. It is a solid foundation for reliable messaging systems without the complexity overhead of larger platforms. For organizations seeking a middle ground between custom solutions and heavyweight message brokers, Nexus provides a compelling combination of features, security, and operational simplicity.

It’s been an interesting journey, and now that I've gotten this out there, maybe I can get back to DANI's digital hormones and see what kind of wacky emotions he's developed.

As always, feel free to leave a comment.

Building My AI Fortress: The Digital Clean Room (and Taking it on the Road!)

In the exciting and sometimes unpredictable world of AI development, especially when you're diving into robotics and experimental projects, security and control are absolutely crucial. That's why I'm building a "digital clean room" for my AI project – a secure, isolated environment where it can grow and develop without external interference.

Imagine it as a "network within a network," a private lab within my digital space. To create this, I'm using two trusty ESP32 microcontrollers, those versatile little chips that are perfect for this kind of project.

The Front Door: Controlled Access

The first ESP32 acts as the "gatekeeper." It connects to my home router (or any available Wi-Fi), allowing me to access the clean room from the outside world. However, this access is strictly limited – think of it as a heavily guarded checkpoint. I’m using the WifiManager library for this ESP32, which is a lifesaver. It automatically scans for available networks, allowing me to easily enter credentials. No more hardcoding network details for every location!

The Inner Sanctum: AI's Safe Haven

The 'Airlock'

The second ESP32 creates the "inner sanctum," acting as a dedicated access point for my AI and robotics projects. This internal network is completely isolated from the outside internet, a secure bubble where my AI can learn and grow without external influence.

The Airlock: Bridging the Gap

The two ESP32s communicate using UART, a simple serial communication protocol. This is where the magic happens – it's where I can implement strict filtering and control the flow of information, acting as an airlock between the AI and the outside world. I put a small display to show the external IP address, in case I ever need to access the clean room, and status messages.

Why This Elaborate Setup?

• Security First: While I don't expect hordes of hackers, it's always better to be safe than sorry. This setup adds a robust layer of protection, significantly hindering unauthorized access.
• AI Purity: Controlled Learning: I want to shield my AI from external influences, especially during its formative stages. It's vital to control the data it learns from, ensuring a solid foundation.
• Protecting the "Child": Think of it as nurturing a child in a safe environment. I want to carefully curate the AI's initial experiences and training data before it explores the vast and sometimes chaotic internet.
• Road-Ready AI, Cyberdeck Style!: This airlock setup has an added benefit. It makes my projects truly portable! I can take them on the road for demonstrations. As long as there's a power source and a network, I can connect an additional computer, like my trusty Raspberry Pi400, directly into the internal network. And here's the fun part: I'm planning to add a small TFT screen via a cyberdeck expansion to the Pi400. This will transform it into a self-contained, portable AI workstation, allowing me to interact with the AI's code, monitor its memory, and keep everything running smoothly, no matter where I am.

The Portable Command Centre: My Raspberry Pi400

At the heart of my portable AI lab is my trusty Raspberry Pi400. This isn't just a computer; it's the portable command centre for my AI project. It's the key to interacting with the AI within the secure confines of the internal network.

Here's why the Pi400 is so crucial:

• Direct Access to the Inner Sanctum: The Pi400 connects directly to the internal network (IN), providing a secure platform for code development, debugging, and monitoring.

• 

  Raspberry Pi400 with Waveshare 3.5" screen
  and the Adafruit Cyberdeck

  Real-Time Monitoring: I can use the Pi400 to monitor the AI's memory usage, processing activity, and overall performance.
• Cyberdeck Expansion: To make this truly portable, I'm adding a small TFT screen via a cyberdeck expansion. This transforms the Pi400 into a self-contained, mobile workstation.
• On-the-Go Development: Whether I'm at a demonstration, a workshop, or simply working from a different location, the Pi400 allows me to access and manage my AI project with ease.
• The gateway to the airlock: The pi400 will be the main device used to send and receive information through the airlock.
• With the Pi400 as my portable command centre, I have the flexibility and control I need to develop and showcase my AI projects, no matter where I am.

At a later date, I may replace the Pi400 with a PiZero2 and a custom keyboard, to make things more compact, but for now, the Pi400 is perfect for the job. Plus, it gives me a full size keyboard for a more comfortable experience..

Controlled Growth, Controlled Access

Yes, this approach might temporarily limit the AI's exposure and potentially slow its initial learning curve. However, in this experimental space, I believe caution is key. It's better to guide its development carefully than to risk exposing it to unfiltered data too early.

By creating this digital clean room and airlock, I'm building a secure, portable, and controlled environment where my AI can thrive. And with the cyberdeck expansion, I'm adding a touch of classic hacker spirit to my mobile AI lab. It's a testament to the importance of security, careful nurturing, and adaptability in the exciting world of AI development.