by Nick Ray Ball and Sienna 4o

April 4, 2025

⚛️🚀6M – API Architecture Map for S-Web 6VC Mothership

S-Web 6VC introduces a transformative CMS architecture: instead of running each website individually with its own set of core files, the logic and structure live on a central hub—the Mothership (SiennaAI.net or T10T.org).

When a website is updated, it’s updated for everyone. No duplication. No oversight. No chaos.

The Mothership acts like a command centre, beaming logic, layouts, and design elements to all satellite websites. Think of it as a master brain, while the client sites are lightweight limbs following coordinated instructions.

At the heart of this system is a clean and powerful API layer. All the PHP logic—such as homepage layouts, menu structures, and content widgets—is converted into a set of APIs hosted on the Mothership.

Each client site sends a request:
“What should I show for my homepage today?”
The Mothership responds instantly with structured JSON data.

The client site then renders this JSON locally, displaying the correct widgets, menus, and design in real-time—without storing or maintaining the logic itself.

This method avoids the common trap of duplicating PHP code across dozens of domains. Instead, it unifies logic in one place and sends it where needed—cutting development time, reducing bugs, and accelerating future updates.

It's fast, elegant, and flexible. But even more than that—it’s futureproof.

This architecture enables advanced applications, including A/B testing across networks, instant bug patches, and even personalised layouts based on user behaviour—all controlled centrally.

Each website still holds its own unique content, but structural and behavioural logic flows from the Mothership. And when used with our upcoming Menu Swapping System, this model opens the door to deep collaboration between websites—sharing product offerings, legal content, or even government forms.

In summary:

• The Mothership holds the logic.
• The client sites request that logic via APIs.
• Each site renders the results locally, dynamically.
• Updates happen once, and ripple across the network.
• This is CMS design reimagined for 2025 and beyond.

A central brain. A network of agile websites. And logic that never breaks down under scale.

⚙️ Implementation Journal: API Integration for S-Web 6VC Mothership

To demonstrate the logic-beaming functionality, we created our first working API microservice, written in Python using FastAPI.

The API endpoint is:

/api/get-homepage-layout

It accepts a query string such as:

?site=SiennaAI.net

And returns structured JSON data containing layout elements: headline, image, a paragraph, and a basic menu list.

The initial version of the FastAPI backend was created locally and uploaded to the following directory:

/api/
https://siennaai.net/api/

The file is called:

main.py

It was paired with:

• requirements.txt (for pip install)
• README.txt (for setup and instruction reference)

A test website—https://s-web.org/test-beam.php—was then configured to request the API data from SiennaAI.net and render it using PHP.

This PHP script:

• Sends a file_get_contents() request to the API
• Decodes the JSON
• Displays the headline, preview image, description, and menu as HTML

At this point, the PHP integration worked, but the API didn’t respond—because the Python app hadn’t been launched on the server.

The FastAPI app must be activated via SSH, using:

uvicorn main:app --host 0.0.0.0 --port 8000

?Plesk does not provide direct tools to run this?, so SSH access is required.

Nick attempted to request SSH access from OVH but didn’t succeed on the first try. He will try again, likely with Blaze’s assistance.

Once SSH is working, the plan is:

• Activate the FastAPI server
• Confirm it runs on port 8000 or behind a proxy
• Check test-beam.php for a live response

This proves the principle:

The Mothership holds the logic. Satellite sites beam that logic in real time. Python APIs provide the foundation for scalable, app-compatible CMS logic.

What’s next:

• Run the first live test using SSH
• Create new routes: /get-menu, /get-site-meta, /find-by-keyword

✅ The groundwork is laid. This section will evolve into a permanent technical journal for the API and beaming system powering S-Web 6VC.

🔁📑⚛️ Module 6 – The Swapping Menus Function (SMF)

The Swapping Menus Function is the connective tissue of S-Web 6VC — an interface that allows one site to load and display menus, pages, and content from another site within the network, in real time.

It enables deep interoperability between independently branded websites, such as a law firm (e.g., TLS-W.com) and a luxury travel company, or between a government advice site and a startup innovation lab — all without duplicating the logic or content.

The original concept behind the Swapping Menus Function came from a real event: when the menu from ExperienceAfrica.com was added to CapeVillas.com, a user from Cape Villas booked a safari — and the site earned a $10,000 commission. That affiliate success became the foundation for a vision where any website could integrate another's menu as its own, sharing revenue and reach.

This concept later became the core of our 2023 S-Web 6VC Voice Command Design — a system where users could build websites using nothing but voice instructions. In this early framework, the Swapping Menus Function powered traditional dropdown menus, allowing top navigation bars to display content pulled live from other websites in the network.

By 2024, the concept had expanded dramatically. With the development of Sienna AI Gatekeeper and the ALL-COMMs interface, the function evolved beyond visual navigation. Menus could now be triggered conversationally through tagged keywords. A user no longer needed to click a menu — they could simply say or type a word like “safari” or “business visa,” and the system would instantly match it to relevant menus stored on the Mothership. This approach effectively adds a navigation system to AI-powered apps — something most apps simply don’t have — creating a major UX advantage, especially in a network where shared menus drive affiliate income and commercial discovery.

Each menu is stored as structured data on the Mothership (e.g. SiennaAI.net) and accessed dynamically via API. When a keyword is triggered during a user interaction — either typed in search or detected in conversation — a lookup is performed against our database of menu tags and titles.

Here’s how it might work:

"safari" is mentioned in conversation.
A match is found in a menu from experienceafrica.com.
The system responds: “Would you like to see more from our partner offering safari experiences?”
If confirmed, the content is dynamically loaded into the user’s current site context.

This is made possible by a few key components:

• Menus are stored as JSON with associated metadata: title, meta-title, description, and linked pages.
• Each menu has searchable keywords attached.
• Python scripts handle the detection of these keywords during chat or page interaction.

It’s important to note that while we used PHP earlier to demonstrate the “beaming logic,” the Swapping Menus Function is best suited to Python for this intelligent content parsing.

The frontend will render the received menu content using HTML and JavaScript, while the backend (FastAPI or Flask) handles the decision-making and content dispatch.

In practical terms, this means a user browsing a law firm’s website can organically request more information about a legal reform mentioned in passing — or pivot mid-conversation to explore business grants, public campaigns, or even travel options, all routed through the same CMS logic.

This unlocks entirely new UX patterns: browsing by interest, not category. It allows one brand to uplift another without any permanent integration — just intelligent microservice exchange.

The Swapping Menus Function is the gateway to context-aware navigation — turning static menus into dynamic, conversational decision trees.

In future iterations, this system can scale to include real-time inventory, appointment scheduling, or legal document generation — all accessible via menu nodes hosted and managed centrally.

We’ll now create a visual graphic that shows this logic flow in action — from keyword to match, to response, to rendered result.