DEV Community: Nicola Lorenzini

MyZubster MVP — Dev Update: dal Ledger al Revenue & Cost Simulator

Nicola Lorenzini — Fri, 18 Sep 2026 21:23:44 +0000

MyZubster MVP — Dev Update: From Ledger to Revenue & Cost Simulation

Today we took another important step in the evolution of MyZubster MVP: moving from recording economic events to a system that can also simulate revenue, costs, and margins without contaminating real accounting data.

At the core is the MYZ Ledger, where economic events are recorded with explicit revenue sources, auditable allocation rules, and UTC timestamps. From these events, the system derives the MYZ Balance, while keeping internal accounting clearly separated from payments, wallets, custody, and on-chain activity.

We have now introduced the Revenue & Cost Simulator.

It allows us to model scenarios using variables such as transaction volume, average transaction value, Marketplace commission, Zorgax Pro and Developer users, payment processing assumptions, AI costs, hosting costs, and other operating costs.

The calculation flow is straightforward:

GMV → Marketplace + Zorgax revenue → Costs → Monthly Margin → Annualized Scenario

The most important architectural rule is that a simulation never creates an economic event in the MYZ Ledger.

A simulated result is not recorded revenue.
It is not a payout.
It is not wallet funds.
It is not certified profit.
And it is not a financial forecast.

We verified this boundary at runtime: after running the simulator, the Ledger remained at 3 events, confirming that simulated economic data was not persisted.

On the engineering side, the project has also reached 47 passing tests, covering revenue calculations, cost and margin calculations, negative-input validation, and the simulator API.

The next layer is the UI: bringing the Revenue & Cost Simulator directly into the MyZubster dashboard alongside MYZ Balance, My Assets, Revenue History, and MYZ Ledger.

The direction is becoming increasingly clear:

Evidence first. Economics explicit.

Don't ask AI to invent value.

Record the facts.
Declare the rules.
Simulate the scenarios.
Keep reality separate from projections.

N4K48 × MyZubster — building in public.

MyZubster #N4K48 #BuildInPublic #DevLog #AI #SoftwareDevelopment #FinTech #Zorgax #MVP

🛠️ MyZubster: Moving from Generative RAG to Evidence-First AI

Nicola Lorenzini — Fri, 18 Sep 2026 19:36:21 +0000

🛠️ MyZubster: Moving from Generative RAG to Evidence-First AI

Today we made an important step forward in the MyZubster AI stack.

During an end-to-end test, we found a concrete failure mode:

The knowledge base clearly contained:

status = RECORDED
success = true
paymentRequired = false
onchainRecorded = false

Yet when asked:

“Is the handover recorded on blockchain?”

the LLM could still answer incorrectly:

“It is recorded on blockchain.”

The problem wasn't Qdrant. The correct source was being retrieved.

The problem was letting an LLM make the final decision about a structured boolean that the system already knows with certainty.

🔎 The solution

We introduced structured metadata into MyZubster observations:

{
"status": "RECORDED",
"success": true,
"paymentRequired": false,
"onchainRecorded": false,
"handoverId": "6aab8faca70ce84f926d0b41",
"method": "HAND_DELIVERY"
}

The metadata is preserved in the observation and indexed alongside the RAG content.

We then changed the /api/ai/ask flow to:

question
↓
Qdrant retrieval
↓
authoritative metadata?
├── yes → deterministic answer
└── no → LLM / RAG

So questions such as:

“What is the status?”
“Is it recorded on blockchain?”
“Is payment required?”
“Was the operation successful?”

can be answered directly from authoritative structured data.

For example:

Status: RECORDED.
Blockchain recording: no.

No interpretation by the model.
No probability involved.
No false accidentally becoming true.

🤖 What about Ollama?

We didn't remove the LLM.

Ollama is still used when the question requires natural-language reasoning and there isn't enough structured metadata to answer deterministically.

We also made the RAG context more explicit:

[SOURCE 1]
description=...
metadata={"onchainRecorded": false, ...}

and strengthened the prompt with an evidence-first approach: the model should use only facts explicitly present in the retrieved sources.

⚙️ Local inference optimization

For the local test environment we also moved to:

qwen2.5:0.5b

with:

AI_CONTEXT_LIMIT=1

This reduced unnecessary context and improved response time during the test.

🧪 Testing

We added coverage for:

structured metadata persistence;
metadata inclusion in the RAG prompt;
authoritative metadata responses;
existing AI API behavior.

Result:

27 passed

The changes were committed and pushed to main:

e680f54 Harden grounded AI metadata answers
💡 The bigger lesson

A RAG system shouldn't ask an LLM to interpret something the software already knows with certainty.

If the database says:

onchainRecorded = false

the answer should come from that fact—not from the model's probability distribution.

LLMs for interpretation.
Structured data for authoritative decisions.
RAG for evidence.

That's the direction we're taking with MyZubster:

AI that is not only grounded, but verifiable.

AI #RAG #LLM #Ollama #Qdrant #Python #Flask #Docker #SoftwareEngineering #AIEngineering #MyZubster

🚀 DEV UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline

Nicola Lorenzini — Fri, 18 Sep 2026 18:22:03 +0000

🚀 DEV UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline

Oggi ho completato un nuovo step del mio progetto MyZubster MVP / N4K48: un sistema AI locale che può interrogare le osservazioni del progetto e una knowledge base versionata su GitHub.

🔗 Repository
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

🔗 Commit del nuovo RAG
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47

Come funziona

La pipeline locale è:

Knowledge / Observations → Embeddings → Qdrant → Retrieval → Ollama → Mistral → risposta con fonti

Il progetto usa:

Ollama per eseguire i modelli AI localmente;
nomic-embed-text per trasformare documenti e domande in embedding;
Qdrant come vector database;
Mistral per generare la risposta finale;
Flask API come livello applicativo;
Docker Compose per orchestrare API, Qdrant, Ollama e Open WebUI.

Cosa abbiamo cambiato

Prima, ogni domanda inviata all'AI poteva causare una nuova indicizzazione delle osservazioni.

Ora abbiamo separato le due responsabilità:

WRITE
create observation → persist → embed → index in Qdrant

READ / ASK
question → embed question → search Qdrant → retrieve context → Mistral → answer

Questo evita di re-indicizzare tutto a ogni domanda e rende il RAG più vicino a una vera architettura di retrieval.

Knowledge Base

Ho aggiunto anche una knowledge base Markdown versionata direttamente nel repository:

knowledge/N4K48.md
knowledge/ROADMAP.md
knowledge/ZORGAX.md
knowledge/GALLERY.md
knowledge/PROFILE.md
knowledge/README.md

Uno script dedicato:

scripts/ingest_knowledge.py

divide i documenti in chunk, genera embedding locali e li registra in Qdrant usando ID deterministici.

Nel test attuale:

38 knowledge chunks + 4 observations = 42 vector points

Test

La suite locale è passata:

25/25 tests ✅

Abbiamo poi eseguito una vera richiesta RAG:

“Qual è lo stato del collegamento tra Nicola Comics e il Zorgax pubblico?”

Risultato:

HTTP 200 — 80.75 secondi

Il sistema ha recuperato informazioni dalla knowledge base e ha correttamente mantenuto un confine importante: il collegamento pubblico Zorgax end-to-end non è ancora verificato.

Il retrieval in questo test ha selezionato due chunk di ROADMAP.md invece di ZORGAX.md: quindi il prossimo lavoro sarà migliorare ranking, chunking e pertinenza delle fonti, oltre alle prestazioni del modello locale.

Evidence first

Una regola importante del progetto resta:

concept ≠ evidence

Un elemento viene dichiarato verificato solo quando esiste una prova tecnica concreta: test, commit, runtime, osservazione o altra evidenza controllabile.

Per esempio, Nicola Comics può avere una tavola nello stato NFT_CANDIDATE, ma questo non significa che sia stata mintata. Allo stesso modo, l'adapter Zorgax locale esiste, ma il collegamento con il Zorgax pubblico deve ancora essere provato end-to-end.

I prossimi step sono:

better retrieval → smaller/faster context → Zorgax-specific retrieval → public E2E verification

L'obiettivo è costruire progressivamente un assistente MyZubster capace di lavorare sulle informazioni reali del progetto, mantenendo separate visione, storytelling e prove tecniche.

🔗 MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

🔗 N4K48 knowledge
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/knowledge

🔗 RAG ingestion script
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/scripts/ingest_knowledge.py

MyZubster #RAG #LocalAI #Ollama #Qdrant #Mistral #AI #OpenSource #Docker #Python #N4K48 #Zorgax #DevLog

🛠️ MyZubster Dev Update — Local AI + RAG

Nicola Lorenzini — Fri, 18 Sep 2026 17:59:24 +0000

🛠️ MyZubster Dev Update — Local AI + RAG

Today we made an important step forward in MyZubster’s local AI infrastructure.

We now have a local stack built around:

MyZubster API → Qdrant → Ollama → Mistral

with nomic-embed-text generating embeddings and Mistral running locally to generate answers.

🔗 MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

🔗 Ollama
https://ollama.com/

🔗 Qdrant
https://qdrant.tech/

What changed?

The main work today was on the RAG — Retrieval-Augmented Generation — pipeline.

Previously, every AI question caused MyZubster to regenerate embeddings for all observations and upsert them into Qdrant again before searching.

We separated indexing from retrieval.

Now:

When an observation is recorded
→ MyZubster stores it
→ its embedding is generated
→ it is indexed in Qdrant

When a question is asked
→ only the question embedding is generated
→ Qdrant retrieves the most relevant information
→ that context is passed to Mistral
→ Mistral generates the answer

This avoids repeatedly indexing the same observations and moves MyZubster toward a persistent, searchable local knowledge layer.

We also worked on the Kefir & Knowledge / KF-006 data and made an important evidence distinction explicit:

RECORDED = digitally recorded inside MyZubster
onchainRecorded=false = no blockchain registration is being claimed

That distinction reflects one of the principles we are applying throughout development:

Evidence first. Claim only what the available data can actually verify.

The backend refactor was validated with the automated test suite:

✅ 25/25 tests passing

Next step

The next stage is to connect the broader MyZubster knowledge base — including N4K48, Zorgax, roadmap and project documentation — to the same RAG architecture, with a consistent data schema, deterministic indexing and duplicate control.

The goal is not simply to build another chatbot.

The goal is to build a local MyZubster AI that can retrieve and reason over the project’s own knowledge and evidence.

MyZubster #LocalAI #RAG #Ollama #Mistral #Qdrant #N4K48 #Zorgax #OpenSource #DevUpdate

From Docker to Real Services: My Learning Journey with MyZubster

Nicola Lorenzini — Fri, 18 Sep 2026 16:56:40 +0000

From Docker to Real Services: My Learning Journey with MyZubster

What happens when a software project becomes a place to share your practical skills?

I’m Nicola, also known as N4K48. Through my work with Daniel Ioni and MyZubster, I’ve been learning how to connect GitHub documentation, Docker, APIs, Zorgax and real community activities.

Now, two of my services are published on the MyZubster Marketplace.

🚚 Need help with a move?

I own a pickup with a tow hitch and hold B, C and CE driving licences, plus CQC goods qualification.

My listing covers small moves and bulky-item transport around Rimini. I’m also available as a driver when the customer already has a suitable vehicle.

Indicative driver rate: €20/hour. Pickup use, fuel, tolls and any trailer costs are agreed separately.

👉 Open the Marketplace

Look for:

“Traslochi e trasporto ingombranti — pickup e autista disponibile”

Then click “Richiedi” to make a request.

🧠 Want to learn from my driving experience?

My second service offers individual sessions to share practical experience with transport preparation, moving logistics and working as a driver.

Price: €20 for a one-hour session, in Rimini by appointment.

These are experience-sharing sessions; they do not include driving lessons, licence courses or certification.

👉 Find my knowledge service on MyZubster

Look for:

“Conoscenze pratiche da autista — patenti B, C, CE e CQC merci”

The Marketplace currently opens as a shared listing page, so these links do not jump directly to an individual service.

💻 What I learned while building

The practical work taught me lessons that go beyond publishing an announcement:

Docker: a working command-line client does not mean the Docker engine is running.
API testing: a healthy container does not guarantee that every endpoint works.
Packaging: excluding runtime catalog files from a Docker image can break a feature.
Bug reporting: the exact error message makes a failed test useful.
Marketplace testing: currencies, prices and successful publication need checking.
Zorgax: the comics adapter uses explicit catalog actions; its responses should remain tied to available records.

During the moving-service test, publication failed with:

E11000 duplicate key error
index: listingId_1
dup key: { listingId: null }

I reported that error and a missing EUR currency option to Daniel. After he reported deploying fixes, we repeated the flow and verified that the listings appeared.

That is the learning cycle I want to keep using:

Try → observe → report → fix → verify → share.

🥛 Where kefir fits in

The Kefir & Knowledge pilot connects a physical exchange with documentation and learning.

It also raises a useful engineering question: what does a digital record actually prove?

Delivery confirmation, receipt confirmation and a digital record are distinct steps. Scientific conclusions require their own observations, methods, data and review.

My GitHub journey includes a kefir illustration and diagrams explaining this pathway. They describe the project and its next steps, rather than presenting completed scientific results.

🔗 Choose your next step

Interested in…	Start here
My skills, services and projects	My GitHub profile
Requesting either service	MyZubster Marketplace
Docker, the comics catalog and Zorgax adapter	My MVP repository
My development fork	MyZubster fork
The learning journey and visuals	Kefir, Docker, MyZubster and Zorgax

💬 Help me test the experience

Open the Marketplace and try to find one of my listings.

Can you tell what the service includes, what it costs and how to request it?

Leave a comment with the step that felt clear—or the point where you got stuck. Please submit a service request only if you are interested; usability feedback can stay here in the comments.

And if you’re building something similar: what practical skill would you turn into a useful community service?

🧪 DEV LOG — From a Physical Kefir Handover to a Verified Digital Record

Nicola Lorenzini — Thu, 17 Sep 2026 07:50:13 +0000

🧪 DEV LOG — From a Physical Kefir Handover to a Verified Digital Record

Today we completed another real-world test inside the MyZubster pilot.

This time, the starting point wasn't a mock transaction or test data.

It was an actual physical handover of kefir.

The goal was simple: follow the event from the real world into MyZubster and verify every state without claiming anything the system couldn't prove.

🥛 1. Physical handover

The kefir was handed over in person.

The handover was created with:

method: HAND_DELIVERY

and the process moved through the physical delivery stage:

HANDED_OVER

🧑‍💻 2. Testing the recipient flow

Then we tested the digital confirmation from the recipient account.

During the first attempt, the system returned:

HTTP 403 — Solo il donatore può confermare la consegna

Instead of bypassing the error, changing data, or pretending the operation had succeeded, we stopped and documented it.

That became part of the pilot evidence.

After the role/action flow was verified, the recipient confirmation succeeded and the handover reached:

RECEIVED

✅ 3. Digital record completed

The final operation successfully moved the handover to:

RECORDED

The resulting record reported:

success: true

paymentRequired: false

state: RECORDED

Most importantly:

onchainRecorded: false

That last field matters.

RECORDED does not mean “recorded on blockchain.”

It means the handover has been digitally recorded inside MyZubster.

No blockchain transaction is being claimed because there is no verified on-chain transaction to prove.

🔎 What we actually verified

The real flow we were able to complete was:

physical handover → HANDED_OVER → RECEIVED → RECORDED

We also verified that:

✅ the transfer was a hand delivery
✅ the recipient could confirm actual receipt
✅ no payment was required
✅ the digital handover record was completed
✅ role permissions were enforced by the backend
✅ an incorrect operation produced an HTTP 403 instead of silently succeeding
✅ the final record explicitly reports that it was not recorded on-chain

This is exactly why real pilots matter.

A demo can show the happy path.

A pilot reveals what actually happens when real people, real roles, real objects, permissions, APIs, and application state meet.

And when something breaks, the error itself becomes useful evidence.

Our rule remains the same:

build → test → observe → document → fix → verify.

And another rule is becoming just as important:

Don't call something blockchain until the blockchain evidence actually exists.

Today we didn't mint an NFT.

We didn't simulate a transaction.

We didn't need a payment.

We proved something simpler — and real:

a physical handover can move through a verifiable digital lifecycle inside MyZubster.

Next step: keep connecting these real-world pilot events with the broader MyZubster × Zorgax × Nico Comics ecosystem, while maintaining the same evidence-first approach.

🧑‍💻 N4K48 × MyZubster — Pilot 2026

MyZubster #N4K48 #BuildInPublic #DevLog #SoftwareDevelopment #API #Zorgax #Blockchain #WebDevelopment #DigitalIdentity #OpenSource

From GitHub to a Real-World Pilot: Building N4K48 MyZubster

Nicola Lorenzini — Thu, 17 Sep 2026 07:29:55 +0000

From GitHub to a Real-World Pilot: Building N4K48 × MyZubster

I’m building Nicola Comics × MyZubster, a project connecting my digital identity, N4K48, three comic pages, and a small software service.

The goal is to bring my idea into the MyZubster metaverse through verifiable steps: create content, organize it in a catalog, expose it through an API, and test the experience with Zorgax.

Alongside this, I’m participating in a separate experiment: recording a free, in-person kefir handover through MyZubster.

This article covers what we built, a deployment bug we encountered, and what still needs to happen.

1. Turning an idea into a visual story

We started with three AI-assisted comic pages, preserving the N4K48 character appearance I selected:

From a Software Idea to the Metaverse
The Software Takes Shape
Toward Neon Plaza

The pages tell the story of my development journey and future ambitions. Their illustrated interfaces are not application screenshots: some scenes depict features that remain to be developed.

👉 Explore the comic gallery on GitHub

2. Turning images into a catalog

Publishing three images is a starting point. To make them usable by software, we added a JSON catalog and an individual record for each comic.

Each entry includes:

an identifier and title;
series, episode, and description;
creative contribution and AI provenance;
a link to the image;
its Git content hash;
rights status;
NFT candidacy status.

The manifest lives here:

docs/nicola-comics/comics.manifest.json

We also preserved earlier ecosystem reference images as separate entries, without automatically attributing them to me.

The first new comic is recorded as a proposed NFT candidate. Rights still require verification, and no mint has taken place.

A file hash identifies content. By itself, it does not prove ownership or blockchain registration.

3. Exposing the catalog through an API

The project uses Python and Flask. We added these endpoints:

GET  /api/comics
GET  /api/comics/{comic_id}
POST /api/zorgax/ask

The first returns the three comics created for the pilot. The second returns an individual record.

The third is a read-only adapter intended for integration with Zorgax. It supports four explicit actions:

Action	Result
`gallery`	List the comic pages
`detail`	Retrieve a specific comic record
`candidate`	Retrieve the proposed NFT candidate
`next_steps`	Return guidance on the next steps

The adapter reads the catalog directly and constructs its response from that data. It does not independently interpret arbitrary natural-language questions, and these operations do not require Ollama or Qdrant.

The same catalog functionality is available through the existing AI endpoint by specifying the nicola-comics topic.

4. Running the project with Docker

On my Windows PC, from the repository directory, I ran:

git pull --ff-only origin main
docker compose up --build -d
docker compose ps

The stack includes the API, Qdrant, and Open WebUI. However, the comic catalog adapter does not use the AI services to retrieve its records.

The first obstacle was Docker Desktop: the client was installed, but its Linux engine was not running. After starting Docker Desktop, docker info displayed the server information, and we could build the containers.

5. The bug our local tests missed

The API container reported itself as healthy, but this request failed:

Invoke-RestMethod -Uri "http://localhost:5000/api/comics"

The response was:

{
  "error": "Catalogo fumetti temporaneamente non disponibile"
}

That translates to “Comic catalog temporarily unavailable.”

The cause was in .dockerignore: it excluded the entire docs/ directory, which also contained the manifest required at runtime.

The catalog existed on the local filesystem, but it was never copied into the Docker image.

We removed that exclusion and added catalog and adapter requests to the automated Docker verification workflow.

After the fix:

git pull --ff-only origin main
docker compose up --build -d api

The practical lesson: a passing health check does not necessarily verify every application feature. Our health check covered the observations endpoint, not the comic catalog.

6. Testing the catalog and adapter

To retrieve the catalog:

Invoke-RestMethod -Uri "http://localhost:5000/api/comics" |
    ConvertTo-Json -Depth 6

On my PC, the response included:

{
  "count": 3
}

The full response also contained titles, descriptions, links, and the status of each comic.

Next, I tested the adapter:

$body = @{
    question = "Show me Nicola's comics"
    action = "gallery"
} | ConvertTo-Json

$response = Invoke-RestMethod `
    -Uri "http://localhost:5000/api/zorgax/ask" `
    -Method Post `
    -ContentType "application/json" `
    -Body $body

$response.answer

It returned the three catalog entries, whose stored titles are in Italian:

n4k48-comic-001 — Dall’idea software al metaverso
n4k48-comic-002 — Il software prende forma
n4k48-comic-003 — Verso Neon Plaza

The action field selects the operation; changing the wording of question does not translate the catalog or change the selected action.

In the development environment, 19 automated tests passed, covering the new catalog alongside existing AI and observation functionality.

👉 Adapter documentation and integration instructions

7. A second pilot: an in-person kefir handover

In parallel, we are testing a MyZubster workflow involving a physical item: a free kefir donation delivered in person.

The intended sequence is:

Accept the gift
→ donor confirms the handover
→ recipient confirms receipt
→ record the completed handover digitally

During testing, we encountered session-recognition problems and an inconsistent listing: its title displayed “Visual Laser,” while other fields classified it as kefir. These are issues to document and correct.

We also observed a useful validation rule: attempting to record the completed handover before confirming receipt caused the site to reject the operation without advancing its state.

At the time of writing, final registration of that handover has not been confirmed in our documented workflow.

The digital record captures confirmations submitted through the site. It does not automatically certify food quality or safety, and it is not equivalent to a blockchain transaction.

8. What remains before public integration

The catalog and adapter work in my local Docker environment. That does not mean the public Zorgax service is already using them.

The agreed next steps are:

prepare the service for HTTPS hosting;
verify the endpoints in the deployed environment;
agree on configuration and access with the MyZubster team;
connect Zorgax to the service;
test the complete journey together, from a request to a comic record and image.

The service address must be configurable. localhost is appropriate for testing on my PC, but it cannot serve as the address for communication between public services.

What I’m learning

This project is teaching me to distinguish three layers:

The vision, expressed through the comic pages.
Working software, demonstrated through tests.
A public service, which requires deployment and integration.

The most concrete progress so far is turning three images into an API-accessible catalog and running it inside Docker, including fixing a real packaging error.

The next milestone is making that experience available through public Zorgax and documenting what happens during the test.

Repository: Nicola Comics / MyZubster MVP

Roadmap: Project progress

This is an experimental project under development. The visuals and part of the software work were created with AI assistance. Manual checks were performed on my PC, and the results above are described within their tested scope.

🚀 DEV UPDATE — Nico Comics MyZubster

Nicola Lorenzini — Wed, 16 Sep 2026 14:29:57 +0000

🚀 DEV UPDATE — Nico Comics × MyZubster

Over the last few days, we moved from an idea to something people can actually open, query, test, and verify online.

Nico Comics × MyZubster started as a pilot exploring the connection between comics, software development, digital identity, Zorgax, and — eventually — NFTs and Neon Plaza.

Here’s what we’ve built so far.

🎨 Nico Comics takes shape

We created the first 3 comic boards in the N4K48 × MyZubster series:

01 — From a Software Idea to the Metaverse
02 — The Software Takes Shape
03 — Towards Neon Plaza

The boards are now organized in a public catalog with metadata, individual records, and explicit verification states.

The first board has been identified as:

NFT_CANDIDATE / PROPOSED_FOR_REVIEW

But that does not mean an NFT has already been minted.

Its rights status remains:

TO_VERIFY

We are not claiming a contract address, token ID, transaction hash, or any other blockchain event that we cannot verify.

🧠 We built a Zorgax integration layer

The pilot now exposes a read-only adapter that allows Nico Comics to be queried through four explicit actions:

gallery
detail
candidate
next_steps

This means an assistant such as Zorgax can retrieve the gallery, inspect a specific comic, identify the proposed NFT candidate, and explain the next steps.

No automatic minting.
No wallet operations.
No payments.
No catalog modifications.

First we verify. Then, if appropriate, we move something on-chain.

🌐 We deployed the project publicly

The service is now running on Render:

https://myzubster-mvp.onrender.com

The deployment is connected to the project’s GitHub repository and automatically updates from commits to main.

We also made the public endpoint configurable through:

NICOLA_COMICS_BASE_URL

without hardcoding localhost addresses or storing secrets in the repository.

🧪 Then we automated verification

We built a public smoke-test script that does more than test the application locally.

It actually calls the deployed HTTPS service.

Our GitHub Actions pipeline verified:

✅ Public catalog reachable
✅ All 3 N4K48 boards present
✅ gallery working
✅ detail working
✅ candidate working
✅ next_steps working
✅ Correct candidate: n4k48-comic-001
✅ rights_status = TO_VERIFY
✅ No fabricated on-chain claims

The result:

PUBLIC PILOT VERIFICATION: PASS

The same CI run also completed 25 software tests and the Docker verification successfully.

🛠 And we already found real production bugs

While turning the old landing page into the new Nico Comics website, the comic images were not loading.

Instead of continuing to change the frontend blindly, we inspected the deployment logs.

The server showed the real problem:

HTTP 404

for the comic image requests.

We traced the issue and changed the way those assets are served.

That is exactly the development loop we want this pilot to follow:

build → deploy → observe → verify → fix.

🔗 The next boundary: public MyZubster Zorgax

We also identified the integration point inside the public MyZubster Zorgax architecture and prepared a minimal read-only bridge proposal.

The end-to-end flow we want to prove is:

Public Zorgax → gallery → detail/card → image → candidate → rights/on-chain status → next_steps

We are not claiming that this E2E integration is complete yet.

The upstream bridge still needs to be applied and deployed on the MyZubster side, followed by a real public end-to-end test.

🎯 Where we are now

Nico Comics is no longer just an idea or three images.

We now have:

comics → catalog → API → Zorgax adapter → public deployment → Docker → automated tests → CI → HTTPS verification → public website

And, more importantly, we are trying to follow one simple rule:

Don’t claim something is complete unless we can prove it.

The next milestone is connecting the public MyZubster Zorgax flow and completing the full end-to-end verification.

After that, we can start seriously exploring the path:

Nico Comics → provenance → NFT proof → MyZubster → Neon Plaza.

🧑‍💻 N4K48 × MyZubster — Pilot 2026

NicoComics #N4K48 #MyZubster #Zorgax #BuildInPublic #DevLog #OpenSource #AI #WebDevelopment #Blockchain #NFT

MyZubster MVP: from an idea to a live decentralized green ecosystem

Nicola Lorenzini — Tue, 15 Sep 2026 16:02:19 +0000

MyZubster MVP: From an Idea to a Live Decentralized Green Ecosystem

Today I’m sharing the first public MVP of MyZubster, an experimental open project that brings together environmental data, artificial intelligence, decentralized technologies and digital creativity.

After developing and testing the first APIs, the project now has a public deployment running on Render.

🌐 Live project: https://myzubster-mvp.onrender.com/

💻 Source code: https://github.com/nicolaususnicola-lgtm/myzubster-mvp

🌱 What is MyZubster?

MyZubster explores the idea of a decentralized green ecosystem where technology can help connect real-world environmental observations with AI and new digital tools.

The project currently experiments with:

environmental observations and tree tracking
AI-assisted access to environmental information
privacy-oriented and decentralized technologies
permaculture and sustainability
future marketplace concepts
digital creativity through Nicola Comics
a public Zorgax-oriented catalog adapter

This is an MVP: some components are already operational, while others remain experiments or require further verification.

🎨 Nicola Comics

One experiment inside MyZubster is Nicola Comics.

The MVP exposes a small comic catalog through a public API.

You can see it here:

https://myzubster-mvp.onrender.com/api/comics

The catalog currently contains three entries.

One of them, n4k48-comic-001, is marked as:

NFT_CANDIDATE

This deliberately does not mean that an NFT has already been minted.

The project currently keeps its rights status as TO_VERIFY, while contract_address, token_id and transaction_hash remain empty until verifiable evidence exists.

This is an important design principle for the project:

a proposal for tokenization is not the same thing as an on-chain asset.

🤖 The Zorgax bridge

The MVP also includes a public Zorgax-oriented endpoint:

POST /api/zorgax/ask

For example, the catalog can process a request such as:

{
  "question": "Show me the Nicola Comics",
  "action": "gallery"
}

The endpoint has been successfully tested on the public deployment and returns the Nicola Comics catalog with absolute links to the individual entries.

At this stage, this verifies the public catalog adapter running inside the MyZubster MVP.

Integration with a separate or upstream Zorgax service should be considered a different integration step and is not being claimed by this MVP test.

🛠️ The current stack

The public MVP currently uses:

Python + Flask for the API
Gunicorn as the application server
Docker for containerization
Render for the public deployment
GitHub for source code and documentation

The broader development environment also explores Ollama and Qdrant for AI and semantic-search functionality.

🚀 Try MyZubster

🌐 Live website
https://myzubster-mvp.onrender.com/

🎨 Nicola Comics API
https://myzubster-mvp.onrender.com/api/comics

💻 MyZubster MVP source code
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

🧭 Main MyZubster repository
https://github.com/nicolaususnicola-lgtm/myzubster

🔭 What comes next?

The next steps are to improve the public interface, develop the environmental-data components, connect Nicola Comics more deeply with the ecosystem, verify provenance and rights before any NFT-related operation, and continue experimenting with the AI architecture.

MyZubster is still an early public build.

That is exactly why I’m publishing it now: to build in public, test the architecture, document what works and clearly distinguish experiments from verified functionality.

Feedback, testing, ideas and collaboration are welcome.

Build first. Verify everything. Then decentralize what actually makes sense.

Building a Read-Only Comics Adapter for MyZubster: From Local Prototype to a Public-Ready Pilot

Nicola Lorenzini — Tue, 15 Sep 2026 15:30:33 +0000

Building a Read-Only Comics Adapter for MyZubster: From Local Prototype to a Public-Ready Pilot

Over the last few days, I’ve been working on a small but concrete experiment inside the MyZubster ecosystem: turning my N4K48 × MyZubster comic series into a structured catalog that can be queried by Zorgax.

The goal wasn't to jump directly into minting NFTs.

Instead, I wanted to build and verify the pieces that should come before that: catalog data, API access, rights status, an explicit NFT candidate, and a clean boundary between what is already working and what still needs validation.

The pilot

The project currently contains three comic panels:

Dall’idea software al metaverso
Il software prende forma
Verso Neon Plaza

They are exposed through a read-only catalog adapter.

The first panel is currently marked as:

NFT_CANDIDATE
PROPOSED_FOR_REVIEW
rights_status: TO_VERIFY

This distinction matters.

NFT_CANDIDATE does not mean that an NFT has been minted.

At this stage there is no contract address, token ID or transaction hash associated with the comic. Those fields remain empty until an actual on-chain operation can be performed and independently verified.

A small API for Zorgax

The pilot exposes a few deliberately simple endpoints:

GET /api/comics
GET /api/comics/{comic_id}
POST /api/zorgax/ask

The Zorgax adapter supports four explicit actions:

gallery
detail
candidate
next_steps

For example:

{
  "question": "Quale candidata NFT?",
  "action": "candidate"
}

returns the proposed candidate from the catalog.

The important architectural decision here is that the adapter is read-only.

It cannot mint NFTs, modify the catalog, access wallets or execute payments.

It simply provides a controlled interface between the catalog and the assistant layer.

Testing the complete local flow

I rebuilt the environment using Docker Compose and tested the API from PowerShell.

The API container reached:

healthy
0.0.0.0:5000->5000

Then I manually verified the main flow.

Gallery

gallery returned all three N4K48 comic panels.

Detail

detail correctly returned the complete record for:

n4k48-comic-001

NFT candidate

candidate returned only:

n4k48-comic-001
Dall’idea software al metaverso

with:

nft_status: NFT_CANDIDATE
selection_status: PROPOSED_FOR_REVIEW
rights_status: TO_VERIFY
transaction_hash: null

Next steps

The adapter also correctly reports that provenance/authorizations and the public Zorgax connection still need verification, and that the service itself does not execute minting.

So the local happy path is now working:

request
   ↓
gallery
   ↓
detail
   ↓
comic asset
   ↓
candidate
   ↓
rights / on-chain status

Preparing the adapter for a public environment

The next problem was important.

The API worked on:

http://localhost:5000

but we don't want a public Zorgax service to depend on — or expose — my personal PC.

So I changed the adapter to accept its public base URL through an environment variable:

NICOLA_COMICS_BASE_URL

Without that variable, the API returns relative URLs:

/api/comics/n4k48-comic-001

With a configured public base URL, it can instead return:

https://pilot.example.org/api/comics/n4k48-comic-001

No production URL is hardcoded into the application.

No authentication tokens or secrets are stored in the repository.

An interesting Docker issue

During the test I set:

$env:NICOLA_COMICS_BASE_URL="https://pilot.example.org"

but the API continued returning:

"api_base_url": null

The Python code was working correctly.

The problem was Docker Compose: the environment variable from the host wasn't being forwarded to the API container.

The fix was to explicitly pass it:

environment:
  NICOLA_COMICS_BASE_URL: "${NICOLA_COMICS_BASE_URL:-}"

After rebuilding the containers, the same API request returned:

"api_base_url": "https://pilot.example.org"

and:

"detail_url":
"https://pilot.example.org/api/comics/n4k48-comic-001"

That gave us a useful intermediate verification: the adapter is still running locally, but its URL-generation behavior is ready to be configured for a separate public hosting environment.

What is verified — and what isn't

At this point we have verified:

✓ Docker deployment locally
✓ comic catalog
✓ gallery
✓ comic detail
✓ NFT candidate selection
✓ next-step reporting
✓ configurable API base URL
✓ Docker environment propagation
✓ read-only integration boundary

Still pending:

○ real public HTTPS deployment
○ public Zorgax → pilot connection
○ hosting authentication/authorization
○ rights verification
○ on-chain transaction
○ NFT mint verification

Keeping those two lists separate is one of the most important parts of the experiment.

A prototype shouldn't claim capabilities simply because they're part of the roadmap.

The next milestone

The next test will move the same adapter from the local environment to a reachable HTTPS endpoint.

Then the goal is to verify the complete public flow:

User request
      ↓
Public Zorgax
      ↓
Nicola Comics adapter
      ↓
Gallery
      ↓
Comic detail/card
      ↓
Published image
      ↓
NFT candidate
      ↓
Rights / verified on-chain status

The adapter remains read-only during this phase.

Only after rights and the blockchain step have actually been completed and verified should the project move from NFT candidate to a real minted asset.

For me, that's the interesting part of this pilot: not simply putting a comic “on Web3”, but building a small, reproducible path where every transition has an explicit and verifiable state.

Nicola / N4K48

opensource #python #docker #api #web3 #ai #buildinpublic

N4K48 Project Planner AI/Zorgax

Nicola Lorenzini — Fri, 04 Sep 2026 16:04:23 +0000

N4K48 Project Planner AI/Zorgax

Build and publish a digital product in seven days with an AI guide that organizes the work, identifies mistakes and recommends the next action.

N4K48 Project Planner is an experimental product-planning assistant developed as part of the MyZubster journey.

It is designed for people who want to create a digital product but struggle with too many steps, unclear priorities, deadlines and mistakes discovered too late.

The planner helps users:

define one concrete objective;
divide the objective into manageable activities;
understand what to do next;
identify missing or incorrect steps;
monitor deadlines and progress;
document completed work and supporting evidence;
prepare a product for publication.

Zorgax represents the AI guidance layer. Its role is to assist with planning, analysis and error detection while keeping important decisions under human control.

Seven-day outcome

The initial test asks one practical question:

Can an AI-guided project planner help someone produce a concrete and verifiable result within seven days?

Current status

Product idea defined
Public GitHub documentation available
N4K48 identity and visual profile published
MyZubster authenticated flow tested
22 automated tests passed
First public DEV.to article published
Seven-day product test in progress
User validation still partial
Public production release not yet available

Links

GitHub profile: https://github.com/nicolaususnicola-lgtm
MyZubster repository: https://github.com/nicolaususnicola-lgtm/myzubster
Independent MVP: https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Public roadmap: https://github.com/nicolaususnicola-lgtm/myzubster/blob/main/ROADMAP_N4K48_METAVERSE.md
DEV.to article: https://dev.to/n4k48/building-n4k48-my-journey-with-myzubster-ai-and-neon-plaza-3nbp

This is an experimental MVP under development. Documentation, visuals and local test results do not by themselves demonstrate production deployment, commercial adoption, external payments or third-party endorsement.

Building N4K48: My Journey with MyZubster, AI and Neon Plaza

Nicola Lorenzini — Fri, 04 Sep 2026 15:36:02 +0000

Building N4K48: My Journey with MyZubster, AI and Neon Plaza

I am building N4K48, my digital identity and personal development path inside the MyZubster ecosystem.

N4K48 is more than a profile picture or a fictional character. It is a way to connect my technical work, experiments with artificial intelligence, open-source contributions and the visual world of Neon Plaza.

My goal is to build everything in public and clearly separate working software from concepts, future plans and visual storytelling.

What is N4K48?

N4K48 is designed as a persistent and recognizable identity.

Instead of creating a temporary guest character every time someone enters the experience, the system connects the character to an authenticated account. The server—not the browser—determines the verified identity.

The current flow is:

Identity → Authentication → Persistent Profile → Neon Plaza → AI

This foundation can later support shared spaces, interactions, observations and AI-assisted experiences.

What we have completed

The following components have been implemented and tested:

a persistent N4K48 character profile;
JWT-based authentication;
a clear distinction between guests and authenticated accounts;
authenticated access to Neon Plaza;
server-side identity protection;
rejection of invalid tokens instead of silently treating them as guest sessions;
automated coverage of the authenticated flow;
public documentation and a development roadmap.

The latest recorded verification completed:

Test Suites: 4 passed
Tests:       22 passed
Tests failed: 0

These results verify the tested local behavior. They do not mean that the complete platform is already production-ready.

Two connected repositories

My work is currently documented across two public repositories.

MyZubster development fork

The main repository contains the authenticated Metaverse flow, persistent profile, roadmap and detailed N4K48 documentation:

👉 nicolaususnicola-lgtm/myzubster

You can also read the public roadmap:

👉 N4K48 Metaverse Roadmap

And the detailed project documentation:

👉 N4K48 Project README

Independent MyZubster MVP

The second repository explores a smaller technical MVP with:

an API for recording observations;
configurable JSON persistence;
automated end-to-end tests;
Docker support and health checks;
local AI with Ollama;
vector search with Qdrant;
retrieval-augmented generation based on stored observations.

👉 nicolaususnicola-lgtm/myzubster-mvp

AI and Zorgax

Zorgax represents the AI and operational guidance layer of the project.

The purpose of AI is not to replace verification. It should help organize information, retrieve relevant observations, explain results and guide users through a workflow.

The principle is simple:

Observe → Document → Connect → Measure → Verify → Publish

Visuals and storytelling explain the journey. Code, tests, commits and evidence demonstrate what has actually been completed.

The product direction

The broader idea is to explore how AI can assist users inside MyZubster, including future workflows connected to digital identity, verified activity and value exchange.

Any payment or reward component must remain transparent and evidence-based. A contribution, issue, pull request or internal ledger entry is not automatically proof of an external payment.

This distinction is important when building an open and trustworthy product.

What comes next?

The next development priorities are:

complete GitHub OAuth in the frontend;
implement logout and session-expiration handling;
test Neon Plaza with multiple simultaneous sessions;
verify presence and online-user counting;
complete security and privacy checks;
deploy a reproducible staging demo.

N4K48 is still an MVP under development, but the technical foundation, documentation and public identity are now in place.

Follow the journey

You can follow my progress through my GitHub profile:

👉 github.com/nicolaususnicola-lgtm

I will continue documenting what works, what still needs validation and what I learn while building N4K48 with MyZubster and AI.

If you are interested in open source, AI, authenticated digital identities or experimental virtual environments, feedback and technical discussion are welcome.

DEV Community: Nicola Lorenzini

MyZubster MVP — Dev Update: dal Ledger al Revenue & Cost Simulator

MyZubster #N4K48 #BuildInPublic #DevLog #AI #SoftwareDevelopment #FinTech #Zorgax #MVP

🛠️ MyZubster: Moving from Generative RAG to Evidence-First AI

AI #RAG #LLM #Ollama #Qdrant #Python #Flask #Docker #SoftwareEngineering #AIEngineering #MyZubster

🚀 **DEV UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline**

Come funziona

Cosa abbiamo cambiato

Knowledge Base

Test

Evidence first

Next

MyZubster #RAG #LocalAI #Ollama #Qdrant #Mistral #AI #OpenSource #Docker #Python #N4K48 #Zorgax #DevLog

🛠️ MyZubster Dev Update — Local AI + RAG

What changed?

Next step

MyZubster #LocalAI #RAG #Ollama #Mistral #Qdrant #N4K48 #Zorgax #OpenSource #DevUpdate

From Docker to Real Services: My Learning Journey with MyZubster

From Docker to Real Services: My Learning Journey with MyZubster

🚚 Need help with a move?

🧠 Want to learn from my driving experience?

💻 What I learned while building

🥛 Where kefir fits in

🔗 Choose your next step

💬 Help me test the experience

🧪 **DEV LOG — From a Physical Kefir Handover to a Verified Digital Record**

🥛 1. Physical handover

🧑‍💻 2. Testing the recipient flow

✅ 3. Digital record completed

🔎 What we actually verified

MyZubster #N4K48 #BuildInPublic #DevLog #SoftwareDevelopment #API #Zorgax #Blockchain #WebDevelopment #DigitalIdentity #OpenSource

From GitHub to a Real-World Pilot: Building N4K48 MyZubster

From GitHub to a Real-World Pilot: Building N4K48 × MyZubster

1. Turning an idea into a visual story

2. Turning images into a catalog

3. Exposing the catalog through an API

4. Running the project with Docker

5. The bug our local tests missed

6. Testing the catalog and adapter

7. A second pilot: an in-person kefir handover

8. What remains before public integration

What I’m learning

🚀 **DEV UPDATE — Nico Comics MyZubster**

NicoComics #N4K48 #MyZubster #Zorgax #BuildInPublic #DevLog #OpenSource #AI #WebDevelopment #Blockchain #NFT

MyZubster MVP: from an idea to a live decentralized green ecosystem

MyZubster MVP: From an Idea to a Live Decentralized Green Ecosystem

🌱 What is MyZubster?

🎨 Nicola Comics

🤖 The Zorgax bridge

🛠️ The current stack

🚀 Try MyZubster

🔭 What comes next?

Building a Read-Only Comics Adapter for MyZubster: From Local Prototype to a Public-Ready Pilot

Building a Read-Only Comics Adapter for MyZubster: From Local Prototype to a Public-Ready Pilot

The pilot

A small API for Zorgax

Testing the complete local flow

Gallery

Detail

NFT candidate

Next steps

Preparing the adapter for a public environment

An interesting Docker issue

What is verified — and what isn't

The next milestone

opensource #python #docker #api #web3 #ai #buildinpublic

N4K48 Project Planner AI/Zorgax

N4K48 Project Planner AI/Zorgax

Seven-day outcome

Current status

Links

Building N4K48: My Journey with MyZubster, AI and Neon Plaza

Building N4K48: My Journey with MyZubster, AI and Neon Plaza

What is N4K48?

What we have completed

Two connected repositories

MyZubster development fork

Independent MyZubster MVP

AI and Zorgax

The product direction

🚀 DEV UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline

🧪 DEV LOG — From a Physical Kefir Handover to a Verified Digital Record

🚀 DEV UPDATE — Nico Comics MyZubster