« Pubkeeper: A 21st century operator
We cornered a few of the creators of Pubkeeper (a niolabs patent pending product) and asked them a few questions about their clever communications broker. We melded their answers together to best explain the magic behind the matchmaker known as Pubkeeper.
First things first, what is Pubkeeper?
Pubkeeper enables different sized and types of devices to share information with one another in real-time using communication protocols they already know and love.
Why was it built?
Pubkeeper exists because we saw that complex distributed systems often encompass many different devices that use different communication protocols. We want devices in these systems to be able to communicate with one another directly, but don’t want to settle for selecting one and only one protocol throughout the system.
The party looking to publish or subscribe to a data topic should not have to care how data makes its way through a system, only that it is able to do so. Pubkeeper allows for disparate communications protocols to be hidden behind an abstracted client which allows participants to publish and subscribe to data within the system, regardless of the client type. For example, one benefit of removing protocol-dependency is that web browsers can become an equal participant in the nio pub/sub environment.
What makes Pubkeeper cool?
Pubkeeper is cool because it reduces the friction of adding any type of node into a complex system. For developers, the existence of many different Pubkeeper client libraries and Pubkeeper brews means that you can introduce real-time communication into your applications without custom development.
Explain Brews as they pertain to Pubkeeper? How many Brews are there?
We use the old-time telephone operator analogy to explain Pubkeeper: a brew is a cable that connects a caller to a receiver. Some callers need a certain kind of cable, some receivers need another kind of cable. Finding a cable that fits both is a specific brew.
Pubkeeper brews correspond to communication protocols. Adding support to a Pubkeeper client for a specific protocol is implementing a brew in the language of the Pubkeeper client. This means there are many (essentially infinite) numbers of brews that may be created. We have several commonly used brews already created and plan to leverage the open-source developer community to create more.
SECURITY!
Pubkeeper end-to-end encrypts all messages sent within the system by default. This is done behind the scenes and is invisible to the end-user, which significantly lowers the barrier to applying encryption in your applications. This allows system participants to send encrypted data across public networks without risk of eavesdropping. It also prevents non participants from injecting data onto a topic and having subscribers interpret that data as valid.
Fast forward; what does the future of Pubkeeper look like?
There are a few ways that Pubkeeper will improve over time. One is through support for more client languages and Pubkeeper brews. This will be driven largely by open-source community contributions and means that users of Pubkeeper will be able to interact with a broader set of devices and protocols. Another is through improvements to the functionality of the Pubkeeper server and clients. Also on the roadmap as we develop Pubkeeper is creating decentralized/consensus-based Pubkeeper matchers. Basically, creating the ability to match up patrons and brewers on a local level and not rely on a single, centralized broker.
Fun fact: Pubkeeper's name
Pubkeeper isn't directly named after a barkeep, however, it is the keeper of publishers. With that in place, the pieces of Pubkeeper all got their names. Brewers are where information is created, the Brew is the type of sub-protocol communication layer, and the Patrons consume the brewed information. There can be as many brews as there are IoT protocols being used. Come on, that's pretty awesome!
Meet the Brewmasters:
