Showing posts with label namespace. Show all posts
Showing posts with label namespace. Show all posts

Recent work on system messaging

Mike's Notes

The work this week. 

I found a problem with the existing Pipi 6 era Messaging Engine (msg). It needed to be replaced to support the richer Pipi 9 internal environment of autonomous agents that can self-organise and move.

I spent days staring into space, and then the solution became very clear while daydreaming 😴 between morning coffee and ice cream summer afternoons 😎. Slow but getting there.

Resources

References

  • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series), by Gregor Hohpe and Bobby Woolf.
  • Integration Patterns (Patterns & Practices). Microsoft.

Repository

  • Home > Ajabbi Research > Library > Authors > Gregor Hophe
  • Home > Handbook > 

Last Updated

25/01/2026

Recent work on system messaging

By: Mike Peters
On a Sandy Beach: 22/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4 (2005-2008)

A simple internal messaging system was invented and built for Pipi 4 around 2005. It had a messaging store and handled interactions between different internal systems. It was not called a messaging system; it was an unnamed part of the Metadata Repository. It was built in CFML code and ran on MS SQL Server.

Pipi 6 (2017-2019)

After reading about Apache Kafka and RabbitMQ, I realised that Pipi 4 had contained a primitive internal messaging system, 5 years before Kafka. A new, quick-and-dirty broker-based messaging system, similar to RabbitMQ, was built as a CFML module to send messages across hundreds of modules when Pipi 4 was rebuilt from memory as Pipi 6. The work of Gregor Hohpe and Bobby Woolf was an inspiration. Martin Fowler was an enormous influence on everything.


Pipi 9 (2023-

It has taken all week to figure out a solution. I ended up splitting the role of the engine

  • The existing Pipi 6 messaging module is now being fully refactored into the Pipi 9 Messaging Engine (msg). Previously, it used a wrapper to make it appear to be an agent. Some minor changes are being made to the Namespace Engine (nsp).
  • The new Messaging Engine (msg) is used to create the local messaging systems via the Factory Engine (fac). The Factory Engine (fac) will place a local message store using a separate embedded database inside each agent to connect to its Messaging Endpoint. Each system (made up of many agents) has its own messaging store attached to the system router.

As agents dynamically self-assemble in response to events, the messaging system always works.

The new Engine closely follows the patterns in Enterprise Integration Patterns and even uses the same icons, aka "Gregorgrams".

Summary of changes underway

  • Internal system messaging between hundreds of autonomous agents.
  • Possible because of the Namespace Engine (nsp) built into Pipi 8.
  • External messaging between Pipi and applications, such as databases, cloud platforms and containers, will be handled using an open-source messaging system, such as Kafka or RabbitMQ.
  • The two messaging systems need to interconnect. I don't know how yet! 😇
  • Event messaging and Pub/Sub are the most common; others include CQRS, Dead Letter, and Point-to-Point.
  • Each agent has a state.
  • Essential for robust Pipi self-management.
  • The pipiWiki will automatically document the configuration of each engine, including messaging (Gregorgrams) diagrams. See link to the Primative Engine (prm) mockup above.
  • The messaging configuration can change dynamically.
  • The Messaging Engine will be accessible for configuration via the coming msg module in the Agent Workspace

Pipi 9 RBAC

Mike's Notes

This is a summary of the RBAC (Role-based access control) now used globally within Pipi 9.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/12/2025

Pipi 9 RBAC

By: Mike Peters
On a Sandy Beach: 18/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Summary

Pipi 9 uses automated RBAC (Role-based access control) to control user access to everything that has a namespace.

Pipi 10 will have additional authorisation frameworks available to be chosen by enterprise accounts.

User Account Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Default Language
  • Global authorisation framework (RBAC)
  • Account type
  • ...

Deployment Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Language (eg English)
  • Inherited User Account
  • Deployment Class (type of tenancy)
  • ...

Workspace Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Inherited language (eg English)
  • Inherited User Account
  • Inherited Deployment
  • Domain Model
  • Domain Model Template
  • ...

Autonomous Agent Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Agent Type (Pipi System, Engine, Domain, Algorithm, CAS, Digital Twin, etc.
  • ...
  • Many Roles
  • Many Policies
  • ...

Namespace Engine key to RBAC

Mike's Notes

After a bit of experimentation, it turns out the Namespace Engine (nsp) is key to reliably implementing RBAC globally.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

12/09/2025

Namespace Engine key to RBAC

By: Mike Peters
On a Sandy Beach: 12/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

This afternoon, I figured out that the Namespace Engine (nsp) already has a way to register the interfaces of every agent that is automatically built by the Factory Engine (fac). This includes industry domain-based applications, such as Websites, Health and Rail.

I added additional Interface Class Types, "Role", and "Policy", and solved the problem of making this global.

Roles

This allowed for the rapid addition of roles to any autonomous agent.

Examples

  • Website Owner
  • Website Administrator
  • Website Editor
  • Website Visitor
  • Website Search Engine
  • etc

This automatically generates security role names used by the Security Engine (scr).

Policy

This allowed for the rapid addition of policy to any autonomous agent.

Examples

  • CNAME Record
  • Website Hosting
  • Patient Record
  • etc

This automatically generates security policy names used by the Security Engine (scr).

Integration

This would also enable configuration storage in XML or other open formats for interchange and documentation.

This configuration system could be used for open-source SaaS applications.

How to set Pipi configuration

Mike's Notes

Here are my notes from today's work on the Website Engine (wbs).

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

How to set Pipi configuration

By: Mike Peters
02/02/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I'm manually migrating my first customer's website to Pipi's hosting. This is an excellent product test of the Website Engine (wbs), which sets up website hosting.

The next problem is enabling simple bullet-proof configurations for future customers to set up websites using no-code.

Each of the hundreds of modules will have many configuration options in the future, so a standardised system-wide process is needed.

This morning, I sketched some ideas on how the Admin User Interface (UI) might look.

This afternoon, I figured out that the Namespace Engine (nsp) already has a way to register the interfaces of every engine that is automatically built by the Factory Engine (fac).

I added another Interface Class Type, "Config", and solved the problem.

This allowed the fast addition of these examples of global properties that a website might have as options for the admin.

  • Meta Title
  • Meta Keywords
  • Meta Description
  • Domain Name
  • Default Language, e.g. eng
  • Plugins
  • Default Theme
  • Use References
  • Use See Also
  • Use Keywords
  • etc

Doing this also automatically generates config variable names used in internal messaging.

This would also enable configuration storage in XML or other open formats for interchange purposes and documentation.

This configuration system will also work for all the other engines and could be used for open-source SaaS applications.

Pipi 8 (2021-2022)

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Pipi 8 (2021-2022)

By: Mike Peters
On a Sandy Beach: 16/12/2022

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The microservice architecture wouldn't work because the simulator induced exponential complexity. It was going to be a big scaling problem. I had a good think and decided to go into the deep end. Instead of trying to reduce complexity, why not maximise it and then harness it? Just like in nature.

2021 Start

The key to the puzzle was introducing global namespaces and changing the architecture so that any messaging could be 100% reliable.

For security, I tried deeply nested microservices. So good so far.

Then, I introduced Algorithms and Markov Chains, fuzzy logic and noise injection.

Postgresql became the production database. Thousands of parameters were needed.

In all this, the self-documentation broke, so I was working completely blind. Pipi was headless, and there was still no API, so I only knew it was working by looking at the logs.

Rich primitives based on the objective reality of emergent layers replaced some entities. Each was a software program and ultimately derived from the fundamental laws of physics and replicable science.

I finished up before Christmas.

Influences

Wikipedia became my friend. I had to take a deep dive into algorithms, and it is amazing what you can find by googling. Every day, I watched a conference talk from QCON.

But Wait There's More

It worked, but no one could use it. The headless state of Pipi needed fixing.