Geistesblitz: Message bus for ecosystem tooling


Currently, I’m working on a project that involves heavy use of golang’s watermill event routing library. I also recently skimmed the asyncApi initiative as well as the cloudevents specificacion. Those tools combined promise an absolutely insane amount of leverage to the possibility of the development of a custom event driven message bus for our tooling ecosystem.

An event driven message bus smells like a huge opportunity to expose a consolidated interface to own and downstream tooling which tries to reason about the build status of nixpkgs branches, PRs and even individual packages and need to react in automatic ways to it.

So, since this idea is very immature, your feedback is needed for potential use cases of such (public) message bus. Your feedback will enable me to stay on the lookout for patterns on a background thread in my head while working day-time job-ish on this project. (Gib dem Affen Zucker! :wink:)

Impact analysis

  • Internal tools can consume messages from a well-known event bus and react in automated ways to them.
  • A public read-only endpoint could be consumed by the broader community, in ingenious ways. Why not have a IOT alarm button going off when one of the tracked packages are reported broken by hydra? (Stuff like that and more)
  • Tooling (e.g. github actions) of (trusted) distributed flake repositories / registries could be granted (restricted) provider roles to also stream their build events to the larger community.


I came across this article which frames the cloudevents from an asyncapi perspective and suggests benefits in combining them when working with FAAS / serverless.

Serverless might become a focus of interest as ideas around NixOS IOT button evolve.

/cc @nixinator