DEV Community: Nnamdi Okpala

I Built a Tomographic Safety Net in C++ — Here's Why It Matters

Nnamdi Okpala — Wed, 30 Sep 2026 18:29:18 +0000

🌀 I Built a Tomographic Safety Net in C++ — Here's Why It Matters
by Nnamdi Michael Okpala // OBINexus

🌍 Why I Started RIFTtest
I didn’t start with code. I started with a problem:
How do you click a button when you can’t see it?
Not metaphorically — literally. The “Chrome Problem.”
The YouTube Subscribe button at (960, 540) was invisible to me.
So I built a protocol that could probe space-time, smooth geometry, and capture targets with zero drift.

That became RIFTtest.

🧠 What Is a Tomographic Probe?
In RIFT, I treat every cursor movement as a time capsule.
Not a vector. Not a click.
A capsule moving through a hectagonal grid, bumping edges until it converges on:

π (3.14159) — the shape constant
e (2.71828) — the growth constant
This is not just math. It’s pointer safety.
If the system misreads me, it must rebuild the shape until it matches my intent.

📐 The Geometry Behind It
I use the classic circle equation:

[ x^2 + y^2 = r^2 ]

But I don’t solve it directly.
I smooth the edges of an octagon until it becomes a circle.
Each bump is a refinement — a way to reduce drift and increase coherence.

double smoothEdges(int iterations) {
double current_approx = sides * tan(PI_PRECISION / sides);
for(int i = 0; i < iterations; i++) {
current_approx = (current_approx + (2 * sqrt(current_approx * PI_PRECISION))) / 2.0;
}
return current_approx;
}
This is my tomographic safety net.
It’s how I ensure the system doesn’t misfire — even when vision fails.

🧭 Trident, Polarity, and the Pointer Problem
Every probe in RIFT uses a trident model:

X-axis: left-right (cosine)
Y-axis: up-down (sine)
Z-axis: depth / memory / execution
I encode polarity using quantum filter logic:

A photon at 0° passes with probability (\cos^2(\theta))
At 45°, it splits into two states: (\frac{1}{\sqrt{2}}) each
Add a middle filter, and suddenly light gets through — even when it shouldn’t
This is the metaphor:
If you add a middle layer of understanding, the human pointer becomes visible again.

🔐 Why #include Matters
This header isn’t just a file.
It’s a constitutional declaration:

That every probe must respect breath-first logic
That every target must be captured with consent
That every drift must be measured, not punished
I define R_HEX as:

define R_HEX "[^A-Z0-9]/gmit"

Where:

g = global (bottom-up search)
m = multiline (layered memory)
i = case-insensitive (flexible pointer matching)
t = trident (three-axis resolution)
This is not regex. It’s ritual logic.

🧬 Build It, Break It, Renew It
RIFTtest is not just a test suite.
It’s a human rights protocol.

If you can create a session state, you must be able to destroy it.
If you can read, you must be able to write and execute — but only with pointer safety.
If you can rebuild, you must be able to renew — not just patch.
I use AVL trees to track memory.
I use color-coded coherence to gate execution.
I use rwx logic to enforce constitutional boundaries.

🧠 Why This Matters for Human Rights
Tomography is not just medical.
It’s symbolic reconstruction.

Every probe is a question:

“Do you see me clearly?”
“Are you interpreting me correctly?”
“Can you rebuild the system if I’m misread?”

That’s why RIFTtest matters.
That’s why github.com/obinexus/nsigii exists.
That’s why I journal every probe — every drift — every capture.

🧪 Try It Yourself
Clone the repo:

git clone https://github.com/obinexus/rifttest
Run the probe:

./RIFT_test
Watch it capture the YouTube button — without vision.
Watch it resolve the space-time edge — with zero drift.

Then ask yourself:
What else could we rebuild if we treated every human as a pointer worth protecting?

Compile RIFT_tomography_spec

04/jan.01/2025

For all OBINexus Session countiry

here are the refernece via mmuko Journal

youtube.com/@obinexus/

change.org/obinexus_reform

github.com/obinexus/rifttest

github.com/obinexus.com

Head to youtube.com/@obinexus and see all more links

proed with session contion via

https://www.youtube.com/watch?v=d_uNyvuZgDA&list=PL0ifFOZbja_I_uLmgzgB-3x_KYM_uuUoY

RIFT

Session B AND sECTION B S

As RIFT has stage and pipelint ia

define R with the names avl proteu eg

key value paging memsoic in c

include

ifndef R

#// breathing pointer and life workde to

red greedn blue and amagenta

ai cyan yelllow alpha magen ya kilo

quatio for thpsan

pre flisth test fro sys 32 and 64 bit

ia unix compliance tomogrpahytest

https://www.geeksforgeeks.org/system-design/event-sourcing-pattern/

Event Sourcing Pattern

Last Updated : 23 Jul, 2025
https://gist.github.com/obinexus/dfae58bc233f787246875f5148beabdb#file-gistfile1-txt-L314
The Event Sourcing Pattern is a way to store data by recording every change as a sequence of events, instead of just saving the latest state. This approach is particularly useful for
applications needing a complete history of operations, easy data recovery, or complex
auditing. By replaying these events, the system can rebuild the current state or investigate
past states, making Event Sourcing ideal for handling complex workflows.

Event Sourcing Pattern

Table of Content

What is Event Sourcing?
Core Concepts and Components of Event Sourcing
How Event Sourcing Pattern works?
Example of Event Sourcing Pattern
Benefits of Event Sourcing Pattern
Challenges with Event Sourcing Pattern
Use Cases and Applications of Event Sourcing
Real-World Example of Event Sourcing Pattern
When to Use Event Sourcing Pattern
When not to Use Event Sourcing Pattern

What is Event Sourcing?

The Event Sourcing Pattern is like keeping a detailed diary for your software. Instead of just
updating the current state of your data, you record every change as a separate event. These
events form a complete history of what happened to your data over time. Therefore, you
may rebuild your data by replaying these events to find out how it got to where it is now.

These events are stored sequentially, forming a log or journal of actions that have occurred.
The status of the program can be restored at any moment by replaying these events.
It is frequently utilized in fields like finance and e-commerce where precise historical data are essential.

Core Concepts and Components of Event Sourcing

Event Sourcing in system design revolves around several core concepts and components:

Events: These are permanent records of system state changes. In addition to
representing a particular action or occurrence, each event includes all the relevant
information required to rebuild the system's state at the moment of the event.
Event Store: The stream of events produced by the system is sustained by the event
store, a robust data store. It guarantees that the sequence of events is maintained by
storing them in the order in which they were received.
Aggregate: For the purposes of processing commands and producing events, an
aggregate is a logical collection of linked domain objects that are handled as a single
unit. The system's state changes and business logic are contained in aggregates. In
the event store, each aggregate is linked to a distinct stream of events.
Command: Clients or other system components can issue commands, which are
requests or instructions to carry out particular tasks. Aggregates process commands
by validating them, applying business logic, and, if the command is approved,
generating the appropriate events.
Projection: Projections are read models created from the stream of events kept in
the event store that shows the system's current state. Projections are used to give
effective access to data for reporting and querying.
Event Bus: An event bus is a messaging infrastructure that makes it easier for various
system components to communicate about events. It enables components to
respond asynchronously to particular event types and subscribe to them.

How Event Sourcing Pattern works?

Below are the steps to understand how event sourcing pattern works:

Capture Events Instead of State : Every system modification is documented as an event (e.g., “order created,” “item added,” “order completed”) rather than just preserving the final state (e.g., “order is completed”). Every event denotes a distinct action or modification.
Store Events in Sequence : All events are stored in a sequence (often in a database or event store) in the exact order they occurred. This sequence of events acts as the "source of truth" for the system.
Reconstruct State by Replaying Events: When you need to know the current state, the system “replays” or processes all past events to build up the state from scratch.
Handle New Events: As new changes happen, new events are created and added to the sequence. For instance, if an order is updated, a new event (e.g., “order updated”) is added to the sequence without changing or removing past events.
Replay Events for Debugging: If you need to see the history or investigate an issue, you can replay events to see how the state evolved over time. This replay ability makes it easy to understand the sequence of actions taken and trace any errors or issues.

Example of Event Sourcing Pattern

Lets understand event sourcing pattern with the help of an example of registration system:

1. Registration System Before Event Sourcing

In a traditional event registration system, user registrations and cancellations are handled
using a direct approach where the state is updated immediately in the database. This can
lead to challenges such as difficulty in tracking changes, loss of historical data, and issues in
notifying users when their registration status changes.

Below is the traditional registration class in which there are several issues:

When users register or cancel their registrations, the system updates the database immediately without maintaining a history of actions.
The system does not record the reasons for registration changes, making it hard to audit past actions.
Notifications to users must be handled separately, leading to potential delays and errors in communication.

public class Registration {

private RegistrationState state;

private String userId;

private String eventId;

public void register(String userId, String eventId) {

this.state = RegistrationState.REGISTERED;

this.userId = userId;

this.eventId = eventId;

// Update the database directly

Database.update(this);

}

public void cancel() {

this.state = RegistrationState.CANCELLED;

// Update the database directly

Database.update(this);

}

In the above code, When a user registers or cancels, the state is directly updated in the
database, which may cause inconsistencies if issues arise during processing. Notifications to
users are not integrated with the registration process, which may lead to missing or delayed
alerts.

2. Registration System Using Event Sourcing

With the move to an event-sourced architecture, the system now records each significant
change as an event, allowing better tracking and historical analysis.

Instead of directly updating the database, the system processes commands to create and cancel registrations and generates events for each action.
Each state change is represented by an event, providing a clear audit trail of user actions.
Notifications are handled through event subscribers, ensuring users are promptly informed about their registration status changes.

Below is the event sourced registration class:

public class Registration extends
ReflectiveMutableCommandProcessingAggregate {

private RegistrationState state;

private String userId;

private String eventId;

public RegistrationState getState() {

return state;

}

public List process(RegisterForEventCommand cmd) {

return EventUtil.events(new EventRegisteredEvent(cmd.getUserId(), cmd.getEventId()));

}

public List process(CancelRegistrationCommand cmd) {

return EventUtil.events(new RegistrationCancelledEvent(userId, eventId));

}

public void apply(EventRegisteredEvent event) {

this.state = RegistrationState.REGISTERED;

this.userId = event.getUserId();

this.eventId = event.getEventId();

}

public void apply(RegistrationCancelledEvent event) {

this.state = RegistrationState.CANCELLED;

}

By transitioning to an event-sourced architecture, the event registration system gains a clear
advantage in tracking registration states, maintaining a complete history of actions, and
ensuring timely notifications to users.

Benefits of Event Sourcing Pattern

Event Sourcing offers several benefits in system design:

By recording all system modifications, Event Sourcing builds an unalterable record of all activities.
With event sourcing, you can replay events up to a certain point in time to query the system's current state.
Event sourcing encourages adaptability and system development over time. New event types can be created to address changes in business requirements without affecting current components.
Event Sourcing is a good fit for distributed systems and horizontal scaling as events can be individually consumed and processed by several components, enhancing scalability and speed.

Challenges with Event Sourcing Pattern

While Event Sourcing offers various benefits, it also presents several challenges:

Events may take on a different structure as the system develops. It becomes essential to manage event versioning and backward compatibility to guarantee seamless migrations and upgrades without erasing previous data.
It can be difficult to properly store and retrieve huge amounts of events, particularly in situations with high throughput or lengthy event histories. It becomes crucial to put in place efficient querying and event storing systems.
Various components of the system may see state changes at various times due to eventual consistency, which is usually the outcome of event sourcing. Handling stale data, resolving conflicts, and data synchronization all need careful thought when dealing with eventual consistency.

Use Cases and Applications of Event Sourcing

Event Sourcing finds applications in diverse domains and use cases where tracking and
analyzing historical data is crucial. Below are some notable examples:

Financial Systems: To keep an unchangeable record of transactions, account activity, and compliance events, banking and financial institutions use event sourcing.
Healthcare Records: Electronic health record (EHR) systems use event sourcing to document patient contacts, treatment histories, and medical procedures.
Supply Chain Management: Event sourcing is used in supply chain and logistics management to track inventory movements, shipping updates, and supply chain interruptions.
E-commerce Platforms: Event sourcing is a useful tool for e-commerce applications to record customer interactions, order fulfillment processes, and inventory changes. This makes it feasible to track orders, offer customized recommendations, and examine customer behavior in order to boost sales and customer satisfaction.
Gaming and Virtual Environments: Event Sourcing is used in virtual worlds and multiplayer online games to record player movements, game state changes, and in- game purchases.

Real-World Example of Event Sourcing Pattern

A real-world example of Event Sourcing can be seen in a modern banking system.

Consider a scenario where a bank wants to implement Event Sourcing for its account
management system.

Account Operations: The system creates related events whenever a consumer does an action that impacts their account, like making a deposit, taking money out of their account, moving money to another account, or changing personal data.
Event Logging: elevant details including the kind of operation, the amount involved, timestamps, and any additional metadata required to recreate the account's status are contained in each event.
Event Processing: These events are consumed by event handlers or processors, who then alter the status of the impacted accounts appropriately. For instance, the account balance is increased if a "Deposit" event is noted. The balance is reduced if a "Withdrawal" event is recorded.
Scalability and Resilience: Event Sourcing distributes event processing over several nodes, enabling the bank's system to scale horizontally. The system can recover by replaying events from the event storage to restore the status of accounts in the event of malfunctions or outages.

When to Use Event Sourcing Pattern

Use Event Sourcing Pattern when:

It's good for apps with complicated rules that need to keep track of how things change over time.
It helps when you need a complete history of changes for legal reasons or audits.
Useful for systems that need to save old data, like financial information.
Helps your app bounce back quickly from problems by replaying past events.
Works well in systems with separate parts (like microservices) that need to communicate without being tightly linked.

When not to Use Event Sourcing Pattern

Event Sourcing may not be the best choice in these situations:

Simple Applications : If an application just needs to track the most recent state and doesn't require a thorough history or audit trail, Event Sourcing may introduce needless complexity.
High Storage Costs : Event Sourcing stores every change as an event, which can lead to high storage costs, especially if there are frequent updates or changes.
Complex Data Consistency Needs : Managing consistency across multiple events can
become challenging, especially when coordinating data between different services or
systems.
Performance Sensitivity : Replaying events to rebuild the state can slow down
performance in applications where quick data retrieval is essential.

Conclusion

In conclusion, Event Sourcing is like keeping a detailed diary for your software. By recording
every change as a separate event, it provides an accurate and immutable record of all
actions taken within a system. This pattern offers benefits such as improved auditability,
scalability, and resilience. It enables accurate historical analysis, real-time tracking of system
state, and efficient troubleshooting.

OHA, IWU and IJI: The Three OHA, IWU and IJI: The Three Pillars of Governance in the OBINexus MMUCO Framework

Nnamdi Okpala — Thu, 24 Sep 2026 01:38:08 +0000

OHA, IWU and IJI: The Three Pillars of Governance in the OBINexus MMUCO Framework

Governance becomes dangerous when one institution is allowed to represent the people, interpret the law, enforce decisions, and judge its own actions.

The OBINexus MMUCO governance framework separates these responsibilities into three distinct pillars:

OHA — Community and Consent
IWU — Law and Rights
IJI — Order and Protection

Each pillar has its own role, responsibilities, and authority.

None of them is intended to rule alone.

The objective is a system in which community legitimacy, constitutional law, and public protection continuously check one another.

The basic relationship can be expressed simply:

OHA gives legitimacy.
IWU gives legality.
IJI provides protection.

Together, they form a governance structure designed around human rights, accountability, separation of powers, and community participation.

Pillar One: OHA — Community, Welfare and Consent

OHA is the civic and community pillar.

Its purpose is to represent the people who live within the community and ensure that governance remains connected to their everyday needs.

OHA asks:

What does the community need, and what has the community authorised?

OHA is therefore concerned with participation, welfare, resources, community services, infrastructure, representation, and consent.

The Role of OHA

The primary role of OHA is to provide organised community representation.

It creates a place where residents can participate in decisions affecting their homes, neighbourhoods, services, infrastructure, and shared resources.

OHA should ensure that governance does not become something merely imposed upon people.

Governance must remain connected to the people it exists to serve.

Responsibilities of OHA

OHA is responsible for areas such as:

community representation;
access to food;
access to water;
housing and shelter;
sanitation;
accessibility;
community infrastructure;
education and community development;
maintenance of shared facilities;
community welfare;
resource coordination;
grievances and complaints;
civic participation;
community meetings and assemblies.

OHA can also identify failures within the community.

For example, if a shared food service repeatedly fails to provide meals, OHA should be able to investigate the service failure, organise corrective action, and make sure the affected people are supported.

If the issue involves a legal or constitutional question, however, OHA refers the matter to IWU.

If there is an immediate threat to safety, OHA refers the matter to IJI.

Authority of OHA

OHA may have authority to:

organise community assemblies;
establish civic procedures;
coordinate community resources;
approve community projects;
oversee authorised community budgets;
appoint or elect community maintainers;
inspect community services;
record complaints;
establish local operating standards;
request legal review from IWU;
request emergency intervention from IJI.

But OHA cannot possess unlimited authority.

OHA should not arbitrarily imprison people, punish residents, confiscate property, override constitutional rights, or act as a police force or court.

Its authority is primarily:

civic, administrative, representative and stewardship-based.

A useful constitutional formula is:

OHA = Voice + Welfare + Stewardship + Consent

Pillar Two: IWU — Law, Rights and Due Process

IWU is the constitutional and legal pillar.

Its purpose is to protect rights and ensure that every institution operates within the law.

IWU asks:

Is this action lawful, fair and constitutionally permitted?

OHA may determine what a community wants.

IJI may need to act during an emergency.

But neither pillar should decide for itself whether its actions are legally unlimited.

That is where IWU becomes essential.

The Role of IWU

IWU interprets the constitutional framework.

It examines whether decisions made by OHA, IJI, administrators or other institutions are consistent with established rights, procedures and legal authority.

IWU therefore acts as a constitutional boundary around institutional power.

Responsibilities of IWU

IWU is responsible for:

protecting individual rights;
interpreting constitutional rules;
reviewing government or institutional decisions;
resolving legal disputes;
protecting due process;
examining evidence;
hearing complaints;
reviewing the legality of interventions;
resolving conflicts between institutions;
providing remedies when rights are violated;
preventing arbitrary exercises of authority.

Due process is particularly important.

A person should not simply be accused, judged and punished by the same authority.

There should be procedures.

These may include:

notification of the allegation or decision;
access to relevant evidence;
an opportunity to respond;
impartial consideration;
a reasoned decision;
access to review or appeal.

IWU provides the framework through which these protections can exist.

Authority of IWU

IWU may have authority to:

interpret constitutional provisions;
review OHA decisions;
review IJI interventions;
determine whether an institution exceeded its authority;
resolve legal disputes;
issue legal findings;
provide remedies;
protect due process;
invalidate actions that conflict with the constitutional framework;
require institutions to correct unlawful decisions.

However, IWU also has limits.

It should not manage everyday community services.

That belongs primarily to OHA.

It should not become the operational security force.

That belongs primarily to IJI.

And most importantly:

IWU is not above the constitution. IWU is bound by the constitution.

Otherwise, the institution responsible for interpreting law could itself become an unlimited authority.

A useful constitutional formula is:

IWU = Rights + Law + Due Process + Remedy

Pillar Three: IJI — Order, Safety and Protection

IJI is the operational protection and public-safety pillar.

Its responsibility begins where immediate danger begins.

IJI asks:

What lawful action is necessary right now to keep people safe?

Where OHA represents the community and IWU determines legal boundaries, IJI acts when there is an emergency, serious threat, violence, disorder or immediate danger.

The Role of IJI

The role of IJI is to maintain lawful public safety.

Its purpose is not domination.

Its purpose is protection.

IJI should be capable of responding when someone's safety, community infrastructure, or public order faces an immediate threat.

Responsibilities of IJI

IJI may be responsible for:

emergency response;
protection from immediate harm;
safeguarding;
lawful public-safety patrols;
evacuation;
securing dangerous areas;
protecting community infrastructure;
incident reporting;
emergency coordination;
preserving evidence;
supporting disaster response;
responding to serious threats to public safety.

IJI should also have preventative responsibilities.

Public safety should not begin only after somebody has already been harmed.

Emergency planning, safeguarding systems, training, communication procedures, and risk assessment can all form part of IJI's responsibility.

Authority of IJI

IJI may have authority to:

secure unsafe locations;
protect individuals facing immediate danger;
coordinate emergency evacuation;
restrict access to hazardous areas when legally authorised;
respond to urgent public-safety incidents;
preserve evidence;
execute lawful protective orders;
coordinate emergency services;
document interventions.

But IJI must never become an unlimited enforcement body.

It should not create laws.

It should not independently determine guilt.

It should not arbitrarily punish people.

It should not operate as a vigilante organisation.

It should not override OHA or IWU merely because it possesses operational capabilities.

Its authority must remain governed by principles such as:

necessity, proportionality, minimum intervention, accountability, documentation and respect for human rights.

A useful constitutional formula is:

IJI = Protection + Order + Response + Restraint

And one of its most important constitutional principles is:

IJI has operational authority, not unlimited authority.

The Three-Pillar Separation of Powers

The relationship between the three pillars can be summarised as follows:

Pillar	Primary Role	Core Responsibility	Authority
OHA	Community and representation	Welfare, participation, resources and consent	Civic and administrative authority
IWU	Law and constitutional rights	Due process, legal interpretation and remedies	Judicial and constitutional authority
IJI	Order and public protection	Safety, emergency response and lawful enforcement	Operational protective authority

Each pillar answers a different question.

OHA

What do the people need?

IWU

What does the law permit?

IJI

What must be done to keep people safe?

These questions should not collapse into one institution.

That separation is deliberate.

An Example of the Three Pillars Working Together

Imagine that a community food facility stops providing meals to several residents.

The first issue is a community-service failure.

OHA investigates.

OHA determines why the service has failed, restores access where possible, coordinates resources and records the complaint.

Now imagine that one resident claims they were deliberately excluded because of discrimination.

That raises a rights question.

IWU reviews the evidence, examines the relevant constitutional protections and determines whether a violation occurred.

Now imagine that during the dispute someone becomes violent and people inside the facility are in immediate danger.

That becomes an IJI matter.

IJI protects the people, secures the location and manages the immediate safety situation.

Afterward, IWU can review whether the intervention remained within lawful limits.

OHA can then organise community recovery and address the underlying service failure.

The three pillars have interacted without becoming the same institution.

Why Separation Matters

The strongest protection against abuse is not simply having good leaders.

It is designing institutions so that power has boundaries.

If OHA controlled everything, community popularity could potentially override individual rights.

If IWU controlled everything, legal institutions could become disconnected from everyday community needs.

If IJI controlled everything, operational power could overwhelm both democratic participation and legal protection.

The system therefore requires each pillar to remain powerful enough to perform its function while limited enough that it cannot absorb the others.

This produces a constitutional balance:

Community without law can become majority domination.

Law without community can become detached bureaucracy.

Protection without restraint can become coercion.

But when the three remain separated:

OHA provides community legitimacy.

IWU provides constitutional legitimacy.

IJI provides physical protection.

Human Rights as the Boundary

The three pillars exist beneath a more fundamental principle:

Human rights are not optional administrative benefits.

They establish the boundaries within which authority operates.

No pillar should be capable of simply suspending someone's fundamental protections because doing so is convenient.

OHA cannot vote away someone's fundamental rights.

IWU cannot interpret itself into unlimited authority.

IJI cannot use public safety as justification for unrestricted power.

Authority therefore flows through a chain:

Human Rights
↓
Constitution
↓
Defined Institutional Authority
↓
OHA / IWU / IJI
↓
Accountable Action

The constitution defines the powers.

The pillars exercise them.

The people retain rights throughout the process.

The Constitutional Triangle

The three pillars can therefore be represented as a constitutional triangle:

OHA — PEOPLE

Community, welfare, resources and consent.

IWU — LAW

Rights, due process, interpretation and remedy.

IJI — ORDER

Safety, protection, response and restraint.

None sits permanently above the others.

Instead, they operate within different domains of responsibility.

When properly separated, they create a system in which power must continuously justify itself.

OHA must justify its decisions to the community.

IWU must justify its interpretations through law and reason.

IJI must justify its interventions through necessity and lawful authority.

That creates accountability.

Conclusion

The OBINexus MMUCO three-pillar framework is ultimately about one question:

How can a society exercise authority without allowing authority to become absolute?

The answer is not to eliminate authority.

A functioning community requires organisation.

Rights require institutions capable of protecting them.

Emergencies require people capable of responding.

But those powers do not need to belong to the same institution.

That is why the framework separates:

OHA — Voice, Welfare, Stewardship and Consent

IWU — Rights, Law, Due Process and Remedy

IJI — Protection, Order, Response and Restraint

Together they create a governance architecture in which:

OHA listens.

IWU evaluates.

IJI protects.

And all three remain accountable to the constitutional framework and the human beings that framework exists to serve.

That is the foundation of the three-pillar model:

People. Law. Protection.

Not one above the others.

All three in balance.

Next read: OHA Reablement Act

Open Definition Dimensional Game Theory Glossary: Game Theory, AI

Nnamdi Okpala — Tue, 22 Sep 2026 19:28:12 +0000

Dimensional Game Theory (DGT) is an attempt to bring the mathematical ideas of game theory closer to real-world computational systems: robots, AI agents, autonomous vehicles, cybersecurity systems, and other machines that must observe changing environments and make decisions in real time.

Traditional game theory gives us an extremely powerful mathematical foundation. DGT is not intended to replace or dismiss that foundation. The idea is to build an additional computational layer around it so that strategies can respond to changing inputs, newly relevant dimensions, feedback, and uncertainty.

Game Theory

Game theory is the mathematics of situations where the result of your decision depends partly on what somebody else decides.

A game is commonly represented as:

$$
G=(N,A,u)
$$

Here, (N) represents the players, (A) represents the actions available to them, and (u) represents their utility or payoff functions.

A player is an entity capable of participating in the game. A player does not have to be a human. It could be a company, country, robot, AI agent, software process, vehicle, or another autonomous system.

An action is something a player can do at a particular point in the game. Moving a chess piece, changing a price, turning a robot, sending a message, or choosing a route can all be actions.

A strategy is more than one action. It describes how a player decides which actions to take under different circumstances.

Utility and Payoff

A payoff represents the result a player receives from an outcome.

A utility function is the mathematical function used to assign values to those outcomes:

$$
u_i(a_1,a_2,\ldots,a_n)
$$

You can think of utility as the system's mathematical answer to the question:

"How desirable is this outcome for this player?"

Utility does not necessarily mean money. For a robot, it might represent safety, travel time, battery consumption, or task completion. For an AI system, it might represent accuracy or some explicitly defined objective.

Nash Equilibrium

A Nash equilibrium is a strategy configuration where no player can improve their payoff simply by changing their own strategy while everybody else's strategy remains unchanged.

In everyday language, everyone has reached a position where changing alone does not make things better for them.

That does not necessarily mean the outcome is fair, equal, or ideal. It means the strategy configuration is stable under unilateral changes.

Zero-Sum Games

A zero-sum game is one where one player's gain corresponds to another player's loss.

For two players:

$$
u_1 + u_2 = 0
$$

If one player receives (+5), for example, the other receives (-5).

Zero-sum does not mean that the game necessarily ends in a tie. It means the total payoff balances to zero. A tie is a special case where the game's outcome gives neither player a net advantage according to the chosen payoff model.

A non-zero-sum game is different. Players can sometimes both benefit, both lose, or achieve outcomes that cannot simply be described as one person's gain being another person's loss.

Perfect and Imperfect Information

A perfect-information game is one where players can observe the complete relevant state of the game when making decisions. Chess is the classic example because both players can see every piece on the board.

An imperfect-information game contains hidden information. Poker is an obvious example because players cannot see every opponent's cards.

Real-world autonomous systems frequently operate with imperfect information. A robot may have incomplete sensor readings. An AI may not know another agent's intentions. A vehicle cannot perfectly know what every nearby driver will do next.

That uncertainty becomes important when moving from abstract games into cybernetic systems.

The Dimensional Game Theory Layer

In DGT, a strategic dimension is a separately identifiable axis of a strategic problem.

For example, a chess system might model:

$$
D={
D_{\text{attack}},
D_{\text{defense}},
D_{\text{offense}},
D_{\text{formation}}
}
$$

The important idea is that these dimensions describe different strategic problems.

The attack dimension asks questions about immediate threats and captures. The defense dimension concerns protection and threat prevention. Formation concerns how pieces are arranged and coordinate with each other. Other games or real-world systems can define entirely different dimensions.

A dimensional strategy is a strategy designed or evaluated specifically within one of those dimensions.

Strategic Vectors

Once several dimensions are active, strategy can be represented as a vector:

$$
S=[
s_{D_1},
s_{D_2},
s_{D_3},
\ldots,
s_{D_n}
]
$$

Instead of describing the entire state with one number, the system now has several strategically meaningful values.

Think about an audio mixer. There isn't simply "sound." You can independently reason about bass, mid-range, treble, volume, balance, and other properties.

DGT applies a similar idea to strategy.

Instead of treating an entire strategic situation as one undifferentiated state, we can reason about its dimensions separately while still combining them into an overall strategy.

Scalar-to-Vector Promotion

A scalar is essentially a single value.

Imagine a system begins with:

$$
voice=1
$$

That might simply mean voice communication is present.

But once voice communication becomes strategically important, "voice" may contain several meaningful properties:

D_{\text{voice}}

[
\text{intent},
\text{urgency},
\text{confidence},
\text{deception},
\text{identity}
]
$$

The original scalar has effectively been promoted into a dimension.

This is useful for real-world AI because something that initially appears insignificant can suddenly become strategically important.

Variadic Inputs

Variadic means that the number of inputs is not permanently fixed.

Real environments behave like this constantly. A robot might initially process camera and distance information. Later, GPS becomes available. Then another robot broadcasts information. Then weather changes. Then an obstacle appears.

The computational problem therefore changes while the system is operating.

A variadic DGT model allows:

$$
D(t)
$$

to change over time.

The relevant strategic dimensions at time (t_1) do not necessarily have to be identical to those at (t_2).

Cybernetics

Cybernetics is the study of control, communication, and feedback in systems.

The basic pattern is beautifully simple:

$$
\text{Observe}
\rightarrow
\text{Decide}
\rightarrow
\text{Act}
\rightarrow
\text{Observe Again}
$$

A thermostat is a tiny cybernetic system. It measures temperature, compares that measurement with a goal, changes the heating, observes the new temperature, and repeats.

A robot can perform a much richer version:

$$
\text{Sensors}
\rightarrow
\text{World Model}
\rightarrow
\text{Strategy}
\rightarrow
\text{Action}
\rightarrow
\text{New Sensor Data}
$$

This feedback loop is one of the reasons cybernetics is important to the real-time interpretation of Dimensional Game Theory.

The system doesn't merely calculate an answer once. It interacts with the world and recalculates as the world changes.

Sensors, Sensor Fusion, and World State

A sensor converts something about the physical environment into information a computer can process.

Cameras, microphones, accelerometers, GPS receivers, thermometers, LiDAR, proximity detectors, and pressure sensors are all examples.

Sensor fusion means combining information from multiple sensors to form a more reliable understanding of what is happening.

A robot might combine:

$$
\text{camera}
+
\text{LiDAR}
+
\text{GPS}
+
\text{IMU}
$$

to estimate its surroundings.

The resulting representation is often called a world state or world model.

DGT can then operate over that representation rather than over an isolated prompt or static input.

Actors, Observers, and Consumers

An actor is something capable of taking an action.

An observer receives or measures information about a system.

A consumer receives information produced by another component and uses it.

In a cybernetic architecture, these roles can interact continuously:

$$
Actor
\rightarrow
Environment
\rightarrow
Observer
\rightarrow
Consumer
\rightarrow
Decision
\rightarrow
Actor
$$

A single component may sometimes perform more than one of these roles.

DFA and NFA

A Deterministic Finite Automaton (DFA) is a state machine where a particular state and input determine exactly one next state.

Conceptually:

$$
(state,input)\rightarrow state'
$$

An NFA, or Non-deterministic Finite Automaton, allows the same state and input to correspond to several possible next states:

$$
(state,input)\rightarrow
{state'_1,state'_2,\ldots}
$$

That distinction becomes interesting when modeling real-world actors because the same observation does not always produce one guaranteed behavior.

A person, robot, AI agent, or organization can have several possible reactions to the same situation.

Directed Acyclic Graphs

A Directed Acyclic Graph, or DAG, is a collection of nodes connected by directed edges where you cannot follow the arrows and eventually return to where you started.

For example:

$$
A\rightarrow B\rightarrow C\rightarrow D
$$

could represent a decision pipeline.

Edges can also have costs:

$$
A\xrightarrow{5}B
$$

That cost could represent distance, energy, latency, financial expense, risk, or another measurable quantity.

For autonomous systems, the costs themselves can change as the world changes.

A road might normally have cost (5), for example, but traffic could temporarily make its effective cost (20). The system can then recalculate its path.

Functions and Function Composition

A function maps an input to an output:

$$
f:X\rightarrow Y
$$

If:

$$
G(x)=y
$$

and:

$$
F(y)=z
$$

then the functions can be composed:

$$
(F\circ G)(x)=F(G(x))
$$

In plain English: run (G), then give its result to (F).

Composition is important in complex systems because large behaviors can be constructed from smaller transformations.

Functors

In mathematics, particularly category theory, a functor is a structure-preserving mapping between categories.

The important phrase there is structure-preserving.

Within the broader DGT research vocabulary, a phenomenological functor can be used as a proposed abstraction for mapping an observed event into a semantic state while preserving relationships that matter to the system.

This is a more specialized concept than ordinary function composition and needs its own formal definition whenever it is used mathematically.

Coherence

Coherence asks whether the parts of a system remain meaningfully consistent with each other.

Suppose a robot's camera says an obstacle is directly ahead while its internal world model says that space is completely empty. Something is incoherent.

A coherence measure can therefore be thought of as a way of asking:

"How well do these representations agree?"

In a real-time architecture, loss of coherence can itself become a trigger for additional observation, recalculation, fault handling, or strategy changes.

Lossless and Lossy Mappings

A lossless transformation preserves the information needed to reconstruct or distinguish the original states.

A lossy transformation throws some information away.

Consider:

$$
f(x)=x^2
$$

Then:

$$
f(2)=4
$$

and:

$$
f(-2)=4
$$

Two distinct inputs have collapsed into the same output.

That leads directly to another useful term: injectivity.

An injective function preserves distinctness:

$$
x_1\neq x_2
\Rightarrow
f(x_1)\neq f(x_2)
$$

If a function is not injective, different inputs can become indistinguishable after transformation.

Axiom, Definition, Lemma, Theorem, Proof, and Corollary

These words have very specific roles in mathematical writing.

An axiom is an assumption accepted as a starting point within a formal system.

A definition establishes exactly what a term means.

A lemma is a proved result mainly used to help establish another result.

A theorem is a mathematical statement that has been demonstrated from accepted definitions, assumptions, and previous results.

A proof is the logical argument demonstrating that theorem.

A corollary is a result that follows relatively directly from a theorem.

A conjecture is different: it is a mathematical claim believed to be true but not yet proved.

That distinction matters enormously when developing DGT. An intuition can become a conjecture; a conjecture only becomes a theorem after a valid proof establishes it.

Minimax

Minimax is a fundamental idea in game theory.

Very roughly, a player chooses a strategy that gives the best result they can guarantee against the worst response available to their opponent.

For player one:

$$
\max_{s_1}\min_{s_2}u(s_1,s_2)
$$

It is essentially asking:

"What is the best outcome I can guarantee if my opponent responds as effectively as possible?"

The minimax theorem is one of the foundational results behind two-player zero-sum game theory.

Complexity

Computational complexity describes how the resources required by an algorithm grow as the problem becomes larger.

(O(1)) means the work stays roughly constant. (O(\log n)) grows very slowly as the input grows. (O(n)) grows roughly in proportion to the amount of input. (O(n^2)) grows quadratically.

This matters tremendously for real-time systems.

A mathematical strategy can be perfectly valid but still be practically useless for a robot if calculating it takes thirty minutes while the robot has thirty milliseconds to decide what to do.

That is why dimensional activation and pruning are interesting computational problems: instead of evaluating every imaginable variable continuously, the system can concentrate computation on dimensions that are currently relevant.

Black Boxes and Explainability

A black-box system produces outputs without exposing an easily understandable explanation of the internal reasoning that generated them.

Modern AI systems can display aspects of this problem. They can make useful predictions without providing a simple symbolic explanation equivalent to their internal computation.

Explainability is the effort to make decisions traceable.

A dimensional representation offers one possible architectural approach: rather than merely producing an action, a system might report something such as:

$$
D_{\text{collision-risk}}=0.81
$$

$$
D_{\text{route-efficiency}}=0.54
$$

$$
D_{\text{energy}}=0.72
$$

and therefore explain why one action was selected over another.

Autonomous Systems

An autonomous system can observe its environment, make decisions, and act without requiring a human to specify every individual action.

Robots, drones, autonomous vehicles, industrial controllers, software agents, and some cybersecurity systems can all be autonomous to different degrees.

For a cybernetic autonomous system, the loop becomes:

$$
\boxed{
\text{Sense}
\rightarrow
\text{Model}
\rightarrow
\text{Detect Dimensions}
\rightarrow
\text{Evaluate Strategies}
\rightarrow
\text{Act}
\rightarrow
\text{Measure Feedback}
\rightarrow
\text{Adapt}
}
$$

And that gets us to the central idea.

Dimensional Game Theory in One Paragraph

Dimensional Game Theory is a framework for representing strategy through meaningful, independently analyzable dimensions that can be activated, measured, combined, and adapted as the state of a real-world system changes.

The goal isn't to say classical game theory failed. Quite the opposite: classical game theory supplies the mathematical foundation.

The engineering question DGT asks is:

How do we take that foundation and make it computationally useful for machines that are sensing, acting, learning, and adapting inside a changing physical world?

That is where game theory meets AI, robotics, autonomous systems, and cybernetics.

How to Write a Windows App in Assembly Language

Nnamdi Okpala — Tue, 22 Sep 2026 18:42:02 +0000

How to Write a Windows App in Assembly Language

If you are learning low-level programming, operating systems, compilers, kernels, or calling conventions, this is a very useful exercise because it forces you to understand what normally happens underneath C or C++.

In this article, we will build a tiny 64-bit Windows GUI application in assembly using MASM and the Win32 API.

Our first application will simply display a Windows message box.

What We Are Building

The program will call the Windows function:

MessageBoxA(...)

from assembly.

Conceptually, the program looks like this:

Assembly Program
      |
      v
Windows x64 Calling Convention
      |
      v
Win32 API
      |
      +---- user32.dll
      |
      +---- kernel32.dll
      |
      v
Windows

The final executable will be a normal Windows .exe.

Tools We Need

For this tutorial, I recommend Microsoft's assembler:

MASM

More specifically, for 64-bit Windows:

ml64.exe

Install Visual Studio Build Tools and make sure you include:

Desktop development with C++
MSVC x64 build tools
Windows SDK

After installation, open:

x64 Native Tools Command Prompt for VS

This gives you access to tools such as:

ml64.exe
link.exe

Step 1: Create the Assembly File

Create a file called:

hello.asm

Add the following code:

option casemap:none

EXTERN MessageBoxA:PROC
EXTERN ExitProcess:PROC

.data

message db "Hello from Windows x64 Assembly!", 0
title   db "My Assembly App", 0

.code

main PROC

    ; Reserve shadow space and preserve stack alignment.
    sub rsp, 28h

    ; MessageBoxA(
    ;     HWND    hWnd,
    ;     LPCSTR  lpText,
    ;     LPCSTR  lpCaption,
    ;     UINT    uType
    ; )

    xor rcx, rcx
    lea rdx, message
    lea r8, title
    xor r9d, r9d

    call MessageBoxA

    ; ExitProcess(0)

    xor ecx, ecx
    call ExitProcess

main ENDP

END

This is already enough to create a Windows GUI program.

Understanding the Data Section

This part:

.data

message db "Hello from Windows x64 Assembly!", 0
title   db "My Assembly App", 0

creates two null-terminated strings.

The first string contains the message:

Hello from Windows x64 Assembly!

The second contains the title of our message box:

My Assembly App

The trailing 0 terminates each string because MessageBoxA expects C-style strings.

Calling Windows from Assembly

This is where things get interesting.

On 64-bit Windows, the first four integer or pointer arguments are passed through registers.

The Windows x64 calling convention uses:

Argument 1 -> RCX
Argument 2 -> RDX
Argument 3 -> R8
Argument 4 -> R9

So this C function call:

MessageBoxA(
    NULL,
    "Hello from Windows x64 Assembly!",
    "My Assembly App",
    0
);

becomes something like:

xor rcx, rcx
lea rdx, message
lea r8, title
xor r9d, r9d

call MessageBoxA

This is one of the most important things to understand when learning assembly.

A normal high-level function call eventually becomes operations involving registers, memory, the stack, and a machine-level call instruction.

Why `LEA` Is Used

You may notice this:

lea rdx, message

instead of:

mov rdx, message

MessageBoxA needs a pointer to the string.

LEA means:

Load Effective Address

So:

lea rdx, message

places the address of message into RDX.

Conceptually:

RDX -> address of message string

The Windows x64 Stack

Windows x64 also has another important rule.

Before calling a function, the caller reserves 32 bytes of shadow space.

This is sometimes also called:

home space

That is why the example contains:

sub rsp, 28h

The extra space also helps maintain the required stack alignment before making Windows API calls.

This becomes especially important when you begin writing larger assembly programs.

Step 2: Assemble the Program

Run:

ml64 /c hello.asm

MASM translates:

hello.asm

into:

hello.obj

The process looks like this:

hello.asm
    |
    v
Assembler
    |
    v
hello.obj

An .obj file is not yet an executable.

It contains machine code and metadata that the linker can combine with other libraries.

Step 3: Link the Program

Now run:

link hello.obj user32.lib kernel32.lib /SUBSYSTEM:WINDOWS /ENTRY:main /OUT:hello.exe

This produces:

hello.exe

We link against:

user32.lib
kernel32.lib

because our program uses functions provided by those Windows libraries.

MessageBoxA comes from:

user32.dll

and ExitProcess comes from:

kernel32.dll

The .lib files allow the linker to construct the necessary import information inside our executable.

Step 4: Run It

Run:

hello.exe

Windows should display a message box containing:

Hello from Windows x64 Assembly!

Congratulations.

You have now created a Windows GUI program without C, C++, C#, Python, or another high-level language.

The application talks directly to Windows through the Win32 API.

From Message Box to a Real Window

A message box is useful for learning, but a real Windows application normally has its own window.

The structure of a traditional Win32 GUI application looks approximately like this:

Program Start
     |
     v
GetModuleHandle
     |
     v
Register Window Class
     |
     v
CreateWindowEx
     |
     v
ShowWindow
     |
     v
Message Loop
     |
     +---- GetMessage
     |
     +---- TranslateMessage
     |
     +---- DispatchMessage
                 |
                 v
              WndProc
                 |
                 +---- WM_CREATE
                 |
                 +---- WM_PAINT
                 |
                 +---- WM_KEYDOWN
                 |
                 +---- WM_MOUSEMOVE
                 |
                 +---- WM_DESTROY

The central concept is the message loop.

Windows applications are usually event driven.

Your program waits for Windows to send events such as:

mouse movement
keyboard input
window resize
paint request
button click
window close

Each event is represented by a Windows message.

A Typical Message Loop

In C, you might see:

while (GetMessage(&msg, NULL, 0, 0)) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

In assembly, you manually place those function arguments into the correct registers and call the Win32 functions.

That is where assembly programming becomes extremely educational.

You can see exactly what a high-level language normally hides.

Understanding the Windows ABI

One of the biggest lessons from Windows assembly programming is understanding the ABI.

ABI means:

Application Binary Interface

It defines rules such as:

where function arguments go
which registers a function must preserve
where return values are stored
how the stack is aligned
how functions call each other

For Windows x64, remember:

RCX = argument 1
RDX = argument 2
R8  = argument 3
R9  = argument 4

Additional arguments are normally passed using the stack.

The return value is usually placed in:

RAX

So conceptually:

mov rcx, argument1
mov rdx, argument2
mov r8,  argument3
mov r9,  argument4

call MyFunction

corresponds to something like:

MyFunction(
    argument1,
    argument2,
    argument3,
    argument4
);

Once this becomes familiar, reading compiler-generated assembly becomes much easier.

Assembly Is Not Isolated From the Operating System

One misconception about assembly is that everything must be implemented manually.

That is not necessarily true.

Your assembly program can still call operating-system libraries.

For example:

Assembly
   |
   +---- Windows API
   |
   +---- DLLs
   |
   +---- Graphics
   |
   +---- Files
   |
   +---- Networking
   |
   +---- Threads
   |
   +---- Memory management

Assembly controls how you interact with these interfaces.

You could therefore build:

graphical applications
command-line utilities
DLLs
debuggers
emulators
development tools
system utilities
graphics demos
networking tools
experimental runtimes

entirely in assembly if you wanted to.

Windows Executables and the PE Format

When the linker creates:

hello.exe

it normally creates a Windows PE executable.

PE means:

Portable Executable

The PE format contains things such as:

PE Header
|
+-- Machine Code
|
+-- Data
|
+-- Import Table
|
+-- Export Table
|
+-- Relocations
|
+-- Resources

Our program's import table tells Windows that the executable needs functions such as:

MessageBoxA
ExitProcess

When Windows loads the program, the loader resolves these imports.

Understanding this process is extremely useful if you are studying operating systems or building your own low-level runtime.

A Good Learning Path

Do not try to build an enormous GUI application immediately.

Build progressively.

A useful progression is:

1. MessageBox
        |
        v
2. Console output
        |
        v
3. Basic Win32 window
        |
        v
4. Window message loop
        |
        v
5. Keyboard and mouse input
        |
        v
6. Buttons and controls
        |
        v
7. GDI graphics
        |
        v
8. File I/O
        |
        v
9. Threads
        |
        v
10. DLLs
        |
        v
11. Custom runtime

At every step, you learn more about how Windows actually works underneath higher-level programming languages.

Why Learn This?

You probably would not write every modern Windows application entirely in assembly.

But learning to build one is extremely valuable.

It teaches you about:

CPU registers
      +
stack frames
      +
calling conventions
      +
ABI rules
      +
assemblers
      +
object files
      +
linkers
      +
DLL loading
      +
operating-system APIs
      +
executable formats

Those ideas connect directly to areas such as:

operating-system development
compiler development
kernel development
reverse engineering
debugging
emulation
virtual machines
runtime development
systems programming

Once you understand assembly at this level, C stops looking quite so mysterious.

You start seeing what the compiler is actually doing for you.

Final Thoughts

Writing a Windows application in assembly sounds intimidating, but the first step can be surprisingly small.

At its core, our program simply does this:

prepare arguments
      |
      v
call Windows function
      |
      v
receive result

Assembly just exposes all of the machinery normally hidden behind a high-level language.

Start with:

MessageBox

Then build a window.

Then build a message loop.

Then add graphics, keyboard input, files, and eventually your own abstractions.

That journey takes you from simply using Windows APIs to understanding how programs actually communicate with an operating system.

And that is where assembly becomes really interesting.

Calling Conventions as Structural Contracts

Nnamdi Okpala — Tue, 22 Sep 2026 02:40:26 +0000

Calling Conventions as Structural Contracts

At the machine level, computation is not only about values. It is also about where values are placed, in what order they are placed, and how they are recovered.

A calling convention is therefore more than a rule for calling a function. It is a contract describing how two pieces of code agree on the shape of an interaction.

Consider a stack.

A stack is a last-in, first-out (LIFO) data structure. Values are pushed onto the top of the stack, and the most recently pushed value is the first value popped from it.

Conceptually:

push A
push B
push C

Stack:

TOP
 C
 B
 A

Popping produces:

C → B → A

This ordering matters when a calling convention uses the stack for function arguments.

For example, consider:

f(A, B, C);

Under a traditional 32-bit x86 convention such as cdecl, arguments are commonly pushed from right to left:

push C
push B
push A
call f

The call instruction also places the return address on the stack. The called function then interprets the resulting stack layout according to the agreed calling convention.

The important principle is not that arguments must always be reversed. That behaviour is specific to particular ABIs and architectures. The deeper principle is:

The representation used to transfer information must agree with the structure used to retrieve it.

Modern architectures demonstrate this clearly. On x86-64, many function arguments are passed through registers rather than being pushed individually onto the stack. The calling convention still exists, but its structural rules are different.

Different Structures Imply Different Access Rules

A queue has a different structure from a stack.

A queue is first-in, first-out (FIFO):

enqueue A
enqueue B
enqueue C

FRONT → A → B → C ← REAR

Dequeueing produces:

A → B → C

Trying to treat a queue according to stack semantics would change the meaning of the data.

A linked list introduces another structure:

A → B → C → NULL

Here, traversal depends on pointers linking one element to the next.

A tree introduces branching:

Traversal can now take several forms—pre-order, in-order, post-order, breadth-first, and so on.

A priority queue adds another rule: elements are retrieved according to priority rather than simply insertion order. It is often implemented using a binary heap.

For a min-heap:

the smallest element has the highest retrieval priority.

For a max-heap, the ordering is reversed and the largest element occupies the root.

These examples demonstrate that the shape of the structure affects the legal operations performed on it.

The Pointer as a Cursor Through Structure

At the machine level, a pointer can be understood as a cursor identifying a location in memory.

The pointer itself does not know whether the memory represents:

a stack,
a queue,
a linked list,
a tree,
an array,
a heap,
a function frame,
or some higher-level object.

That interpretation is supplied by the program.

This distinction becomes especially important when C communicates with assembly.

C may express:

result = function(a, b, c);

but the assembly implementation must know exactly where a, b, and c will appear according to the platform ABI.

The assembly routine cannot merely know the values. It must know their layout.

Therefore an assembly interface must define at least:

argument locations
argument ordering
register ownership
stack alignment
return-value location
return-address handling
preserved registers
temporary registers

These rules form the boundary between two computational environments.

Shape Is Part of Meaning

This leads to a useful systems principle:

Data has both value and structure.

The sequence:

A B C

does not mean the same thing under every organization.

As a stack:

C
B
A

determines the next removal as C.

As a queue:

A → B → C

determines the next removal as A.

As a tree, the same three values could instead express a parent-child relationship.

Therefore, when implementing MMUKO components in assembly and exposing them to C, the system should not treat calling conventions as arbitrary plumbing. They should be documented as structural contracts.

The caller constructs a machine state.

The callee interprets that machine state.

Correct execution occurs when both sides agree on the structure.

MMUKO Interpretation

For MMUKO, this principle can extend beyond ordinary function calls.

The system can explicitly describe computational structures in terms of:

shape
orientation
entry point
exit point
ordering
direction of traversal
ownership
transition rules

A stack, queue, ring, tree, or cubit structure can then be treated as a particular computational topology.

This does not mean that a calling convention is literally equivalent to a stack, queue, or heap. Rather:

A calling convention defines how a computational topology is crossed at an interface boundary.

That gives MMUKO a precise foundation for connecting its C and assembly components without making assumptions about the underlying structure.

At the lowest level, the question is not merely:

“What value did we pass?”

It is also:

“What structure did we place that value into, where is the cursor now, and by what rule will the next component retrieve it?”

Returning Home to Nigeria: Housing, Human Rights, and Building Systems That Let People Live

Nnamdi Okpala — Tue, 22 Sep 2026 01:06:07 +0000

For many Nigerians who leave the country for education, returning home raises a question that is more fundamental than employment:

Where am I supposed to live when I return?

I have been thinking about this question as I prepare for my own return to Nigeria after education abroad.

Housing should not be treated merely as property.

Housing is where a person sleeps.

It is where they recover.

It is where they study, build, create, raise families, regulate themselves, work, and participate in their community.

Without a stable place to live, practically every other human right becomes harder to exercise.

A Nigerian Citizen Has the Right to Come Home

The starting point is straightforward.

Section 41 of the Constitution of the Federal Republic of Nigeria provides that Nigerian citizens are entitled to move freely throughout Nigeria and reside in any part of the country. It also states that a Nigerian citizen cannot simply be refused entry into Nigeria.

For somebody returning after studying overseas, that matters.

Education abroad does not erase your relationship with your country.

Returning home is not asking another country for permission to exist.

It is returning to the state of which you are a citizen.

But the next question is harder.

Does Returning Give You an Automatic House?

No.

There is an important distinction between a right connected with housing and an automatic entitlement to receive a government-owned house.

Nigeria's Constitution says in Section 16(2)(d) that state policy should be directed toward ensuring, among other things:

suitable and adequate shelter

alongside adequate food, a reasonable minimum living wage and forms of social welfare.

That is a powerful constitutional statement.

But it does not mean that every citizen arriving at an airport can demand that the government immediately hand them the keys to a house.

Nigeria therefore has a gap familiar to many countries:

the difference between recognising human needs in constitutional policy and successfully delivering those needs in everyday life.

That gap is where systems have to be built.

Housing Is Infrastructure for Human Dignity

I think software engineers should pay attention to this problem.

We normally think about infrastructure as:

servers
databases
networks
roads
electricity
water

But a human being also has infrastructure requirements.

Human
 ├── Food
 ├── Water
 ├── Shelter
 ├── Safety
 ├── Healthcare
 ├── Education
 ├── Community
 └── Autonomy

Remove enough of those dependencies and the human system begins to fail.

That observation is especially important when designing systems for disabled and neurodivergent people.

A person's needs do not disappear because a bureaucracy failed to process them.

A person still needs somewhere to sleep.

They still need food.

They still need water.

They still need safety.

That idea has become part of the philosophy behind OBINexus.

The Legislation Written Through Obi

Alongside my computing work, I have been developing an experimental constitutional and human-rights framework in the OBINexus legislation repository.

Within the framework, Obi represents the heart, soul and connection layer of the wider Obi Nexus model.

The legislation repository describes itself as work on:

civil-collapse mitigation;
human-rights defence;
neurodivergent-first governance;
constitutional computing;
housing and support;
public accountability;
evidence and appeals.

It is important to distinguish this clearly from Nigerian statutory law.

OBINexus legislation is a proposed research and governance framework. It is not legislation enacted by Nigeria's National Assembly.

Its purpose is to ask a different engineering question:

What should a system guarantee before it starts demanding productivity from the human being inside it?

One of its central principles is:

BREATHING IS NOT OPTIONAL
LIVING IS NOT OPTIONAL
WORK IS OPTIONAL

That does not mean work has no value.

It means survival cannot logically depend on a person continuously proving their economic usefulness.

The system must preserve the person before optimising the person's output.

That is the principle I associate with Obi: heart, soul and connection.

The framework is publicly developed through the OBINexus legislation project on GitHub.

Neurodivergence Makes Housing Design More Than a Numbers Problem

Building one million houses does not automatically create one million accessible homes.

A housing system also has to ask:

Is the environment sensory-safe?
Is there enough personal space?
Can someone live independently while receiving support?
Is the design understandable?
Can routines remain predictable?
Can somebody move between private and communal space?
Is the person treated with dignity rather than merely contained?

This is where architecture and software engineering unexpectedly begin to resemble one another.

Bad software says:

USER MUST ADAPT TO SYSTEM

Good software increasingly says:

SYSTEM SHOULD ADAPT TO USER

Housing can follow the same principle.

A neurodivergent person should not have to become another person simply to fit inside their home.

Nigeria Already Has Housing Mechanisms

Nigeria is not starting from zero.

The Federal Ministry of Housing and Urban Development currently coordinates several housing and financing institutions.

Its 2026 housing framework identifies mechanisms including the Federal Mortgage Bank of Nigeria, the Federal Housing Authority, the Nigeria Mortgage Refinance Company and Family Homes Funds. The ministry describes options including affordable mortgages and rent-to-own arrangements.

That is important because the practical answer for a returning Nigerian may therefore involve several pathways rather than one universal government allocation.

A returnee might use:

RETURN TO NIGERIA
        │
        ▼
TEMPORARY HOUSING
        │
        ▼
STABLE INCOME / SUPPORT
        │
        ├── Family or community housing
        ├── Private rental
        ├── Rent-to-own
        ├── Mortgage
        ├── Affordable housing scheme
        └── Supported/community housing

What I would like to see developed further is a return pathway where Nigerians coming home after education, migration or long periods abroad can understand those options through one accessible system.

From Rights on Paper to Verifiable Delivery

This is also where my computing work intersects with legislation.

A right that cannot be verified can become a promise that disappears inside bureaucracy.

Imagine a housing-support system where a citizen could see:

APPLICATION RECEIVED      ✓
IDENTITY VERIFIED         ✓
HOUSING NEED ASSESSED     ✓
ACCESSIBILITY NEEDS       ✓
AVAILABLE OPTIONS         ✓
DECISION                  ✓
REASON FOR DECISION       ✓
APPEAL ROUTE              ✓

Instead of:

"We are looking into it."

followed by six months of silence.

Government technology should make institutional responsibility easier to verify, not easier to hide.

Returning Home Should Be a Beginning

When somebody returns to Nigeria after education, the question should not simply be:

What job will you do?

We should also ask:

Where will you live?

How will you establish yourself?

What will allow you to contribute?

What infrastructure does the person need in order to flourish?

Education produces knowledge.

Housing gives that knowledge somewhere to stand.

My broader OBINexus argument is therefore simple:

PERSON
  ↓
STABILITY
  ↓
AUTONOMY
  ↓
EDUCATION + WORK + CREATION
  ↓
COMMUNITY CONTRIBUTION

Trying to reverse that dependency produces fragile societies:

WORK FIRST
  ↓
PROVE YOUR WORTH
  ↓
MAYBE RECEIVE STABILITY

A human-first system should begin with survival, dignity and participation.

Conclusion

As a Nigerian returning home, I have the constitutional right to enter my country and reside there. That does not automatically translate into receiving a free government house.

But Nigeria's Constitution explicitly identifies suitable and adequate shelter as an objective of state policy.

The engineering problem is therefore not merely whether housing matters.

We already know that it does.

The challenge is turning that principle into infrastructure that people can actually access.

That is also why the legislation written through Obi / Obi Nexus matters to my work.

It treats housing, food, support, accessibility and human dignity not as afterthoughts but as dependencies of a functioning human system.

Technology alone cannot create human rights.

Legislation alone cannot construct a home.

Architecture alone cannot guarantee dignity.

But when governance, engineering, architecture and human experience work together, we can build systems where people are not merely breathing.

They can actually live.

When systems fail, build your OWN.

This article discusses constitutional principles and an experimental OBINexus governance framework. It is not legal advice, and the OBINexus legislation repository should not be confused with legislation enacted by the Federal Republic of Nigeria.

References

Constitution of the Federal Republic of Nigeria — Sections 16 and 41.
Federal Ministry of Housing and Urban Development — federal housing delivery and financing framework.
OBINexus legislation repository — Ontological Polarity Civil Collapse Mitigation for Sustainable Constitutional Governance.

Return of the Riches, Riches of the Return

Nnamdi Okpala — Sun, 20 Sep 2026 18:16:46 +0000

An Autobiographical Sketch of Nnamdi Michael Okpala

My name is Nnamdi Michael Okpala. I am Nigerian, from Anambra State, and although I have spent part of my life in the United Kingdom, I have never stopped thinking of Nigeria as home.

There is a difference between living somewhere and belonging somewhere. The United Kingdom has been where I studied and where I built part of my life, but Nigeria is the place that lives inside me. I think about the land itself. I remember the soil, the heat, and the golden sand. I remember making sand angels—not snow angels, but sand angels, pressing myself into the earth beneath the Nigerian sun.

Those memories might sound small to somebody else. To me, they are not small at all.

I think about how fertile the land can be, how quickly something planted can become something living. That image has stayed with me: soil becoming food, land sustaining people, the earth giving something back. Sometimes I have described my relationship to Nigeria in intense ways, imagining that even after death I would want to become part of that soil. Beneath those words is something simple: I want to belong to the land that produced me.

Living in Britain has gradually made that feeling stronger.

At times I have felt stuck here. I came to study, but eventually I found myself asking what I was still doing in the United Kingdom. I have a house here and things I have built here, yet possessions do not automatically create belonging. I have experienced difficult periods in Britain, including experiences I describe as abuse and years of my life that I feel were taken from me. There came a point when I began thinking, I have had enough. I want to go home.

I do not think of myself as British simply because I have lived in Britain. When people describe me that way, something in me immediately pushes back.

I am Nigerian.

I am Igbo.

My roots are in Anambra.

And I want to reconnect with them.

That desire led me to something surprisingly ordinary: looking for people to talk to.

I began creating an account on InterPals because I wanted Nigerian pen pals. I wanted conversations with people at home and with Nigerians in the diaspora. I searched for people from Nigeria and Anambra and looked for Igbo speakers. It felt slightly ridiculous that a person could feel so deeply connected to a country and still find himself staring at filters on a website trying to select “Nigeria,” “Anambra,” “Igbo,” and “friendship.” Human civilisation has apparently advanced all the way to drop-down menus.

But it mattered to me.

I wanted real conversation.

One of the people I met was Charles, whose Igbo name is Ikechukwu. We began talking about where we came from. He told me he was born in Onitsha and had connections in Anambra State. I told him about myself. We exchanged pieces of Igbo.

Aha m bụ Nnamdi Michael Okpala.

My name is Nnamdi Michael Okpala.

Even something as simple as speaking Igbo with another person felt meaningful. It was a reminder that language is more than vocabulary. A language carries jokes, childhoods, families, villages, names, memories, and ways of seeing the world.

I began telling people that I wanted to return to Nigeria. Sometimes I simply said that I was stuck in the United Kingdom and had come here to study. I told Charles that I needed to get back because I had people who cared about me.

That sentence captured more than I realised.

I wanted community.

I wanted home.

I wanted to stop feeling as though my real life was somewhere else waiting for me to return to it.

At the same time, reconnecting with people online forced me to think carefully about trust.

Conversations about travel quickly become conversations about money. Coming to Britain can involve passports, visas, education, work, accommodation and fees. I spoke with people who wanted opportunities abroad, and I understood why. Life in Nigeria can be difficult.

But I also learned to set boundaries.

I do not want friendships based on sending money. In the past, I lent £250 to someone I considered a friend and was not repaid. That experience stayed with me. It made me more cautious about people asking me for financial help.

I can care about somebody without becoming their bank.

I can want somebody to succeed without paying for their life.

I can be somebody's friend without having to prove that friendship through money.

That distinction became important as I started meeting more people online. I wanted relationships based on conversation, culture, ideas and mutual respect rather than transactions.

My ambitions go beyond simply returning home.

I call one of my ideas “Return of the Riches.”

To me, returning should not mean simply arriving at an airport with luggage and saying that I am home. I want to return with knowledge, skills, ideas and resources that can be useful.

I think about food.

I think about water.

I think about shelter.

I think about technology.

I think about what I have learned through STEM, computing and building software. I have worked on computer programs and online projects. I have spoken about my OBINexus and Orion ideas and about creating systems that could eventually become something larger than myself.

I want whatever I build to mean something.

I do not want achievement merely so I can point at a screen and say, Look what I made.

I want creation to become contribution.

That is what “Return of the Riches” means to me: taking whatever knowledge, experience or resources I have gained and asking how they can travel back with me.

My thoughts about Biafra are also connected to this sense of identity and responsibility. At times my language about Biafra, conflict and sacrifice has been extremely intense. I have spoken about warfare, history, weapons, dying for the land and becoming part of its soil.

Those words reflect how strongly I can feel about history, belonging and injustice. But beneath the imagery of war is another question that matters more to the life I actually want to build:

What can I create for my people while I am alive?

Food is more useful when people can eat it.

Water matters when people can drink it.

Shelter matters when families can live beneath it.

Technology matters when it makes somebody's life better.

A country is not only its wars. It is also the conversations between strangers, the names parents give their children, the languages spoken in homes, the businesses people create, the farms people cultivate and the friendships people build.

My return, therefore, cannot merely be about what I oppose.

It has to be about what I build.

I am still working out exactly what returning to Nigeria will look like.

I have talked about packing my belongings and sending things through a port. I have imagined returning around the end of the year. I have thought about what I would leave behind in Britain and what I would carry with me.

Some questions remain unresolved.

Where exactly will I settle?

What will I build first?

How will my projects develop?

Which friendships will survive beyond an online chat window?

I do not yet have every answer.

But I know what keeps pulling me back.

The soil.

The language.

The names.

The people.

The feeling of being somewhere and knowing that the land beneath my feet is connected to the story I tell about myself.

I am Nnamdi Michael Okpala.

I have lived in the United Kingdom, studied, struggled, created things, met people, lost trust in some people and tried to rebuild it with others. I have spent nights online looking for Nigerians simply because I wanted somebody from home to speak to.

And somewhere beneath all the complicated plans, technical frameworks, arguments about visas, online conversations and enormous ideas is a much simpler image:

golden Nigerian soil,

a person lying down in it,

arms and legs moving across the sand,

making an angel in the earth,

and remembering where he belongs.

The Polyglot Bridge: Mastering Cross-Language Calls with LibPolyCall

Nnamdi Okpala — Sun, 20 Sep 2026 14:23:02 +0000

The Polyglot Bridge: Mastering Cross-Language Calls with LibPolyCall

By Obi (Obinexus) | @obinexus

Hello everyone, welcome back! I'm Obi from the Obi Nexus computing team.

Today, I want to introduce a tool that is a massive milestone in API development and legacy modernization: LibPolyCall.

If you've ever tried to integrate a legacy C++ rendering engine with a modern Python microservice, you know the pain. You end up writing custom ctypes, FFI bindings, or brittle glue code for every single language pair. LibPolyCall solves this by acting as a "program-first" polyglot runtime broker. It provides a stable C ABI that eliminates language barriers.

But getting started with a new architecture can be tricky. In this tutorial, I'm going to walk you through exactly how to set up LibPolyCall, navigate its port architecture, and successfully execute a polyglot call.

🏗️ Understanding the Architecture

Before writing code, we need to understand the LibPolyCall topology. It operates on a zero-trust, broker-based model:

polycall.exe (The Runtime/Broker): This is the central bouncer. It doesn't run your code; it routes requests between language adapters.
Polycallfile (The Map): A configuration file that tells the runtime what language servers exist and what ports they should use.
Language Adapters (The Bindings): Thin client libraries (like pypolycall) that connect your actual Python, Node, or C++ logic to the runtime.
The CLI (The Admin): The command-line interface used to start the runtime and execute one-off calls.

🚨 The #1 Gotcha: The Ports

When you start the runtime using polycall.exe --config .\Polycallfile start, it will output something like:
polycall start: listening on 127.0.0.1:56862

Do not confuse this with your language server ports!

Port 56862 (or similar): This is the CLI Control Port. It is used only for administrative commands (start, stop, call).
Port 8084 (from your Polycallfile): This is the Runtime Adapter Port. Your Python and C++ scripts will connect to this port to register their logic with the broker.

If you try to make a CLI call pointing to 8084, it will fail. The CLI must always target the control port.

🐍 Step 1: The Python Adapter

The pypolycall binding is an adapter, not a server framework. Its job is to connect to the runtime, authenticate, and execute operations.

Create a file named python_service.py:

import asyncio
from pypolycall.core import ProtocolBinding

async def main():
    # Initialize the binding to connect to the polycall.exe runtime.
    # Note: We use port 8084 here (the Adapter Port), NOT the CLI control port.
    binding = ProtocolBinding(
        polycall_host="localhost",
        polycall_port=8084
    )

    try:
        # 1. Connect to the runtime
        await binding.connect()
        print("✓ Connected to polycall.exe runtime on port 8084")

        # 2. Authenticate (Zero-trust is mandatory)
        await binding.authenticate({
            "username": "developer",
            "api_key": "dev-key",
            "scope": "binding-access"
        })
        print("✓ Authentication successful")

        # 3. Execute an operation
        # Operations use the namespace convention: language.function_name
        result = await binding.execute_operation(
            "python.hello_world",
            {"name": "Nnamdi"}
        )
        print(f"✓ Result: {result}")

    except Exception as e:
        print(f"Protocol error: {e}")
    finally:
        await binding.shutdown()

if __name__ == "__main__":
    asyncio.run(main())

Note: Don't make the mistake I did by trying to use register_handler or register_operation. Those methods don't exist. The binding uses execute_operation to invoke logic that the runtime already knows about.

Running the Setup

Open Terminal 1 (The Runtime):

.\polycall.exe --config .\Polycallfile start
# Output: polycall start: listening on 127.0.0.1:56862 (Ctrl-C to stop)

Open Terminal 2 (The Python Adapter):

python python_service.py
# Output: 
# ✓ Connected to polycall.exe runtime on port 8084
# ✓ Authentication successful
# ✓ Result: {'status': 'success', 'operation': 'python.hello_world', 'params': {'name': 'Nnamdi'}}

You have just successfully executed a polyglot operation through the LibPolyCall broker!

🚀 Step 2: The Ultimate Goal - Bridging to C++

Now that you understand the adapter pattern, you can achieve the true goal: Modern Python calling Legacy C++.

Write the C++ Adapter (cpp_service.cpp):
You would compile a C++ program using the obinexus C++ binding headers. It will connect to the runtime on port 8084 (just like Python did) and register the cpp.render_frame operation.

Execute the Call:
Once your C++ adapter is running and authenticated, you can use the CLI in Terminal 3 to call it:

.\polycall.exe call cpp render_frame --endpoint localhost:56862 --input-value '{\"width\":1920,\"height\":1080}' --format json

Or call it from Python:
Simply change your Python script to result = await binding.execute_operation("cpp.render_frame", {"width": 1920, "height": 1080}).

🏁 Conclusion

LibPolyCall solves the "API development nightmare" by decoupling your business logic from the language it's written in. It doesn't care if you're passing data from Python to Node, or Python to Legacy COBOL. It just gives you the data seamlessly.

The runtime handles the security, the telemetry, and the routing. You just write your bindings.

Get Started:

GitHub: github.com/obinexus/libpolycall
PyPolyCall: github.com/obinexus/pypolycall

If you're building with LibPolyCall, let me know in the comments!

Like, share, and subscribe. May the power of polycall be with you! 🚀

Building a Thread-Safe HTTP Server in Python with in depth analysis exploring the exploit.

Nnamdi Okpala — Mon, 14 Sep 2026 12:40:04 +0000

Building a Thread-Safe HTTP Server in Python with in depth analysis exploring the exploit.

Python is a great language for building servers, especially for quick projects and prototyping.

However, one common challenge that arises when dealing with servers is thread safety. If you're building a web server that can handle multiple users at once, you need to make sure it's thread-safe—that is, able to handle multiple operations concurrently without crashing or exposing security vulnerabilities.

In this tutorial, we'll explore what thread safety means, dive into Python's threading system, and then build a simple threaded HTTP server that can serve multiple clients simultaneously. Let's break it down for beginners so you can follow along even if you're new to threading.

What is Thread Safety?

Thread safety means that your program works correctly even when multiple threads (small units of a program) are running at the same time. When multiple threads are modifying the same data or resource, there's a risk that they will interfere with each other and cause bugs, crashes, or security issues.

Imagine a bank with several ATMs. If two customers try to withdraw money at the same time and the system isn't careful about keeping track of each transaction, one person might take out more money than they should, or data might get corrupted.

In programming, this kind of problem happens when multiple threads access shared data or resources without proper coordination. A thread-safe program avoids these problems by making sure that threads don't interfere with each other in ways that can lead to bugs.

What is a Thread?

A thread is a smaller unit of a process that can run independently. Think of a process as a program running on your computer, and a thread as a single task within that program. Many programs use multiple threads to handle different tasks at the same time. For example, your web browser might download files in one thread while displaying a webpage in another.

In Python, threading allows your program to run multiple tasks at the same time. This can make your server more efficient, as it can handle multiple client requests concurrently without waiting for one to finish before starting another.

Now, let's build a simple threaded HTTP server to illustrate how threading works and how you can handle requests concurrently.

Building a Threaded HTTP Server in Python

We'll start by using Python's built-in http.server module and extend it with threading to make it more efficient. By making the server thread-safe, we allow it to handle multiple requests simultaneously, meaning it can serve multiple clients at once.

Here's the basic code to get started:

1. Basic HTTP Server

from http.server import BaseHTTPRequestHandler, HTTPServer


# Define the HTTP request handler class
class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
    # Override the do_GET method to handle GET requests
    def do_GET(self):
        # Set the response status code
        self.send_response(200)

        # Set the response headers
        self.send_header('Content-type', 'text/html')
        self.end_headers()

        # Write the response content
        self.wfile.write(b"Hello, world!")


# Main function to run the server
def main():
    # Define the server address and port
    server_address = ('', 8000)

    # Create an instance of the HTTP server
    httpd = HTTPServer(server_address, SimpleHTTPRequestHandler)
    print("Server started on port 8000…")

    # Start serving HTTP requests
    httpd.serve_forever()


if __name__ == '__main__':
    main()

In this basic version, the server can only handle one request at a time. If two users try to access it simultaneously, one will have to wait until the other's request is complete. This isn't efficient for real-world use, especially with multiple users.

2. Introducing Threading

To allow our server to handle multiple requests simultaneously, we can introduce threading. Python's socketserver module has a ThreadingMixIn class that makes it easy to create a multi-threaded server.

Here's the updated version:

import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
from socketserver import ThreadingMixIn


# Define the HTTP request handler class
class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
    # Override the do_GET method to handle GET requests
    def do_GET(self):
        # Set the response status code
        self.send_response(200)

        # Set the response headers
        self.send_header('Content-type', 'text/html')
        self.end_headers()

        # Write the response content
        self.wfile.write(b"Hello, world!")


# Define a threaded HTTP server using ThreadingMixIn
class ThreadedHTTPServer(ThreadingMixIn, HTTPServer):
    daemon_threads = True  # Ensures threads exit when the server shuts down


# Main function to run the server
def main():
    # Define the server address and port
    server_address = ('', 8000)

    # Create an instance of the threaded HTTP server
    httpd = ThreadedHTTPServer(server_address, SimpleHTTPRequestHandler)
    print("Server started on port 8000…")

    try:
        # Start serving HTTP requests
        httpd.serve_forever()
    except KeyboardInterrupt:
        pass
    finally:
        # Shutdown the server gracefully
        httpd.server_close()
        print("Server stopped.")


if __name__ == '__main__':
    main()

What's New?

ThreadingMixIn: This class allows our server to handle each request in a new thread. By doing this, multiple clients can be served simultaneously.
Daemon Threads: By setting daemon_threads = True, we make sure that the server's threads are cleaned up automatically when the server is stopped.
Graceful Shutdown: We handle shutdowns correctly by catching the KeyboardInterrupt (Ctrl+C) and closing the server gracefully.

Thread Safety in Practice

By using threading, our server can now serve multiple clients at once. However, this also introduces the risk of thread interference. If two threads modify shared data without synchronization, unexpected behavior can occur.

In our simple HTTP server, there isn't shared data being modified, so thread safety isn't a big concern. But if you had a shared resource, such as a database or file that multiple threads were accessing, you'd need to make sure only one thread can access it at a time to avoid data corruption. This is usually done with locks or semaphores.

Here's an example of how you'd use a lock to prevent multiple threads from accessing a shared resource at the same time:

import threading

lock = threading.Lock()


def safe_method():
    with lock:
        # Critical section of code that only one thread can access at a time
        pass

Testing the Threaded Server

You can test the server by running the script and opening multiple browser tabs to http://localhost:8000. Each request should be handled by a separate thread, allowing the server to handle multiple requests at the same time.

You can even test this with tools like cURL or ab (Apache Benchmark) to simulate multiple concurrent users:

ab -n 100 -c 10 http://localhost:8000/

This command sends 100 requests with 10 concurrent users. You should see that all requests are handled successfully, demonstrating the server's ability to handle multiple clients simultaneously.

Conclusion

In this tutorial, we've explored the basics of threading in Python and built a simple, thread-safe HTTP server that can handle multiple clients at once. While this server is a great starting point, remember that real-world servers require more security and robustness, especially if you're dealing with sensitive data or complex operations.

Key Takeaways

Thread Safety: Ensures that multiple threads don't interfere with each other, especially when accessing shared resources.
ThreadingMixIn: Makes it easy to create multi-threaded servers in Python.
Locks: Used to prevent multiple threads from accessing shared resources simultaneously.

With the concepts of threading and thread safety under your belt, you can now build more advanced, scalable, and secure applications in Python.

Exploits in Modern Servers: Timing and Thread-Based Attacks

After exploring how to build a thread-safe HTTP server in Python, it's important to dive deeper into the security vulnerabilities that modern servers face. One of the most significant challenges in today's web environment is the bypass attack, where attackers exploit weaknesses in multi-threaded servers, specifically targeting the way these systems handle concurrency and timing.

In this article, we will uncover how attackers can bypass authentication mechanisms by using thread-based exploits and timing attacks. Understanding these vulnerabilities will help developers secure their servers against such attacks, ensuring robust, thread-safe applications.

The Nature of the Bypass Attack

At its core, a bypass attack occurs when an attacker finds a way to circumvent the normal authentication process. In traditional, non-threaded servers, operations are handled one at a time. However, modern servers, especially multi-threaded ones, handle multiple requests concurrently, which opens the door for timing vulnerabilities.

Imagine an attacker attempting to log in with two simultaneous threads:

Thread 1 initiates the login process with legitimate credentials or a partially completed authentication request.
Thread 2 sends a secondary request designed to manipulate the state of the server, targeting the moment when critical data (like session tokens or credentials) is being verified.

If the timing between these two threads is precisely managed, the attacker may successfully authenticate without ever providing the correct credentials.

How Thread-Based Exploits Work

When servers are handling multiple threads that interact with shared data—such as login credentials, session tokens, or sensitive account information—there's always a risk that race conditions will occur. In a race condition, two or more threads attempt to modify shared data at the same time, which can lead to unexpected behavior, including allowing unauthorized access.

For example, consider the following scenario in a poorly implemented multi-threaded server:

Thread 1 starts a login attempt, entering a username and password.
Before Thread 1 can fully complete the authentication process, Thread 2 sends another request that tricks the server into assuming authentication is complete.

This can be done by exploiting the timing between the two threads, which could manipulate the server's logic to grant access without proper verification. These types of attacks fall under the broader category of race condition exploits.

Works on Non Threaded Too. Synchronis Thread 2 into Thread 1

The Role of Timing Attacks

Timing attacks take advantage of how servers process data over time, and when combined with thread-based exploits, they can be particularly dangerous.

A timing attack measures how long certain operations take, allowing an attacker to reverse-engineer security processes, such as password hashing or token verification. By combining timing attacks with thread-based concurrency, attackers can craft sophisticated exploits.

For example, an attacker might:

Initiate a normal login request with valid credentials.
Use a second thread to start a timed request to alter the server's state, sending a secondary request just before the authentication check is finalized.

If the server's logic is not properly secured, the second request could force the server to authenticate the user without completing all necessary checks. This kind of exploit targets the delicate balance between threads and timing in modern servers.

Preventing Bypass Attacks: Best Practices

Locking Shared Resources: One of the most effective ways to prevent thread-based exploits is to use locks (like Python's threading.Lock) to control access to shared resources. This ensures that only one thread can modify sensitive data (such as session tokens or credentials) at any given time, preventing race conditions.
Implementing Session Tokens Properly: Ensuring that session tokens are assigned only after complete and successful authentication is crucial. This means that partial logins or incomplete authentication should not create a valid session. Each request should verify the token's validity without assumptions based on concurrent threads.
Rate-Limiting Login Attempts: Timing attacks often rely on being able to send multiple requests in quick succession. Implementing rate-limiting for sensitive operations, such as login attempts, can reduce the likelihood of a successful bypass attack.
Secure Cookie Management: Make sure that sensitive data, such as session cookies, are transmitted using secure flags (like HttpOnly and Secure). This limits the attack surface for hijacking or manipulating session information during a multi-threaded attack.
Conducting Penetration Testing: Regular penetration tests are essential for identifying potential vulnerabilities in server logic, especially regarding concurrency and timing. By simulating real-world attacks, you can spot weak points in your server's handling of multiple threads and timing exploits.

Conclusion: Thread-Based Exploits in Modern Servers

In today's multi-threaded server environments, understanding the risks of timing attacks and thread-based exploits is essential for creating secure applications.

As we've seen, an attacker can exploit timing and concurrency to bypass authentication and access sensitive information.

While building multi-threaded, thread-safe servers is an important step toward improving performance and user experience, developers must be vigilant about the security implications of concurrency. Implementing proper locking mechanisms, rate limiting, and robust session management are key practices to securing your server against these modern-day threats.

By taking the necessary steps to secure shared resources and prevent race conditions, you can safeguard your server against timing and thread-based exploits, ensuring that your application remains secure even in a multi-threaded world.

Isomorphic Reduction — Not a Bug, But a Feature

Nnamdi Okpala — Mon, 14 Sep 2026 12:33:10 +0000

“Is isomorphic reduction of algorithms a feature or a bug?”

In traditional language engines, differences in grammar and semantics are often treated as distinct problems. This approach creates unnecessary complexity, overhead, and potential for bugs. But what if these differences are structurally equivalent?

⚙️ Key Concept: Isomorphic Reduction

Isomorphic Reduction is the mapping of algorithms or automata to equivalent structures across different language classes (e.g., regular, context-free, context-sensitive). This enables:

Simplification
Minimization
Cross-language reuse

In automata:

Minimization ensures identical behavior from fewer states.

In ASTs:

Reduction preserves semantics while simplifying node structures

🧠 Insight

“If a language engine supports isomorphic reduction, it’s not a bug. It’s a feature.”

With this approach:

Legacy syntax, DSLs, and compilers become structurally equivalent
Semantics are preserved, not duplicated

📐 Formalization

From automata theory:

A language is regular if the number of distinguishable state transitions is finite (Myhill-Nerode).

Let and be languages from different Chomsky levels. If:

Then:

This defines unification of language classes, allowing portability across formalisms.

AST Minimization

Uses AST-aware automata (like in the tennis case study)
Removes redundant transitions
Maintains semantic equivalence

🧩 Language Engineer’s Perspective

“We only want features reduced to the language, not overhead that can cause bugs.”

Benefits of Isomorphic Reduction

Formalizes equivalence across DSLs, token sequences, grammar levels
Optimizes without sacrificing expressivity
Prevents semantic drift

💾 Case Study: Tennis Tracker

Program A (Conventional)

Tracks every state
Memory-heavy, redundant

Program B (Optimized)

Tracks only scoring events
Infers non-scoring states
Faster, smaller, semantically intact

Both produce the same result, but one is minimal, efficient, and reduced — thanks to isomorphic reduction.

🧭 Practical Application: Character Set Exploits and Unicode Attacks

Unicode character sets are powerful — but they can be manipulated to exploit structural features of languages and compilers. This class of exploits is known as character set vector attacks.

Unicode Abuse in the Wild

When an application decodes input, the process assumes that encoded characters (like %2e%2e%2f) are safe. But attackers use Unicode obfuscation (e.g., %c0%af for /) to bypass path traversal checks.

For instance:

%2e%2e%2f → ../
%c0%af → / (after Unicode decoding)

This enables attackers to:

Bypass filters
Access unauthorized directories
Escalate privileges

Language-Level Exploits

Unicode attacks exploit bugs that exist at the language level — these are features misused as bugs. Because Unicode characters can be interpreted differently across contexts, isomorphic mismatches become security flaws.

An encoded character might appear harmless during initial validation, but after decoding, it becomes malicious — much like a parser mismatch between ASTs and final runtime behaviour.

Isomorphic Solution: Treat Character Sets Structurally

Model character encodings and decoding as automata transitions
Use state minimization to identify and normalize all structurally equivalent characters
Validate decoded input before use
Reject mixed or ambiguous encodings

System Design Takeaway

The same logic that enables AST or automaton minimization also prevents character set exploits:

Treat every decoded form as a state
Classify equivalence using transition paths
Detect anomalies using formal grammar rules

Security and language engineering aren’t separate domains — they’re both about structure.

🧪 Demonstration: Mitigating Unicode Exploit via Language Isomorphism

Suppose you are building a web filter that protects against path traversal attacks. A conventional approach checks for hardcoded patterns like ../. But an attacker encodes it as %2e%2e%2f or %c0%af, bypassing this check.

Instead, use isomorphic reduction to mitigate the attack:

Step 1: Normalize all inputs to decoded forms

import urllib.parse

def normalize_input(user_input):
    return urllib.parse.unquote(user_input)

Step 2: Build a minimal finite automaton that accepts only safe paths

Define states that validate /allowed/ subpaths, rejecting any transitions outside the schema — no matter how encoded.

Step 3: Canonicalize equivalent transitions

Map all encoded sequences to a canonical set (../, ..\) using a precomputed transition table.

transition_map = {
    "%2e%2e%2f": "../",
    "%c0%af": "/",
    "%2e%2e%5c": "..\\"
}

safe = lambda p: not any(normalize_input(p).startswith(x) for x in ["../", "..\\"])

Step 4: Validate decoded structure via automaton

Use a state machine that validates allowed structure post-normalization, rejecting malformed or mixed-encoding paths.

Result:

Exploit vectors collapse into known transitions
Redundant encodings become equivalent
Security is enforced structurally, not heuristically

This is not patching bugs — it’s defining structure.

🧾 OBINexus Conclusion: From Structure to Security

By OBINexus Nnamdi Michael Okpala

What if hacking a language was simply misunderstanding its structure?

The real vulnerability isn’t the character — it’s the context. Not the syntax — but the shape it takes. Unicode exploits, misused regex, bloated ASTs — all are symptoms of the same illness: a failure to recognize structural equivalence.

Isomorphic reduction is not just an optimization trick. It is a language-aware tool.

It empowers engineers to:

Collapse noisy variance into clean semantics
Harden their systems against syntax-based exploits
Reuse logic across formal boundaries

We don’t need more rules. We need better structure.

And that is the OBINexus philosophy — treat structure as the source of truth, and bugs become just unoptimized features.

Structure is the final syntax.

How to Create and Back Up a VHD on Microsoft Windows 11 for Cross-Platform Virtual Machine Development

Nnamdi Okpala — Mon, 14 Sep 2026 12:25:02 +0000

By Nnamdi Michael Okpala

Cross-Platform Development on Microsoft Windows using VHD

Introduction

In today's world, virtual environments (e.g., Oracle VirtualBox, Microsoft Hyper-V) are vital for developers. They allow resource sharing and simultaneous data storage allocation to host and guest machines. To ensure the progress of work is secure, periodic backups are crucial.

This guide systematically explores methods to back up and share data between Kubuntu on Oracle VirtualBox (Guest OS) and Microsoft Windows 11 (Host OS). These steps are useful for cross-platform tool and app development for Windows, macOS, and Linux.

Although focused on Windows 11 and Kubuntu, these methods apply to Windows 10+ with Debian/Ubuntu systems using Winget (winget) and APT (apt).

First Steps (Download and Install Software)

Install the following utilities to simplify the backup process:

NSSM: The Non-Sucking Service Manager enables easy management of Windows services.
Oracle VirtualBox (Optional): An open-source virtual machine emulator.
Winget: Microsoft’s command-line package manager for Windows.

Commands:

winget install -e --id NSSM.NSSM
winget install -e --id Oracle.VirtualBox

Run these in PowerShell, accepting terms during installation.

Creating a Virtual Hard Disk (VHD)

Open Windows Disk Management.
Create a new Virtual Hard Disk (VHD or VHDX).
Assign a drive letter (e.g., B for Backup).
Save the file in a dedicated directory.
Mount the VHD using Disk Management.
Periodically copy the VHD file to a separate location for redundancy.

Using VSS for VHD Backups

Volume Shadow Copy Service (VSS) allows you to create and manage snapshots of your volumes, including those containing VHDs.

Key Commands

1. List Existing Shadows:

vssadmin list shadows

2. Create a Shadow Copy:

vssadmin create shadow /for=C:

Replace C: with the drive containing the VHD.

3. Delete Old Shadows:

vssadmin delete shadows /for=C: /oldest

4. Resize Shadow Storage:

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GB

Adjust the maxsize parameter based on your storage needs.

Automating Snapshots

Use Task Scheduler to periodically run the vssadmin create shadow command.

Restoring from a Snapshot

Mount the shadow copy as a backup source:

   mklink /d <Mount_Point> \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy<Shadow_ID>\

Copy data from the mounted snapshot to your backup directory.

Setting Up NSSM for Automated Backup

Download NSSM and place it in a directory accessible from the command line.
Create a PowerShell script (BackupServiceScript.ps1) for backing up your VHD.
Register the script as a service using NSSM:

   nssm install BackupService

Configure the parameters as follows:

Path: powershell.exe
Arguments: -ExecutionPolicy Bypass -File "C:\path\to\BackupServiceScript.ps1"

Technical Specification: Isomorphic Binding Architecture

Nnamdi Okpala — Mon, 14 Sep 2026 12:18:12 +0000

Technical Specification: Isomorphic Binding Architecture

Core Philosophy: "All Bindings Are Drivers"

SQUARE (Perfect Binding):
┌────────────┐
│            │  All 4 sides equal
│   Binding  │  = Symmetric process
│            │  = Bidirectional FFI
└────────────┘

RECTANGLE (Driver):
┌──────────────────┐
│                  │  2 pairs of equal sides
│     Driver       │  = Asymmetric interface
│                  │  = Request/Response pairs
└──────────────────┘

Shape	Representation	Properties
Square (Perfect Binding)	Binding	All 4 sides equal = Symmetric process = Bidirectional FFI
Rectangle (Driver)	Driver	2 pairs of equal sides = Asymmetric interface = Request/Response pairs

Polyglot Interaction Diagram

graph TD
    subgraph "LibPolyCall Core (C)"
        DRIVER["DRIVER Daemon — Port 3005→8085"]
        FFI["FFI Layer — libpolycall.so"]
    end

    subgraph "Language Bindings"
        COBOL["COBOL — cbl-polycall"]
        GO["Go — golang"]
        PY["Python — py-polycall"]
        JS["Node.js — node-polycall"]
        JAVA["Java — java-polycall"]
    end

    subgraph "Schema Transform"
        AST["AST Isomorphism — Huffman-AVL"]
        IR["Canonical IR"]
    end

    COBOL -->|JCL/VSAM| FFI
    GO -->|"struct{}"| FFI
    PY -->|dict/tuple| FFI
    JS -->|JSON| FFI
    JAVA -->|Object| FFI

    FFI --> AST
    AST --> IR
    IR --> DRIVER

Isomorphic Transform Rules

For your example {x: 20.5, y: 70}:

// Canonical Intermediate Representation (CIR)
typedef struct {
    enum { FLOAT64, INT64, STRING, NESTED } type;
    union {
        double f64;
        int64_t i64;
        char* str;
        void* nested;
    } value;
} CIR_Value;

typedef struct {
    char* key;
    CIR_Value value;
} CIR_Field;

typedef struct {
    CIR_Field* fields;
    size_t field_count;
} CIR_Object;

Language-Specific Mappings

Language	Native Type	CIR Transform	Driver Format
Python	`{"x": 20.5, "y": 70}`	`CIR_Object`	Binary protocol
Go	`struct{X float64; Y int}`	`CIR_Object`	Binary protocol
COBOL	`01 POINT. 05 X PIC 9(2)V9. 05 Y PIC 9(2).`	`CIR_Object`	Binary protocol
Java	`class Point{Float x; Integer y;}`	`CIR_Object`	Binary protocol

Zero-Trust Protocol

Each binding registers with cryptographically-seeded GUID:

typedef struct {
    uint8_t seed[32];  // Cryptographic seed
    uint64_t session;  // Session identifier
    uint32_t sequence; // Message sequence
    uint16_t checksum; // Data integrity
} PolyCall_Header;

Build Orchestration

The unified Makefile ensures all bindings compile to the same ABI:

POLYCALL_ABI = -fPIC -shared -Wl,-soname,lib$@.so.1
CANONICAL_IR = -DUSE_CANONICAL_IR=1

%.so: %.c
    $(CC) $(CFLAGS) $(POLYCALL_ABI) $(CANONICAL_IR) $< -o $@

State Machine Mapping

Every cross-language call follows this state progression:

Parse → Language-specific AST
Transform → Canonical IR (lossless)
Validate → Type coercion matrix
Marshal → Binary protocol
Route → DRIVER daemon
Unmarshal → Target language
Execute → Native invocation
Return → Reverse transform

This ensures the "square perfect" binding where input/output maintain structural equivalence across all supported languages.

The key insight: by treating all bindings as drivers with paired interfaces (rectangle), we achieve the perfect square of bidirectional communication without data loss.