DEV Community: Nicola Lorenzini

From a Local MVP to an Independently Operated Node: N4K48 ↔ MyZubster Interoperability Is Now TESTED

Nicola Lorenzini — Wed, 07 Oct 2026 16:29:01 +0000

From a Local MVP to an Independently Operated Node: N4K48 ↔ MyZubster Interoperability Is Now TESTED

Over the last few weeks, I have been working on a question that sounds simple but becomes much more interesting once you try to prove it:

Can an independently operated MyZubster MVP communicate with the wider MyZubster ecosystem without sharing its filesystem, database, or local administrative control?

Today, I can document a concrete answer:

Yes — for a bounded technical interoperability path, this has now been TESTED.

This is not a claim that the architecture is fully decentralized.

It is not yet direct peer-to-peer communication.

It is not a production-readiness or security-certification claim.

What we have instead is something I consider much more useful at this stage of development:

a reproducible technical checkpoint backed by code, hashes, tests, public evidence, and an explicit list of what remains unproven.

Where N4K48 started

My independent development repository is:

N4K48 / MyZubster MVP

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

The wider MyZubster ecosystem is developed here:

MyZubster Ecosystem

https://github.com/MyZubster-Ecosystem/myzubster

My local MVP has gradually evolved into an evidence-first experimental environment combining several components:

observation and provenance APIs;
semantic retrieval with Qdrant;
local AI through Ollama;
an OpenAI-compatible RAG interface;
Zorgax read-only interaction;
a local experimental MYZ ledger;
economic simulation;
the Nicola Comics catalog;
Docker-based service isolation;
deterministic tests around evidence retrieval.

The principle behind the project has remained simple:

retrieval is not truth, generation is not evidence, and a successful demo is not automatically proof of a larger architectural claim.

That principle became particularly important when we started working on interoperability.

The interoperability challenge

Running software locally is one thing.

Running two environments under different administrative boundaries and proving that they can exchange a bounded job and result is something else.

The tested path is:

MyZubster VPS

→ authenticated Bridge / broker

→ contributor-controlled N4K48 Docker agent

→ local MyZubster catalog

The N4K48 environment remains independently administered.

The Bridge does not receive access to my local filesystem or database.

The agent communicates through a deliberately constrained interface and retrieves the required information from the local catalog API.

That distinction matters.

The objective was not to simulate decentralization by putting several containers on one machine.

The objective was to begin separating administrative control.

The live test

A controlled interoperability test was performed between the MyZubster VPS infrastructure and my N4K48 environment.

The remote Bridge created a bounded gallery job.

My independently running N4K48 agent received it, contacted the local catalog and returned four expected catalog entries.

The observed titles were:

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

The result reached the Bridge with:

state: done

Repeated reads during the permitted TTL returned the same result.

After expiration, the Bridge returned:

{"error":"expired"}

That TTL behavior is important because interoperability is not only about obtaining a successful response.

The lifecycle of the response must also behave predictably.

The upstream MyZubster checkpoint is publicly documented here:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1545#issuecomment-6041485188

My detailed N4K48 interoperability record is here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_INTEROPERABILITY_2026-10-07.md

Verifying the software that actually ran

I did not want the test to depend only on statements such as “the container was running” or “it looked correct.”

The N4K48 agent used for the checkpoint has this SHA-256:

75ab34d21f668fa48383ac7070c717b074c868694c3042928e4532b5ccd34fa1

The hash was verified inside the running Docker container.

The agent ran without publishing network ports.

The local catalog remained behind the contributor-controlled environment.

This gives us a much more precise statement than simply saying two systems were “connected.”

We can identify the artifact that ran and compare it against the expected artifact.

Hardening the node after the interoperability test

Passing the first test created another question:

How should an independently operated node handle its Bridge credential?

The first rule was straightforward:

credentials do not belong in Git.

After the controlled live test, the plaintext token was removed.

The encrypted credential was moved outside the repository.

The test container was stopped.

The host environment variables used for the Bridge session were cleared.

The repository was then checked again to ensure that credential material had not accidentally become an untracked Git artifact.

But I wanted to go further.

Moving the local credential to Windows DPAPI

The N4K48 environment currently runs on Windows with Docker.

For the next local hardening step, I migrated the node token to Windows DPAPI using the CurrentUser protection scope.

The resulting credential is stored outside the Git repository.

The important boundary is:

the repository contains the launcher logic, not the credential.

The DPAPI-protected credential can be decrypted by the appropriate Windows user when the node needs to start.

No plaintext token file needs to live inside the project.

I then built a PowerShell launcher that:

retrieves the DPAPI-protected credential;
decrypts it for the current user;
keeps the plaintext credential in memory;
starts the N4K48 Docker agent;
passes the required Bridge configuration;
verifies the SHA-256 of /app/agent.py;
clears the host environment variables afterward;
clears the local byte buffer used for the decrypted credential;
refuses to create a second agent when one already exists.

This was tested end-to-end.

The resulting node started successfully.

The agent hash matched.

No host port was published.

After startup, the Bridge token, Bridge URL and local catalog configuration were no longer present as environment variables in the parent PowerShell session.

The container was subsequently stopped and, because it runs with --rm, removed automatically.

This is not presented as the final secret-management architecture.

The running Docker container still requires access to its authentication material.

For a future persistent deployment I want explicit credential rotation, revocation and a more complete managed secret lifecycle.

But compared with storing a token in the repository or leaving plaintext credentials on disk, this is a meaningful operational improvement.

Testing the checkpoint

After the lifecycle changes, I reran the tests.

N4K48 Bridge agent tests:

13 / 13 passed

Complete MyZubster MVP test suite:

77 / 77 passed

I also ran Git whitespace/diff validation before creating the checkpoint.

The new checkpoint is:

89ca1b5 — feat: harden N4K48 bridge agent lifecycle

It contains:

bridge/Dockerfile
bridge/agent.py
bridge/test_agent.py
scripts/start-n4k48-agent.ps1

The checkpoint is available on:

pilot/n4k48-tested-checkpoint

Repository:

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

What has actually been demonstrated?

I think this is the most important section.

Software projects — especially projects involving AI, distributed systems, blockchain or decentralization — can easily move from a successful experiment to claims much larger than the evidence supports.

So here is the boundary.

TESTED

We have tested technical interoperability between:

a MyZubster VPS-side Bridge and an independently administered N4K48 environment.

The test crossed an administrative boundary.

The N4K48 node processed an authenticated remote job.

It retrieved information from its own local environment.

It returned the expected result.

The Bridge observed the result lifecycle through expiration.

The agent artifact was hash-verified.

The implementation has automated tests.

The credential is not stored in the Git repository.

NOT YET PROVEN

This does not prove:

complete decentralization;
direct contributor-to-contributor P2P networking;
elimination of the central Bridge/broker;
Byzantine fault tolerance;
production readiness;
security certification;
general scientific or clinical validity;
unrestricted interoperability with every MyZubster contributor.

Those are separate checkpoints.

And they should remain separate until they are actually tested.

Why I think the administrative boundary matters

Docker alone does not make software decentralized.

Running five containers on one administrator's server is still one administrative domain.

For me, the more interesting transition begins when independently controlled environments can communicate using a defined protocol without requiring shared:

filesystems;
databases;
operating-system privileges;
administrator accounts;
private infrastructure access.

That is why I consider this interoperability checkpoint important.

It is not the destination.

It is evidence that we can start moving toward it.

The next step: a second independent contributor

The next major checkpoint is intentionally harder.

I want to reproduce interoperability with a second independently administered contributor environment.

The proposed test is consent-gated.

No contributor should be silently enrolled into an experiment simply because their GitHub account appears somewhere in an ecosystem.

Before a second-node test, the participating contributor must explicitly opt in and the test must freeze:

repository;
branch;
commit;
protocol/fixture version;
expected result;
test commands;
evidence format;
limitations;
rollback/stop procedure.

The environment must genuinely be independently administered.

It must not share the N4K48 filesystem, database or administrative privileges.

The proposed second-contributor test plan is public here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/SECOND_CONTRIBUTOR_INTEROPERABILITY_TEST_PLAN.md

The wider contributor discussion is here:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1520

Only after a reproducible second-node PASS should I describe that checkpoint as tested.

Toward Bridge Protocol v1

There is another problem that becomes visible as soon as a second node enters the picture.

If interoperability depends on undocumented assumptions, it does not scale.

We therefore need to freeze the contract between Bridge and node.

I have started a draft for:

N4K48 Bridge Protocol v1

The current proposal covers concepts including:

protocol versioning;
job envelopes;
job IDs;
leases;
actions;
payloads;
expiration;
result envelopes;
capability negotiation;
error semantics;
authentication boundaries;
conformance fixtures;
credential lifecycle.

The draft is here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_BRIDGE_PROTOCOL_V1_DRAFT.md

And the word DRAFT matters.

The exact wire contract still needs joint review and agreement before it should be called a stable protocol.

From interoperability toward federation

My longer-term technical path now looks approximately like this:

Local MVP

→ independently administered N4K48 node

→ authenticated Bridge interoperability — TESTED

→ stable Bridge protocol

→ second independent node

→ cross-node evidence verification

→ redundant delivery routes

→ broker failure testing

→ federation

→ measurable decentralization criteria

This is a slower way to use the word “decentralized.”

I think it is also a more useful one.

Instead of starting with the claim and trying to justify it afterward, I want each architectural property to correspond to an observable test.

If the broker remains a single point of dependency, document it.

If nodes cannot discover each other, document it.

If evidence cannot be independently verified, document it.

If failure recovery has not been tested, document it.

Then build the next experiment.

MyZubster and the evidence-first approach

The wider MyZubster project is available here:

https://github.com/MyZubster-Ecosystem/myzubster

The public repository describes an ecosystem involving evidence and provenance, Zorgax-assisted workflows, participant pilots, community infrastructure and several experimental technical paths.

My N4K48 repository is an independently operated MVP and contributor-side experimentation environment:

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

The relationship I am trying to build between these environments is therefore not “trust everything because it belongs to the same project.”

It is closer to:

produce → identify → exchange → verify → reproduce → then make the claim.

That distinction also matters for AI.

An AI-generated answer is not automatically evidence.

Semantic retrieval is not automatically truth.

A hash proves integrity relative to some bytes; it does not automatically prove that the underlying real-world statement is true.

A blockchain transaction proves that something was recorded according to the properties of that chain; it does not magically validate every semantic claim attached to it.

And a successful distributed-system test proves the bounded behavior that was actually exercised — not every future property of the architecture.

This is the engineering philosophy I want to continue applying to N4K48.

An open invitation to developers

If you work on distributed systems, local-first software, agent interoperability, provenance, verifiable evidence, Docker isolation or decentralized architectures, I would be interested in technical review.

In particular, I would value feedback on:

How should independently administered contributor nodes negotiate capabilities and verify results without turning the central broker into a permanent trust anchor?

That is one of the questions behind the next phase.

You can inspect the code and evidence directly:

N4K48 / MyZubster MVP

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

MyZubster Ecosystem

https://github.com/MyZubster-Ecosystem/myzubster

N4K48 interoperability evidence

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_INTEROPERABILITY_2026-10-07.md

Public VPS ↔ N4K48 PASS checkpoint

https://github.com/MyZubster-Ecosystem/myzubster/pull/1545#issuecomment-6041485188

Bridge Protocol v1 draft

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_BRIDGE_PROTOCOL_V1_DRAFT.md

Second contributor interoperability test plan

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/SECOND_CONTRIBUTOR_INTEROPERABILITY_TEST_PLAN.md

Contributor interoperability discussion

https://github.com/MyZubster-Ecosystem/myzubster/issues/1520

Final thought

This checkpoint is small compared with the architecture I ultimately want to test.

But it is real.

A remote authenticated job crossed from the MyZubster infrastructure into an independently administered N4K48 environment.

The local agent processed it.

The expected catalog result came back.

The lifecycle behaved as expected.

The artifact was hash-verified.

The tests passed.

The credential lifecycle was hardened afterward.

And the remaining limitations are documented rather than hidden.

That is enough for me to call this milestone:

TESTED.

Not “fully decentralized.”

Not “finished.”

Not “production certified.”

Tested. Reproducible. Inspectable. Ready for the next experiment.

And the next experiment is where things become even more interesting:

one Bridge, multiple independently administered nodes — and eventually, no single Bridge that has to be trusted at all.

opensource #decentralization #distributedSystems #docker #ai #interoperability #buildinpublic #github #myzubster #n4k48

From Comics to Code: Building MyZubster One Piece of Evidence at a Time

Nicola Lorenzini — Sat, 03 Oct 2026 20:25:32 +0000

From Comics to Code: Building MyZubster One Piece of Evidence at a Time
It started with a comic.
N4K48 visually represented a journey: a software idea taking shape and imagining its path into the MyZubster metaverse.
Those panels were not screenshots of a finished product. They were not proof of a fully decentralized platform. They were a representation of something we wanted to build.
Then we started turning that narrative into verifiable software.
From Storytelling to Evidence
One of the questions that emerged during development was surprisingly simple:
How can an AI system distinguish between something that was actually recorded and something that merely sounds plausible?
For MyZubster, the answer is increasingly becoming:
Start with evidence.
An observation enters the system with an identifier. It is persisted, indexed, and made searchable.
Qdrant provides semantic retrieval. Ollama provides local AI inference. A RAG layer connects questions, retrieved sources, and generation.
But while testing the system, we discovered something more important than simply proving that “RAG works.”
We saw how easily a language model can take a correct source and still produce an incorrect answer.
For example, MyZubster contains a real observation:
ID: 21089771b2a73a9f
Description: Test reale MyZubster RC2 - N4K48

Semantic retrieval correctly found that observation.
But when we asked the model to describe it, the model could still introduce additional statements that were not supported by the retrieved evidence.
That changed the way we approached the problem.
Retrieval Is Not the Same as Truth
We started separating two problems that are often treated as if they were the same:
Finding information and deciding what the system is allowed to claim based on that information.
We introduced a deterministic path for observation IDs.
If a request contains an existing observation ID, MyZubster prefers the exact observation over semantic similarity.
If the ID looks valid but does not exist, the system does not silently search for something similar and use that as a substitute.
Instead, it returns:
Informazione non disponibile nelle fonti MyZubster.

In English:
Information is not available in the MyZubster sources.

This sounds like a small behavior change.
It is not.
It means that absence of evidence is no longer treated as permission to generate a plausible substitute.
Sometimes the AI Should Not Generate
We found the same problem with descriptions.
When a user explicitly asks for the description contained in the evidence, why should a language model rewrite it?
We tested exactly that.
The correct evidence was:
Test reale MyZubster RC2 - N4K48

Yet a small local model could turn it into a longer response containing claims that were never present in the source.
So we changed the architecture.
When MyZubster can answer an authoritative question directly from the retrieved evidence, it can bypass generation and return the evidence verbatim.
The result becomes:
Test reale MyZubster RC2 - N4K48

Nothing added.
Nothing “improved.”
Nothing invented.
That led us to an important design principle:
When the software already knows the fact, we do not necessarily need AI to reinvent the answer.

AI becomes useful where interpretation and synthesis are actually required—not as an unavoidable intermediary between the user and every piece of stored evidence.
Local AI, Connected to Evidence
The current prototype connects several components:
User
↓
Open WebUI
↓
OpenAI-compatible MyZubster API
↓
Retrieval / deterministic evidence paths
↓
Qdrant
↓
MyZubster evidence
↓
Ollama when generation is actually needed
↓
Answer

We exposed the MyZubster RAG system through an OpenAI-compatible API, allowing Open WebUI to use myzubster-rag as a model.
That gave us a practical end-to-end environment in which we could test the entire path from the user interface to the underlying evidence.
And the tests uncovered real architectural problems.
At one point, an observation existed in persistent storage but was missing from Qdrant.
That exposed another important distinction:
stored data and searchable data are not automatically the same thing.
So we added an explicit observation-index recovery mechanism capable of rebuilding the search index from persisted observations.
Again, this is not primarily about making a chatbot answer questions.
It is about being able to understand where an answer came from and whether the underlying evidence can be recovered.
From Software to Decentralization
This is where decentralization enters the story.
And this distinction matters:
MyZubster does not become decentralized simply because we use local AI, hashes, identifiers, or an internal ledger.
A digitally recorded event is not automatically a blockchain event.
A database entry is not automatically decentralized evidence.
We have deliberately tried to preserve those distinctions in the prototype.
The more interesting question is:
If evidence originates inside MyZubster today, how could someone verify it tomorrow without having to blindly trust MyZubster itself?

That is where decentralization becomes meaningful.
Hashes, provenance, identities, attestations, and externally verifiable records can eventually allow evidence to move beyond the trust boundary of a single application.
But before decentralizing evidence, we need to know exactly what is being attested.
That is one reason we are building the evidence layer first.
Decentralization without provenance can simply distribute uncertainty.
From the Comic to the Commit History
The N4K48 comic represented a vision.
The software is slowly turning parts of that vision into properties we can actually test.
Some of the latest checkpoints tell that story:
16f0800 fix: add observation index recovery
d1aa48f fix: prefer exact observation ID retrieval
8106276 fix: reject unknown observation IDs safely
87a1021 fix: return authoritative descriptions verbatim

The interesting part is not the commit count.
It is the progression.
First, recover the evidence.
Then make sure an exact identifier retrieves the exact evidence.
Then make sure a nonexistent identifier cannot silently become “something similar.”
Then prevent the language model from rewriting an authoritative description when no generation is necessary.
Each step removes a little ambiguity from the system.
Evidence First, Generation Second
This is gradually becoming one of the core ideas behind MyZubster:
Observe
↓
Record
↓
Preserve
↓
Retrieve
↓
Verify
↓
Generate only when necessary

Most AI systems are designed around the final step.
We are increasingly interested in everything that happens before it.
Because an eloquent answer is not necessarily a grounded answer.
A semantically similar document is not necessarily the requested evidence.
A model saying something confidently does not turn it into a recorded fact.
And a decentralized record is only useful if we understand what that record actually proves.
Where This Is Going
The goal of MyZubster is not to build an AI that appears to know everything.
The more interesting goal is to build a system that becomes increasingly capable of distinguishing between:
what was observed,
what was recorded,
what can be retrieved,
what can be verified,
and what the AI generated.
There is still a lot to solve.
Generic semantic questions can still retrieve partially relevant context. Small local models can still infer things that the evidence does not say. Provenance can become stronger. Verification can extend beyond the boundaries of one application. And decentralization remains a direction to build and test rather than a label to attach prematurely.
But that is exactly why this journey is interesting.
It started with comic panels imagining a world.
Now we are working on the less spectacular—but perhaps more important—part:
giving that world a verifiable memory.
From comics to evidence.
From evidence to software.
From software to verification.
From verification toward decentralization.
And this time, every step should leave evidence behind.

Building Verifiable Knowledge in MyZubster: From Stable Evidence IDs to Proof v3

Nicola Lorenzini — Wed, 30 Sep 2026 22:49:47 +0000

Building Verifiable Knowledge in MyZubster: From Stable Evidence IDs to Proof v3
Tonight I worked on a part of MyZubster that I find particularly interesting: making a Knowledge Card not only readable, but traceable and verifiable.
The task started as a relatively focused frontend issue and ended up touching several important concepts: stable evidence identity, deduplication, versioned proofs, cryptographic digests, blockchain attestations, deployment verification, and contributor rewards.
The result is now running in production.
The starting point
MyZubster has a Knowledge Graph where a Knowledge Card can be connected to multiple pieces of evidence.
For the card used during this work:
6abaaefb3a7460c4574a45fd
the graph contains normal sources as well as cryptographic proof information.
The first requirement was deceptively simple:
When selecting the Proof filter, both Proof v2 and Proof v3 should appear as separate and independently identifiable attestations.

But there were several constraints.
Normal evidence had to remain normal evidence.
Proof records had to be recognized separately.
Proof v2 history could not be rewritten just to accommodate v3.
Duplicate URLs could not produce duplicate nodes.
And the stable IDs introduced in the previous work had to remain stable across refreshes and reimports.
In other words, this wasn't simply:
if label contains "proof":
show proof

That would have been fragile.
Stable evidence identity first
Before working on Proof v3, the graph already had another important improvement: evidence nodes were given stable SRC-* identifiers.
That matters more than it might initially appear.
If a graph generates arbitrary node identities every time data is imported, refreshed or reordered, the visual representation may look correct while its identity model is unstable.
For evidence systems, that's a problem.
A source should remain the same source when the page reloads.
So the model became conceptually:
Knowledge Card
|
+-- SRC-...
+-- SRC-...
+-- SRC-...

with deterministic identity rather than presentation-dependent identity.
That foundation became important when introducing versioned proofs.
Proof is not just another source
The next problem was classification.
A Knowledge Card can have ordinary evidence:
source
source
source

but it can also contain evidence describing an attestation:
digest
contract
transaction
documentation
payload

Those records collectively describe something different from a normal source.
They describe a proof.
The implementation therefore moved toward recognizing structured fields where available, such as concepts equivalent to:
type: proof
proofVersion: 3
proofRole: digest

rather than relying exclusively on human-readable labels.
Textual detection remains useful as a fallback for legacy data, but structured metadata is considerably safer.
The important distinction becomes:
normal evidence → source

versioned attestation evidence → proof

Grouping evidence into versioned proofs
Once proof evidence can be recognized, individual records can be grouped by version.
Conceptually:
Proof v2
├── digest
├── contract
├── transaction
└── documentation

Proof v3
├── digest
├── contract
├── transaction
└── documentation

This is much more useful to a reader than exposing every technical reference as an unrelated graph node.
The graph can represent the attestation as an object, while still retaining the references required to inspect it.
The Proof v3 attestation
The Proof v3 used for this Knowledge Card includes a SHA-256 digest and an Ethereum Sepolia attestation.
The digest is:
d1c89d2a4157a159b56e92825ca59fdb
1f0e84e003b05e022af67da69ed25ac4

The Sepolia contract is:
0x3233fA7f8c50Aa25d9B1263c25F28535B6eA59bF

and the deployment/attestation references can be associated with the corresponding payload and documentation.
The important idea isn't simply that "something is on a blockchain."
The useful relationship is:
Knowledge
↓
canonical payload
↓
SHA-256
↓
attestation
↓
independent verification

The blockchain reference doesn't magically prove that the knowledge itself is true.
What it can help establish is that a particular cryptographic commitment existed and can be compared against a particular payload.
That distinction is essential in any serious provenance system.
A bug that looked correct until the graph was inspected
After the first implementation, the deployment built successfully, but visual verification revealed an interesting problem.
The Proof filter showed something equivalent to:
Proof v2
Proof v2
SRC-...
SRC-...
SRC-...

while Proof v3 wasn't represented correctly.
There were actually two different problems.
The historical Proof v2 path already existed, while dynamically grouping evidence created another v2 representation.
At the same time, raw evidence used to construct a proof remained visible as ordinary SRC-* nodes.
So even though the underlying information existed, the semantic representation was wrong.
That is why visual acceptance testing mattered here.
Unit tests alone weren't enough.
Deduplicating the graph
Once evidence has been aggregated into a proof object, exposing the exact same evidence again as raw graph nodes creates noise and potentially misleading duplication.
The graph therefore needed another rule:
if evidence has already been consumed by a grouped proof:
don't render it again as an independent source

The final Proof view became much cleaner:
PROOF V3
|
|
K-4A45FD
/ \
/ \
PROOF V2 SHA-256

No duplicate Proof v2.
No raw proof SRC-* nodes leaking into the Proof filter.
And, importantly, Proof v3 is visibly connected to the Knowledge Card.
The isolated-node problem
One of the final bugs was purely structural.
Proof v3 existed.
It rendered correctly.
Its metadata was correct.
But visually it was floating above the Knowledge Card without an edge.
That may sound cosmetic, but in a knowledge graph an edge carries meaning.
A node that isn't connected to the card doesn't clearly communicate:
this proof attests to this Knowledge Card

So the edge construction was extended to include versioned proof nodes.
After redeployment, the intended relationship became visible:
K-4A45FD → PROOF V3

while preserving the historical Proof v2 chain.
CI also taught us something
During the work, several repository-wide CI workflows failed.
It would have been easy to interpret:
red CI = my change is broken

But inspecting the logs showed failures in existing Zorgax/Seller-related backend tests unrelated to the Knowledge Graph modification.
That distinction matters.
A contributor shouldn't ignore failing CI.
But a contributor also shouldn't start modifying unrelated systems simply to turn every check green.
The useful workflow was:
CI fails
↓
inspect exact failing suites
↓
determine relationship to current diff
↓
fix regressions caused by the change
↓
keep unrelated failures separately tracked

This prevented MYZ-209 from expanding into an unrelated backend repair project.
Preview before merge
Another useful part of the workflow was refusing to treat a successful build as final acceptance.
The sequence was approximately:
implementation
↓
tests
↓
Vercel preview
↓
visual graph verification
↓
fix
↓
new preview
↓
final verification
↓
merge

Daniel Ioni performed the final preview verification and confirmed that the Proof filter contained the expected distinct nodes without duplicates.
Only then was the PR merged.
PR:

25

MYZ-209: expose versioned Proof v3 in Knowledge Graph

Merge commit:
157fc5edf7440a732c489a918efe6be8e34888c3

Production verification
After the merge and production deployment, I performed another verification against the public Knowledge Card.
The production Proof filter now shows:
PROOF V3
MyZubsterProof v3 · Sepolia

SHA-256
Digest del payload

PROOF V2
MyZubsterProof · Sepolia

There are no duplicate raw proof sources in that filtered view.
The Knowledge Card is visibly connected to Proof v3.
And switching back to the complete graph shows Proof v2 and Proof v3 coexisting with the ordinary SRC-* evidence nodes.
So the production result matches the verified preview.
MYZ-209 is complete.
What I learned from this
The interesting part of this task wasn't adding another node to a React page.
It was dealing with the boundary between data, evidence and proof.
These concepts shouldn't be collapsed into one another.
A source can support knowledge.
A digest can identify a payload.
An attestation can commit to a digest.
A transaction can provide independently inspectable evidence that an attestation occurred.
But none of those things, individually, should be described as magically proving that a statement is true.
A more useful model is:
KNOWLEDGE
|
+--- SOURCES
|
+--- PROVENANCE
|
+--- PAYLOAD
|
SHA-256
|
ATTESTATION
|
VERIFICATION

That is the direction I want to keep exploring with MyZubster.
Contributor rewards
There was also another interesting outcome from this contribution.
After MYZ-209 was accepted, I asked whether the contribution qualified for a MyZubster contributor reward.
Daniel confirmed a reward of:
250 MYZ

for:
N4K48 / nicolaususnicola-lgtm

One important clarification: under the current MyZubster model, MYZ is an internal reward/accounting unit. It should not be confused with an on-chain token, fiat payment or guaranteed conversion into another asset.
A ledger reference, MYZ-LEDGER-000002, was communicated for this contribution.
At the time of writing, however, I have not yet independently located that entry in the public repository, so I'm treating the reward assignment as confirmed by the maintainer while the public ledger reference is still awaiting independent verification.
I think that distinction is worth publishing rather than hiding.
If we're building systems around verifiable knowledge, the same standard should apply to contributor rewards.
Claim what the evidence supports. Clearly label what is still pending verification.
What's next?
The next step isn't simply adding more proofs.
It's making the relationship between knowledge, evidence, provenance and attestations increasingly structured and independently inspectable.
For me, that's the interesting question behind this work:
Can a knowledge platform show not only what it knows, but also why a claim is present, where its evidence came from, which payload was attested, and how someone else can verify that history?

Tonight's work moved MyZubster another step in that direction.
Project: MyZubster
Task: MYZ-209
Contribution: Proof v3 visibility and versioned proof handling
Contributor: N4K48 / nicolaususnicola-lgtm
Status: merged and verified in production
Reward: 250 MYZ confirmed; public ledger entry awaiting independent verification

opensource #react #web3 #blockchain #provenance #knowledgegraph #javascript #buildinpublic

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

Nicola Lorenzini — Wed, 30 Sep 2026 20:52:34 +0000

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

Over the last few weeks, I've been experimenting with a simple question:

Can the things I learn and build become verifiable evidence instead of just claims on a profile?

Together with the MyZubster project and with AI-assisted development, I built and tested a proof-of-concept that connects local software experiments, GitHub evidence, a Knowledge Card, cryptographic hashing and Ethereum Sepolia.

The current flow looks like this:


text
N4K48
  ↓
real work and local tests
  ↓
GitHub evidence
  ↓
MyZubster Knowledge Card
  ↓
canonical payload
  ↓
SHA-256
  ↓
Ethereum Sepolia
  ↓
Knowledge Proof Verifier
  ↓
Knowledge Graph

This is still an experiment, but we now have a complete reproducible path.
1. Starting locally: Docker + AI + RAG
The work started inside myzubster-mvp.
I built and tested a local environment involving:
- Docker / Docker Compose
- Ollama
- Qdrant
- Open WebUI
- Python / Flask APIs
- local knowledge ingestion
- RAG retrieval
One of the concrete improvements was changing the knowledge chunking and testing a new ingestion.
The resulting ingestion loaded 46 knowledge chunks into Qdrant while skipping one empty document.
I also tested retrieval through the API and adjusted the AI context limit so the expected GitHub context could be retrieved.
Repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
2. Turning the work into a Knowledge Card
Instead of describing this work only in a README or profile, I created a public MyZubster Knowledge Card:
https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd
The card connects the activity to supporting evidence such as:
- the repository;
- commits;
- local test descriptions;
- Proof documentation;
- Ethereum contracts;
- deployment transactions;
- the Knowledge Proof Verifier.
The important idea is that the profile claim and the evidence remain separate.
The evidence supports inspection.
It doesn't automatically certify the claim.
3. Proof v1: proving the URL
The first Ethereum experiment was intentionally simple.
I calculated a SHA-256 digest from the Knowledge Card URL and stored it in a small Solidity contract on Ethereum Sepolia.
That proved that I could create a public on-chain anchor.
But it also exposed an important limitation:
hashing the URL is not the same as hashing the content.
So we moved to a second version.
4. Proof v2: hashing the canonical payload
For Proof v2, I created a stable JSON representation of the Knowledge Card.
Instead of hashing the URL, the system hashes the exact payload bytes.
The SHA-256 was:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

That value was stored as bytes32 in a new Sepolia contract.
The public knowledgeHash() value could then be read and compared with the locally calculated digest.
This was much closer to the model I wanted:
content
  → exact bytes
  → SHA-256
  → bytes32
  → public blockchain

5. Building a repeatable verifier
Manually comparing hashes is useful during an experiment, but it isn't a good verification interface.
So the next step was MYZ-213: a repeatable Knowledge Proof Verifier.
The verifier:
1. reads the exact saved payload bytes;
2. calculates SHA-256;
3. reads knowledgeHash() from the Sepolia contract;
4. compares the values;
5. reports one of the meaningful outcomes:
MATCH
NO_MATCH
ERROR

It also includes tests for an altered payload and an unavailable RPC endpoint.
The verifier was merged through PR #16:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/pull/16
No private key is required for verification.
No signature is required.
No transaction is required.
Verification uses public, read-only Ethereum RPC calls.
6. Proof v3: verifying the updated knowledge payload
After adding the new development evidence, I created a third payload.
The exact committed v3 payload is:
proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v3.json

Size:
5083 bytes

SHA-256:
d1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4

I reproduced this digest locally using both sha256sum and Python hashlib.
Then I deployed another MyZubsterProof contract to Ethereum Sepolia.
Contract:
0x3233fA7f8c50Aa25d9B1263c25F28535B6eA59bF

Deployment transaction:
0x5c7717be6dc70e6416f8053c72bb1e2bec2b7c5462b23fcb9c4b1077f907fed4

Reading the contract directly returned:
0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4

Exactly the same value as the locally calculated payload digest.
Then I ran the Knowledge Proof Verifier.
The result was:
{
  "status": "MATCH",
  "payload_sha256": "d1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "calculated_bytes32": "0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "onchain_bytes32": "0xd1c89d2a4157a159b56e92825ca59fdb1f0e84e003b05e022af67da69ed25ac4",
  "payload_matches_onchain": true,
  "payload_matches_expected": true,
  "network": "Ethereum Sepolia",
  "chain_id": 11155111
}

That was the key milestone.
The same value existed in:
committed payload
      ↓
local SHA-256
      ↓
expected bytes32
      ↓
Sepolia knowledgeHash()

And the verifier returned:
MATCH

Proof v3 documentation:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/SEPOLIA_PROOF_V3.md
7. Connecting it to a Knowledge Graph
The next layer is the MyZubster Knowledge Graph.
The goal is to make this path navigable:
N4K48
 ↓
Knowledge Card
 ↓
contribution
 ↓
GitHub evidence
 ↓
payload
 ↓
SHA-256
 ↓
Ethereum proof

During testing we confirmed that the graph contains a single N4K48 node and a single node for the Knowledge Card.
We also found something useful:
after updating the Knowledge Card with the latest GitHub evidence, the new sources were not yet automatically reflected in the graph.
That's not something to hide.
It's exactly the kind of integration issue this pilot is designed to discover.
The automatic synchronization between updated Knowledge Cards and graph evidence still needs work.
8. What does MATCH actually prove?
This distinction is important.
A MATCH does not mean:
"Everything this person says is true."

It does not automatically certify a professional skill.
It does not automatically prove identity or ownership of every linked artifact.
What it does demonstrate is much narrower and more technically useful:
The exact payload bytes being verified produce the same cryptographic digest as the value stored in the referenced public blockchain contract.

That gives us integrity and provenance evidence.
Other forms of verification can be layered on top later.
9. What I learned
This project connected several areas that I had previously been testing separately:
- local AI and RAG;
- Docker environments;
- Ollama and Qdrant;
- Python APIs;
- GitHub commits and pull requests;
- CI;
- canonical data representation;
- SHA-256;
- Ethereum read-only verification;
- smart contracts;
- Knowledge Cards;
- Knowledge Graphs;
- AI-assisted development.
More importantly, it changed the way I think about a digital profile.
Instead of:
I say I know X

the model can move toward:
I say I know X
      ↓
here is what I did
      ↓
here is the source
      ↓
here is the artifact
      ↓
here is its fingerprint
      ↓
here is a public attestation
      ↓
verify it yourself

What's next?
There is still plenty to build.
The next steps include improving Knowledge Graph synchronization, finishing more end-to-end testing, simplifying the verification UX, and exploring interoperable attestation and credential standards.
The long-term goal isn't to put every piece of personal information on a blockchain.
It's to make useful evidence easier to inspect, reproduce and verify.
For me, this experiment has already reached an important milestone:
local work became documented evidence, the evidence became an exact payload, the payload became a cryptographic fingerprint, and that fingerprint became independently verifiable on a public network.
I'm building this publicly as N4K48.
GitHub:
https://github.com/nicolaususnicola-lgtm
MyZubster:
https://www.myzubster.com
Knowledge Card:
https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd
The project is experimental and under active development.

From Local RAG to a Verifiable Knowledge Proof on Ethereum Sepolia

Nicola Lorenzini — Mon, 28 Sep 2026 23:39:54 +0000

From Local RAG to a Verifiable Knowledge Proof on Ethereum Sepolia
How I connected Docker, Ollama, Qdrant, GitHub, a MyZubster Knowledge Card and an on-chain SHA-256 proof
Building an AI project is one thing.
Being able to show what was actually built, what was tested, where the evidence is, and whether a documented artifact has changed is another.
During the development of my myzubster-mvp project, I wanted to test a simple idea:
Can we connect a person's documented technical activity to GitHub evidence, an AI/RAG system, a public Knowledge Card, and finally a cryptographic proof recorded on a blockchain?

This experiment became a small end-to-end proof-of-concept involving:

Docker and Docker Compose
Ollama
Qdrant
Open WebUI
a local RAG pipeline
GitHub commits
MyZubster Knowledge Cards
SHA-256
a Solidity smart contract
Ethereum Sepolia
a Knowledge Graph The goal was not to put personal knowledge itself on a blockchain. The goal was to build a verifiable chain between a documented knowledge artifact and a cryptographic commitment to that artifact.
Starting point: my local AI/RAG environment The experiment started inside my public project: Repository: https://github.com/nicolaususnicola-lgtm/myzubster-mvp The local stack combines MyZubster's API with Docker, Ollama, Qdrant and Open WebUI. At a simplified level: Documents / observations ↓ Ingestion ↓ Embeddings ↓ Qdrant ↓ Relevant context ↓ Local LLM through Ollama ↓ MyZubster AI response

One of the important principles behind the project is evidence first.
The AI should not simply generate plausible answers.
Where authoritative structured information exists, that information should remain the source of truth. RAG and the local language model can then operate over the evidence retrieved from the system.

Improving the ingestion pipeline During testing I found that document chunking could be improved. Instead of blindly cutting text, I modified the ingestion process so that it tries to respect paragraph and line boundaries while maintaining overlap between chunks. The change is documented here: Chunking commit: https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/ea80799 After the modification, I performed a new ingestion. The local test resulted in: 46 knowledge chunks loaded into Qdrant 1 empty document skipped

I also tested retrieval through the MyZubster AI endpoint:
/api/ai/ask

During this work I increased the amount of retrieved AI context from 1 to 5 so that the expected GitHub/project information could be recovered more reliably.
This gave me the first part of the evidence chain:
Technical activity
↓
GitHub commit
↓
Local ingestion
↓
Qdrant
↓
RAG retrieval

Turning the work into a Knowledge Card The next step was to describe the work in a public MyZubster Knowledge Card. The card is: “Prove Docker e chat AI del progetto myzubster-mvp” Public Knowledge Card: https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd The card connects the activity to evidence such as the repository, Docker tests, the chunking modification and the later blockchain experiments. This creates another layer: N4K48 ↓ Technical activity ↓ GitHub evidence ↓ Knowledge Card

But at this point there was still an interesting question.
How could I create a cryptographic reference to the Knowledge Card?

Proof v1: anchoring the Knowledge Card URL The first experiment was intentionally simple. I calculated the SHA-256 of the Knowledge Card URL string. That digest was passed to a small Solidity contract deployed on Ethereum Sepolia. The contract was: // SPDX-License-Identifier: MIT pragma solidity ^0.8.20;

contract MyZubsterProof {
bytes32 public knowledgeHash;
address public creator;
uint256 public timestamp;

constructor(bytes32 _knowledgeHash) {
    knowledgeHash = _knowledgeHash;
    creator = msg.sender;
    timestamp = block.timestamp;
}

}

The contract stores three values:
knowledgeHash
creator
timestamp

Proof v1 contract
https://sepolia.etherscan.io/address/0xabCF68e97a32eCa503942A563FF16F209ed45d11#code
Deployment transaction
https://sepolia.etherscan.io/tx/0x09dddd29aca76c9a425ba9cb45cefb1bfbe203b9628f5f9526e4a281012d4f20
GitHub evidence
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/2df5b39
The recorded value was:
0x15b21c4f189259f143f6c946ac866001d88f5bc7aa371cac7cbcc1ce66b43685

The contract source for this first proof was publicly verified on Etherscan as an Exact Match.
But there was an important limitation.
Proof v1 did not hash the Knowledge Card content
It hashed the URL string.
That distinction matters.
The first experiment therefore demonstrated that I could associate a blockchain record with the identifier/location of the Knowledge Card.
It did not cryptographically commit to the complete contents of the card.
So we moved to a second experiment.

Proof v2: anchoring the content For Proof v2, the objective changed. Instead of: Knowledge Card URL ↓ SHA-256

I wanted:
Knowledge Card
↓
Canonical payload
↓
SHA-256
↓
Ethereum Sepolia

The content used for the proof was stored in the GitHub repository so that the artifact being referenced is publicly inspectable.
Canonical payload:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json
The corresponding GitHub commit is:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/ecefd81c5c9da0be15c99aeeb83878480abd60a8

Calculating the SHA-256 The SHA-256 used for Proof v2 is: 6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

As a Solidity bytes32 value:
0x6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

The important point is that the proof refers to the exact payload bytes committed to the repository.
Anyone with those bytes can independently calculate their SHA-256 and compare the result with the value used in the proof.
For example:
sha256sum proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json

Or with Python:
import hashlibfrom pathlib import Pathdata = Path( "proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json").read_bytes()print(hashlib.sha256(data).hexdigest())

The expected result is:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

Registering Proof v2 on Ethereum Sepolia A new MyZubsterProof instance was deployed for Proof v2. Contract https://sepolia.etherscan.io/address/0x21787249Df054132093FcF09bB914C0CCC539390 Deployment transaction https://sepolia.etherscan.io/tx/0xc837ba3f3046f3712e3eba4b81107cb22939b61300f2cab3cfe5bbb7b3319ded Network: Ethereum Sepolia Chain ID: 11155111

After deployment I reconnected to the contract and called:
knowledgeHash()

The returned value was:
0x6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

This matches the digest documented for the committed payload.
That gives us the core verification relationship:
GitHub payload
│
│ SHA-256
▼
6097e05866bafce...
│
│
▼
MyZubsterProof
Ethereum Sepolia
│
│ knowledgeHash()
▼
6097e05866bafce...

Making the proof reproducible A blockchain transaction by itself is not enough for a useful technical experiment. Someone examining the project also needs to understand:
what artifact was hashed;
which digest was expected;
where the artifact is stored;
which contract contains the commitment;
which transaction deployed it;
how to reproduce the hash calculation. For this reason I added dedicated Proof v2 documentation to GitHub: https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/SEPOLIA_PROOF_V2.md Documentation commit: https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/405467e8d7b4e55ea9f18044a00aa66804f3ada3 This turns the blockchain experiment into something closer to a reproducible evidence record rather than an isolated transaction hash.
Updating the main README One problem remained. The evidence existed, but somebody arriving on the repository homepage might never discover it. So I added a dedicated section to the main README: Knowledge Card → Ethereum Sepolia Proof v2 The README now exposes the verification path directly: N4K48 ↓ Knowledge Card ↓ canonical payload ↓ SHA-256 ↓ Proof v2 Sepolia ↓ GitHub documentation

Repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
README update commit:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/a4b54b86fe1066684c8604a83b3e32656b7429d7
This is important from a usability perspective.
Evidence that nobody can find is much less useful than evidence that can be navigated.

The complete evidence chain At this stage the experiment can be represented as: N4K48 │ ▼ Technical activity │ ▼ GitHub commits │ ▼ Local AI / RAG tests Docker + Ollama Qdrant + API │ ▼ Knowledge Card │ ▼ Canonical payload │ SHA-256 │ ▼ MyZubsterProof v2 Ethereum Sepolia │ ▼ GitHub documentation │ ▼ Knowledge Graph

This is the part of the experiment I find most interesting.
The blockchain is only one component of the evidence chain.
GitHub provides the development history and artifact.
The Knowledge Card provides the human-readable description.
The canonical payload provides the artifact to hash.
SHA-256 provides the cryptographic fingerprint.
Ethereum Sepolia provides a public location for the commitment.
The Knowledge Graph can then provide navigation between those elements.

What did we actually prove? This distinction is essential. The experiment provides evidence that a particular payload corresponds to a particular SHA-256 digest and that this digest was used in the Sepolia proof. It therefore creates a cryptographic link between: documented artifact ↕ cryptographic digest ↕ on-chain record

If the bytes of the artifact are changed, recalculating SHA-256 will normally produce a different digest, so it will no longer match the recorded commitment.
But this does not automatically prove that every statement inside the Knowledge Card is true.
For example, putting the hash of a statement such as:
"I am an expert in X"

on a blockchain does not prove expertise in X.
It proves something much narrower and more technically useful:
this particular data can be associated with this cryptographic fingerprint and compared against the recorded commitment.

That is why MyZubster keeps a distinction between:
CLAIM
EVIDENCE
INTEGRITY
VERIFICATION

They are related concepts, but they are not the same thing.

Why not store the entire Knowledge Card on-chain? Because that is not necessary for this experiment. Instead of storing the whole document on Ethereum, we can store a fixed-size digest: Knowledge Card content ↓ SHA-256 ↓ 32 bytes ↓ Blockchain

The larger artifact can remain in an appropriate external repository or storage layer.
The blockchain only needs the cryptographic commitment.
This approach is simpler and avoids treating a blockchain as general-purpose document storage.

From a Knowledge Card to a Knowledge Graph The next stage is to make the relationship navigable. The intended graph is: N4K48 │ ├── Knowledge Card │ │ │ ├── GitHub evidence │ │ │ └── Canonical payload │ │ │ ▼ │ SHA-256 │ │ │ ▼ │ Proof v2 Sepolia │ │ │ ├── Contract │ └── Transaction │ └── Project: myzubster-mvp

The idea is that a visitor should not simply see the statement:
N4K48 worked on a local RAG system.

They should be able to navigate from that statement toward the underlying evidence.
This is the direction being tested with the MyZubster Knowledge Graph.

AI is useful here, but it is not the authority Another lesson from this experiment concerns AI. The local model is useful for:
interpreting questions;
summarizing retrieved context;
navigating documentation;
connecting relevant evidence;
presenting information to a user. But the language model should not become the authoritative source for facts already represented structurally. For example: GitHub commit → evidence JSON payload → artifact SHA-256 → fingerprint Ethereum contract → commitment Qdrant → retrieval LLM → interpretation

The AI operates around the evidence, not instead of it.
This is one of the central ideas behind the evidence-first architecture I am exploring in MyZubster.

What I learned The most important lesson was that verifiability is not created simply by “using blockchain.” A useful evidence system requires several layers to work together: Human-readable description + source evidence + stable artifact + cryptographic digest + public commitment + reproducible verification + clear navigation

Remove the documentation and the hash becomes difficult to interpret.
Remove the original artifact and the digest becomes difficult to reproduce.
Remove the distinction between claims and proofs and it becomes easy to overstate what the technology demonstrates.
The interesting part is therefore not any single technology.
It is the connection between them.

Public references Everything used for this experiment can be inspected through the following starting points: MyZubster MVP repository https://github.com/nicolaususnicola-lgtm/myzubster-mvp Knowledge Card https://www.myzubster.com/knowledge-card?id=6abaaefb3a7460c4574a45fd Chunking improvement https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/ea80799 Proof v1 GitHub commit https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/2df5b39 Proof v1 Sepolia contract https://sepolia.etherscan.io/address/0xabCF68e97a32eCa503942A563FF16F209ed45d11#code Canonical payload for Proof v2 https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json Canonical payload commit https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/ecefd81c5c9da0be15c99aeeb83878480abd60a8 Proof v2 documentation https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/proofs/SEPOLIA_PROOF_V2.md Proof v2 documentation commit https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/405467e8d7b4e55ea9f18044a00aa66804f3ada3 Proof v2 Ethereum Sepolia contract https://sepolia.etherscan.io/address/0x21787249Df054132093FcF09bB914C0CCC539390 Proof v2 deployment transaction https://sepolia.etherscan.io/tx/0xc837ba3f3046f3712e3eba4b81107cb22939b61300f2cab3cfe5bbb7b3319ded README integration commit https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/a4b54b86fe1066684c8604a83b3e32656b7429d7 Conclusion This started as a local Docker and AI/RAG test. It gradually became something broader: local development ↓ documented evidence ↓ Knowledge Card ↓ canonical artifact ↓ cryptographic fingerprint ↓ public blockchain commitment ↓ navigable Knowledge Graph

The experiment does not turn a claim into truth simply because a hash exists on Ethereum.
What it does demonstrate is a practical architecture for making digital knowledge records more traceable, reproducible and tamper-evident.
And for me, that is the interesting direction:
not replacing trust with blockchain or AI, but making the evidence behind a digital claim easier to inspect.
N4K48 / Nicola
Building and testing myzubster-mvp

ai #rag #ethereum #opensource

Building MyZubster: Docker, Local AI, RAG and the First On-Chain Proof on Ethereum Sepolia

Nicola Lorenzini — Mon, 28 Sep 2026 22:29:17 +0000

Building MyZubster: Docker, Local AI, RAG and the First On-Chain Proof on Ethereum Sepolia
Today I reached an important milestone in the development of MyZubster.
What started as a local experiment around AI-assisted knowledge retrieval has evolved into a working development stack combining Docker, Ollama, Qdrant, an API layer, Open WebUI, GitHub and Ethereum Sepolia.
The interesting part wasn't simply getting the individual components running. The goal was to connect them into a system that could ingest knowledge, retrieve the correct context, expose it to an AI interface, and begin attaching independently verifiable proofs to knowledge artifacts.

Building the local AI stack The first step was creating a reproducible local environment. The development stack uses Docker Compose to orchestrate several components:
Ollama for local language-model execution
Qdrant as the vector database
an API layer for retrieval and application logic
Open WebUI as the user-facing AI interface
the MyZubster application and knowledge-ingestion pipeline This allowed the project to move from isolated scripts toward an actual integrated environment. The repository containing the work is: github.com/nicolaususnicola-lgtm/myzubster-mvp
Building the RAG knowledge pipeline The next challenge was knowledge ingestion. Documents have to be transformed into chunks before embeddings can be stored in Qdrant and later retrieved by the AI system. During testing, I found a problem in the original chunking logic: paragraph and line boundaries could produce poor chunks and potentially interfere with retrieval. The ingestion script was therefore modified to improve the chunking strategy while:
preserving useful overlap;
respecting paragraph and line boundaries;
avoiding loops;
skipping empty documents;
keeping chunks suitable for retrieval. After the changes, the ingestion process completed successfully. In one of the verification runs, 46 knowledge chunks were loaded into Qdrant and one empty document was skipped. That gave us a concrete test that the modified ingestion pipeline was functioning.
Testing retrieval through the API Storing embeddings isn't enough. The important question is whether the system can retrieve the right knowledge when a user asks a question. The RAG pipeline was therefore tested through the API endpoint. One particularly useful discovery involved the amount of context supplied to the model. By increasing AI_CONTEXT_LIMIT from 1 to 5, the system was able to recover the relevant context and return the expected GitHub repository information. This was a small configuration change, but an important lesson: retrieval quality depends not only on embeddings and chunking, but also on how much retrieved context is actually made available downstream.
Moving from AI knowledge to verifiable knowledge The next experiment was more ambitious. Instead of asking users to simply trust that a knowledge artifact existed at a particular moment, MyZubster needed a way to create an independently inspectable proof. For this first experiment I created a Solidity smart contract called: MyZubsterProof.sol The contract records a bytes32 value representing a hash associated with a knowledge artifact. The objective is deliberately simple: the blockchain stores the proof, not the complete knowledge content. This distinction matters. Sensitive or large content does not need to be published on-chain. A cryptographic digest can instead provide a reference that can later be compared with the original artifact.
First deployment on Ethereum Sepolia The contract was deployed to the Ethereum Sepolia test network. The deployment transaction is publicly inspectable through Etherscan, and the contract source was subsequently verified there with an Exact Match result. That gives the project its first independently inspectable on-chain component. For the development process, this was an important transition: local experiment → public cryptographic evidence The corresponding Solidity source and documentation were also committed to the project's GitHub repository.
Connecting the evidence back to MyZubster The next step was documenting the work as a MyZubster knowledge card. The card contains references to:
the project repository;
the local Docker test;
the chunking improvement commit;
the Sepolia proof commit;
the verified Sepolia contract;
the Sepolia deployment transaction. An interesting bug appeared here too. The profile builder limits a knowledge card to 12 sources, and initially some sources had been entered using separate lines for title, URL and description. The parser treated those lines as separate sources. The expected format was actually: name | URL | note with one source per line. After normalizing the source list, the card contained six sources and could be successfully saved as a private draft before publication. It's a tiny implementation detail, but exactly the kind of thing that appears when a prototype starts becoming a real product. What exists now At this stage, MyZubster has demonstrated several pieces of the architecture working together: Docker environment → knowledge ingestion → Qdrant → RAG retrieval → AI interface/API → GitHub evidence → Ethereum Sepolia proof → MyZubster knowledge card There is still work to do. In particular, the complete Open WebUI integration deserves additional end-to-end verification, and the relationship between knowledge cards and on-chain hashes can be automated further. But the important milestone is that the project now has both a local AI knowledge pipeline and its first publicly inspectable blockchain proof. Next steps The next development phase will focus on tightening the connection between these layers. Instead of manually creating blockchain proofs, the long-term flow could become: Knowledge Card → canonical representation → SHA-256 → on-chain attestation → transaction reference → verification That would allow a MyZubster knowledge artifact to carry not only sources and AI-readable context, but also a cryptographic proof that can be independently checked. The goal isn't to put knowledge on a blockchain. The goal is to make claims about digital knowledge more inspectable, attributable and verifiable. And this first Sepolia deployment is a small but concrete step in that direction.

Building a Local AI Knowledge System with Docker, Ollama, Qdrant and Open WebUI

Nicola Lorenzini — Mon, 28 Sep 2026 18:27:45 +0000

Building a Local AI Knowledge System with Docker, Ollama, Qdrant and Open WebUI

Today I continued experimenting with MyZubster, an open-source project I'm working on while learning how local AI systems, knowledge retrieval and verifiable profiles can work together.

The goal was simple:

Can a local AI answer questions using a personal knowledge base instead of relying only on what the language model already knows?

The stack we tested included:

Docker
Ollama
Qdrant
Open WebUI
a Python API
Markdown knowledge files
local embeddings

Starting the local stack

The project uses Docker Compose.

After starting Docker Desktop, the services came online:

api
ollama
qdrant
open-webui

The API reported healthy and Open WebUI became available locally.

This gave us a completely local environment where we could experiment with AI retrieval without depending on a hosted LLM.

Building the knowledge base

The project contains Markdown documents inside a knowledge directory.

A Python ingestion script:

reads the documents;
splits them into chunks;
creates embeddings using Ollama;
stores the vectors and metadata in Qdrant.

The embedding model used during the experiment was:

nomic-embed-text

After rebuilding the knowledge index, the ingestion completed with:

Loaded 40 knowledge chunks; skipped 1 empty documents

So the pipeline itself was working.

Then we found an interesting problem

We asked the AI:

What is the GitHub repository of N4K48? Give me the complete link without abbreviating it.

The model answered confidently — but returned the wrong GitHub URL.

That was useful.

It showed an important distinction:

a working RAG pipeline does not automatically mean reliable answers.

Docker was running.

Qdrant contained the knowledge.

Ollama was generating embeddings.

Open WebUI could talk to the model.

But somewhere between document ingestion, retrieval and generation, the information reaching the model was still not reliable enough.

Investigating document chunking

The original ingestion system divided documents approximately every 1,000 characters with an overlap.

That approach is simple, but arbitrary character boundaries can split meaningful information.

URLs are a good example.

A GitHub URL divided between chunks can become incomplete or lose the context that explains what the URL represents.

So we inspected and modified the knowledge ingestion logic to make document segmentation more meaningful and reduce arbitrary cuts.

Then we deleted the previous knowledge points and rebuilt the Qdrant index.

The result was 40 newly generated knowledge chunks.

The experiment isn't finished yet.

The next step is to inspect the retrieval path between:

question → embedding → Qdrant → retrieved knowledge → API → Ollama

and determine exactly where the incorrect repository information is being introduced.

A second experiment: knowledge profiles

At the same time, we tested the MyZubster Knowledge Profile Builder.

Instead of treating every statement as verified knowledge, the Builder distinguishes between:

declared knowledge;
external evidence;
information still requiring verification.

We created three private knowledge drafts covering:

professional transport experience;
Docker and local AI experimentation;
learning and collaboration during the MyZubster project.

The drafts were saved privately and remained available after reopening them.

They are not public yet.

Before publishing them, we're checking how evidence and verification should be attached to each claim.

What I learned

The most interesting lesson wasn't that we managed to run an LLM locally.

It was that running the model is the easy part.

The difficult part is building a trustworthy path from:

human knowledge

to:

documents

to:

chunks

to:

embeddings

to:

retrieval

to:

LLM answer

Every step can change what the final model sees.

And a model can produce a perfectly fluent answer even when one of those steps supplied the wrong information.

That's why provenance and verification matter.

What's next

The next experiments will focus on:

inspecting Qdrant retrieval results;
improving knowledge chunking;
testing complete URLs and source metadata;
distinguishing declared knowledge from verified evidence;
testing the three Knowledge Profile drafts;
improving the reliability of answers generated from the local knowledge base.

This is still an experiment, and some parts are intentionally unfinished.

I'll document what works — and what breaks — as the project develops.

MyZubster / N4K48

Building, testing and learning in public.

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 Community: Nicola Lorenzini

From a Local MVP to an Independently Operated Node: N4K48 ↔ MyZubster Interoperability Is Now TESTED

From a Local MVP to an Independently Operated Node: N4K48 ↔ MyZubster Interoperability Is Now TESTED

Where N4K48 started

The interoperability challenge

The live test

Verifying the software that actually ran

Hardening the node after the interoperability test

Moving the local credential to Windows DPAPI

Testing the checkpoint

What has actually been demonstrated?

TESTED

NOT YET PROVEN

Why I think the administrative boundary matters

The next step: a second independent contributor

Toward Bridge Protocol v1

From interoperability toward federation

MyZubster and the evidence-first approach

An open invitation to developers

Final thought

opensource #decentralization #distributedSystems #docker #ai #interoperability #buildinpublic #github #myzubster #n4k48

From Comics to Code: Building MyZubster One Piece of Evidence at a Time

Building Verifiable Knowledge in MyZubster: From Stable Evidence IDs to Proof v3

25

opensource #react #web3 #blockchain #provenance #knowledgegraph #javascript #buildinpublic

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

From Local AI to Ethereum: Building a Verifiable Knowledge Proof with MyZubster

From Local RAG to a Verifiable Knowledge Proof on Ethereum Sepolia

ai #rag #ethereum #opensource

Building MyZubster: Docker, Local AI, RAG and the First On-Chain Proof on Ethereum Sepolia

Building a Local AI Knowledge System with Docker, Ollama, Qdrant and Open WebUI

Building a Local AI Knowledge System with Docker, Ollama, Qdrant and Open WebUI

Starting the local stack

Building the knowledge base

Then we found an interesting problem

Investigating document chunking

A second experiment: knowledge profiles

What I learned

What's next

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 UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline