Coder Legion - Recent posts tagged source

How to Deduplicate Leads in n8n Before They Reach Your CRM

Sun, 11 Oct 2026 15:50:00 +0000

Lead deduplication is not one filter. A reliable n8n workflow separates repeated submissions from repeated people, normalizes the values used for comparison, checks persistent records, and lets the CRM enforce uniqueness whenever the destination supports it.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: use a stable source ID to stop the same event twice, normalized email or phone to find an existing person, and a CRM-native create/update or upsert operation for the final write. Never auto-merge two records on name alone.

First identify which duplicate you are stopping

Duplicate type	Example	Best first control
Repeated item in one execution	A spreadsheet import contains the same row twice	Remove Duplicates on the current input
Repeated source event	A webhook or retry delivers submission `lead_8472` again	Persistent check on the stable source ID
Same person from another source	The same customer submits a website form after a Facebook form	Normalized identity lookup in the CRM
Conflicting identity	Email matches one contact while phone matches another	Human review, not an automatic merge

The Facebook Lead Ads workflow uses a Meta lead ID to stop one submission from creating several sheet rows. This guide goes further by handling several sources and an existing CRM full of contacts.

Choose identity keys before building nodes

Key	What it proves	Rule
Source record or submission ID	The same source event or object	Strongest key for replay protection, but not for matching a person across systems
Normalized email	Usually the same inbox	Good exact contact key when present and valid
Normalized phone	Usually the same reachable number	Useful with country context; shared business or family numbers need caution
Name	Only that the text looks similar	Use as review context, never as the only automatic merge key

Decide field ownership too. A new form may fill a missing phone number, but it should not silently replace a verified CRM email, owner, lifecycle stage, or consent value. Deduplication decides which record to use. A separate update policy decides which fields may change.

A practical n8n workflow shape

Lead trigger
  → Edit Fields: normalize keys
  → Remove Duplicates: current batch or repeated event
  → Data Table or CRM: persistent lookup
  → Switch: new / exact match / conflict
  → CRM: create or update
  → Data Table: record source key and CRM ID
  → Alert only when review or failure is needed

Start with one lead source and one CRM. The same pattern can later sit behind Facebook forms, website forms, imports, chat, and email without giving each source a different duplicate policy.

Step 1: normalize the fields once

Add an Edit Fields node immediately after the trigger. Preserve the original values for audit and display, then create separate comparison fields:

source_key
email_original
email_key
phone_original
phone_key
full_name
source
received_at

For an email comparison key, an n8n expression can trim whitespace and use lowercase:

{{ ($json.email || '').trim().toLowerCase() }}

Build source_key from the provider and its stable ID, for example facebook:lead_8472 or website:submission_193. Do not concatenate name and timestamp and call that stable. For phone numbers, remove presentation punctuation and normalize with the correct country context. Simply stripping every non-digit character can make two different international numbers look deceptively similar.

Step 2: use Remove Duplicates for the narrow job it does well

For duplicate rows arriving together, configure Remove Duplicates → Remove Items Repeated Within Current Input, choose Selected Fields, and compare source_key. This is ideal for imports and batched records.

For the same source event arriving in later executions, the node also supports Remove Items Processed in Previous Executions. Use Value Is New and deduplicate on source_key. Scope can be the individual node or the workflow. Current n8n documentation says the default history size is 10,000 items.

Do not treat that history as your customer database. The history has a configured size, can be cleared, and only knows the values you gave that node or workflow. It cannot decide that two different source IDs belong to the same person.

Step 3: add a persistent lookup

Option A: n8n Data Table for a small lead ledger

A Data Table is a practical first version for a small business that does not yet have strong CRM lookup rules. Create a table such as lead_identity with these columns:

source_key
email_key
phone_key
crm_id
status
first_seen_at
last_seen_at

The current Data Table node can check whether a row exists, get rows, insert, update, and upsert using conditions. Search the strongest available key before the CRM write, then upsert the final crm_id only after the CRM succeeds.

n8n describes Data Tables as light to moderate storage. The default total limit across all tables in an instance is 50 MB, although self-hosted instances can change it. That makes a table useful as a compact identity ledger, not a replacement for a mature CRM or warehouse.

Option B: search the CRM directly

If the CRM already owns the customer record, query it first. The current n8n HubSpot node, for example, supports searching contacts and a Create/Update a contact operation. Other CRM nodes expose different operations, so check the destination's exact contract before copying a pattern.

Prefer a CRM record ID or custom unique source ID once you have one. HubSpot's current Contacts API can retrieve by email and batch upsert by email or a custom unique identifier. It also notes that partial upserts are not supported when email is the identifier, which is one reason not to send an incomplete payload blindly.

Step 4: route new, matched, and conflicting leads

Use a Switch node with three explicit outcomes:

No match: create the contact, then save the returned CRM ID with the source key.
One safe match: update only allowed fields and attach the new source or submission as an activity.
Conflict: do not create or merge automatically. Send the candidate record IDs and incoming values to an owner for review.

A conflict includes more than two search results. It also includes email matching contact A while phone matches contact B, or a source ID pointing to a record whose verified identity now disagrees with the payload. Preserve the lead and notify someone. Silent deletion is not deduplication.

Step 5: make the CRM write duplicate-safe

Use the destination's create/update or upsert operation when it can enforce a unique identifier. This is stronger than a separate search followed by create because two n8n executions can run at nearly the same time, both see no result, and both create a contact before either writes the ledger.

If the CRM cannot upsert atomically, use its unique-field constraint, serialize the critical section, or put the identity key in a database with a unique index. Catch the destination's duplicate response and retrieve the existing record instead of treating every conflict as an unrecoverable failure.

After a successful write, upsert the source key and returned CRM ID into the Data Table. Then send notifications or start follow-up. This ordering prevents the team from receiving a success alert for a contact that never reached the CRM.

Test with a small duplicate matrix

Test	Expected result
Same source ID delivered twice	One CRM record; the replay is stopped or attached without another create
Different source ID, same normalized email	Existing contact updated according to field rules
Same phone with different formatting	One candidate after country-aware normalization
Same name, different email and phone	New record or manual review, never an automatic merge by name
Email matches A, phone matches B	Conflict branch with both record IDs visible
Two identical executions started together	One destination record because the final write enforces uniqueness
CRM write fails	No success alert and no ledger row marked complete

Common mistakes

Comparing raw email or phone values without normalization.
Using name as a unique key.
Assuming a source submission ID identifies the same person across every channel.
Dropping duplicates without recording the new campaign, form, message, or timestamp.
Overwriting verified CRM fields with blank or lower-confidence form values.
Running search and create concurrently without a destination uniqueness control.
Using a temporary in-workflow list as the only long-term duplicate barrier.

Useful questions before publishing

Can Remove Duplicates replace a CRM lookup?

No. It is useful for repeated items and remembered values, but it does not understand an existing customer record, alternate email, shared phone, merge history, or field ownership.

Should email or phone be the main key?

Use the strongest verified identifier your process reliably collects. Email is often the simplest contact key. Phone can be useful after country-aware normalization. Keep a stable source ID for replay protection even when email is the CRM match key.

Should a duplicate lead be discarded?

Usually not. The person may have submitted a new service request or responded to a different campaign. Reuse the contact record, then preserve the new submission as an activity, note, deal, or source event.

Privacy and operating rules

Store only the identity fields needed for matching and follow-up.
Restrict Data Tables, execution data, and CRM credentials to the responsible project members.
Set retention rules for rejected and ambiguous records.
Do not place full lead payloads in chat alerts when a secure CRM link is enough.
Document who resolves conflicts and how quickly the review queue should be checked.

For retries around state-changing API calls, use the separate duplicate-safe n8n API retry pattern. That guide protects one operation from being repeated. This guide protects CRM identity across leads and sources.

Sources checked

n8n Cloud for small teams

Test the duplicate guard without maintaining a server

n8n Cloud is the simplest place to build this workflow if you want to focus on the lead logic instead of hosting. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the CRM identity rules mapped?

Send the lead sources, available IDs, CRM, match fields, and examples of known duplicates. I will help define the new, matched, and review paths before the workflow writes production records.

Map the duplicate guard

Originally published on FloxoLab.

Building Evidence-First Contributor Interoperability with VPS Checkpoints, GitHub Provenance and I

Tue, 06 Oct 2026 17:30:43 +0000

Building Evidence-First Contributor Interoperability with VPS Checkpoints, GitHub Provenance and Independent Verifiers

Open-source projects are good at collecting contributions.

They are much less good at answering a harder question:

Can somebody independently reproduce what a contributor actually built?

A merged pull request tells us that code entered a repository.

It does not automatically tell us:

which exact contributor commit was independently tested;
whether that behavior still works on the current codebase;
what environment was used;
what was expected;
what actually happened;
what failed;
and what the result does not prove.

At MyZubster, we have been experimenting with a contributor model built around evidence-first interoperability.

Instead of treating every external contribution as something that simply disappears into the main repository, we are trying to preserve the contributor's provenance and connect their work to reproducible technical checkpoints.

Today we pushed that model further by connecting multiple contributors through GitHub, contributor-specific verifier scripts and an independent VPS execution environment.

The result is not full P2P decentralization yet.

But it is a concrete step toward a network where contributors can own their code while sharing a common verification protocol.

The core idea

Our current contributor flow looks like this:

Contributor
    ↓
Public repository / pull request
    ↓
Immutable commit SHA
    ↓
Contributor-specific verifier
    ↓
Independent VPS execution
    ↓
Expected vs actual result
    ↓
Structured evidence
    ↓
TESTED checkpoint

Different contributors may use:

Node.js
Python
Docker
Qdrant
Ollama
Jest
webhooks
policy engines
research artifacts
KPI frameworks

They do not need the same runtime.

They need the same evidence discipline.

That distinction matters.

Git history is part of the evidence

Branches are convenient for development.

They are not ideal as evidence anchors because they move.

So when we verify a contribution we prefer to record:

GitHub username
repository
pull request
contributor commit
merge commit, if applicable
verifier commit
test objective
expected result
actual result
limitations

That gives us an immutable checkpoint.

Instead of saying:

This feature was tested.

we can say:

This exact contribution, from this exact commit, was reproduced under these exact conditions.

That is much more useful.

Why use a VPS?

We currently use a MyZubster VPS as an independent technical reproduction environment.

It is important to describe what that means correctly.

The VPS is not:

unrestricted contributor access
production control
shared root access
security certification
automatic bounty approval

It is a controlled execution environment.

Depending on the contribution, we can:

clone the public repository;
check out an exact branch or commit;
run a bounded verifier;
use synthetic fixtures;
run a Docker stack;
collect sanitized output;
compare expected and observed behavior.

In some cases direct contributor VPS access may eventually be appropriate.

In others, a maintainer-run test is safer and more reproducible.

Our public contributor VPS pilot is tracked here:

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

The rules include:

least privilege
time-limited access
no public secrets
explicit scope
synthetic or authorized data
rollback expectations
reproducible commands

Contributor checkpoint 1: N4K48 as an independent Docker node

One of our earliest practical contributor-node experiments was Nicola / N4K48.

The external project runs independently from the MyZubster core repository.

We reproduced a specific contributor checkpoint:

repository:
nicolaususnicola-lgtm/myzubster-mvp

commit:
87a1021

The environment included:

Docker
MyZubster API
Qdrant
Ollama
Open WebUI
nomic-embed-text
Zorgax

We checked bounded behaviors such as:

container startup
API health
observation retrieval
read-only contributor flows
semantic retrieval

That produced a technical:

TESTED

checkpoint for the independent reproduction.

It did not mean:

full P2P established
production deployment certified
commercial settlement proven

The distinction between what passed and what remains unproven is part of the evidence itself.

Contributor checkpoint 2: Open Period Care

Open Period Care presented a completely different type of contribution.

Instead of a standalone runtime, the contribution contained structured research and evidence artifacts.

Two example Knowledge Cards were:

KC-OPC-001
Multi-Layer Biomaterial Architecture for Reusable Textile Absorbents
SUPPORTED

and:

KC-OPC-002
Contributor Privacy, Data Minimization & Clinical Boundaries
SUPPORTED

Notice the status:

SUPPORTED

That state belongs to the research content.

Running a successful software integration did not magically change it to TESTED.

What became TESTED was the technical bridge that retrieves and scopes the contributor evidence.

The read-only bridge was merged through:

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

Merge SHA:

6061140f4ade01ab10211b2a6698cac03f326e55

This separation between:

technical interoperability

and:

research/evidence status

is one of the most important parts of the architecture.

Semantic search is not identity

During the Open Period Care work we hit a useful retrieval failure.

A semantic query over a shared Qdrant collection returned the wrong contributor record.

The vector search was doing what vector search does:

find semantically similar content

But we were asking it to do something stricter:

identify the authoritative record

Those are not the same problem.

We now separate:

semantic/vector retrieval
→ discovery

from:

deterministic metadata lookup
→ authoritative IDs
→ status
→ provenance
→ contributor scope

For example:

bridge = open-period-care
knowledgeCardId = KC-OPC-001

is a much stronger lookup constraint than:

"find something similar to this card"

The general lesson is simple:

Embeddings are excellent for finding candidates. Structured metadata should decide identity.

Contributor checkpoint 3: Shweta and an unmerged commit

Shweta-singh24 gave us another interesting case.

The contribution we wanted to verify came from a pull request that had been closed without merging.

That does not make the code disappear.

It simply changes the claim we are allowed to make.

We reproduced the exact contributor commit:

82461433e0c5bfee9aa369b4a71e9331261cf803

The bounded policy checks covered behavior such as:

GLOBAL      → ALLOW
HK          → ALLOW
CN_MAINLAND → DENY

plus fail-closed behavior for unknown policy values.

The verifier bridge was merged through:

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

Merge SHA:

aa54fd380e487c11ba39fb40a092212f412cf364

The evidence therefore says:

TESTED — exact closed/unmerged contributor checkpoint

It does not say:

merged upstream
deployed
legally approved

This is exactly why immutable provenance matters.

Contributor checkpoint 4: wasim-builds

wasim-builds contributed explicit regression coverage for fail-closed admin authentication.

Original contribution:

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

Contributor commit:

d378adbbd9690cfbac081758000bb95d64fe7fb1

The independent VPS verifier reran four bounded behaviors:

ADMIN_API_KEY not configured → 503
missing admin key            → 401
incorrect admin key          → 401
correct admin key            → 200

Result:

4 / 4 PASS

The verifier was merged through:

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

Merge SHA:

a0faab53f817c3c6379d3ccaaad5d3fac3b6fb1b

Contributor checkpoint:

TESTED — fail-closed admin-auth regression

This is not a security certification.

It is an independent reproduction of four defined security regression cases.

That boundary matters.

Contributor checkpoint 5: Aming9303

Aming9303 contributed signed payment lifecycle webhooks.

Original PR:

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

Contributor commit:

cee464b6a69e621442b30a57d2d56933988827e2

The contribution included:

HMAC-SHA256 signatures
delivery IDs
retry behavior
timestamp windows
replay protection
constant-time signature comparison

We created a targeted VPS verifier for five behaviors:

1. signed event has correct HMAC
2. retry preserves the delivery ID
3. endpoint without secret is rejected
4. replayed delivery ID is rejected
5. stale event is rejected before replay claim

Result:

5 / 5 PASS

The verifier was merged through:

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

Merge SHA:

1154a87d27332a779e86d11e4b7952c22099d533

Checkpoint:

TESTED — signed payment-webhook regression

Again, this does not imply that every production webhook receiver is reliable.

It proves the tested contract.

Contributor checkpoint 6: foxxx009

foxxx009 contributed a KPI, baseline and evidence/provenance framework.

Original PR:

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

Contributor commit:

70cb32c6500525df4056859525fe215b95188a02

This verifier was especially useful because it needed to check more than code execution.

We tested:

3 baseline records
2 pilot records
11 KPI outputs
evidence references
JSON output
Markdown output
missing-data handling
synthetic-data disclaimers
anti-overclaim behavior

One KPI uses a documented:

ratio-of-totals

aggregation.

The expected value was:

(3222.5 + 3098.7) / (9.95 + 9.51)

which equals:

324.83042137718394

The independently observed value was:

324.83042137718394

Exact match.

The verifier failed twice

And this is where the process became interesting.

The first run failed because our verifier tried to install pytest.

The VPS had Python 3 but no pip.

Result:

FAILED

But that was not a contributor failure.

It was a verifier dependency failure.

So we removed the dependency.

The verifier became:

Python 3
+
standard library
+
repository modules

The second run failed because our expected KPI formula was wrong.

We had calculated:

average of ratios

while the contributor implementation correctly used:

ratio-of-totals

Our verifier was wrong.

Not the contributor.

We corrected the expectation and reran.

Final result:

TESTED

The verifier was merged through:

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

Merge SHA:

f0c477f563ab7e92a734b3042d44063794b7f81f

This reinforced a rule we want to keep:

A failed verifier run is evidence too.

Do not rewrite it into success.

Find out what actually failed.

Why a verifier should be intentionally boring

A good verifier should avoid cleverness.

Its job should be something like:

read known source
check provenance
run deterministic operation
compare result
emit JSON

For example:

{
  "contributor": "example-user",
  "source_commit": "abc123",
  "scope": "bounded webhook regression",
  "checks": {
    "valid_signature": true,
    "invalid_signature": true,
    "replay_rejected": true
  },
  "status": "TESTED",
  "boundary": "Production delivery reliability was not tested."
}

That output can later feed:

Contributor Passport
Knowledge Graph
Zorgax
public evidence pages
project dashboards

without requiring an AI model to invent the underlying state.

What we mean by decentralization

We are deliberately careful with this word.

Today MyZubster is not claiming:

fully decentralized production
permissionless VPS access
distributed consensus
fully federated execution
complete direct P2P contributor communication

What we have demonstrated is something earlier and more practical:

Decentralized provenance

Contributors retain public ownership of their own:

GitHub identity
repository
commit history
artifact
technical evidence

Independent reproducibility

A central maintainer does not have to be the only authority saying:

This contributor's work works.

A third environment can rerun the checkpoint.

Interoperability through evidence

Different contributors can use different architectures while speaking a common evidence language.

That gives us:

different code
different runtime
different domain
different repository
            ↓
shared verification contract

That is the decentralization layer we are currently building.

Contributor-to-contributor links come next

We have also opened an opt-in contributor bridge around the N4K48 node:

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

The intended state machine is:

PROPOSED / CONSENT PENDING
        ↓
OPTED IN
        ↓
APPROVED BY BOTH SIDES
        ↓
TEST PLAN AGREED
        ↓
TESTED
        ↓
VERIFIED

This is important because similar interests do not automatically create collaboration.

A graph edge should not imply consent.

A shared technology stack should not imply partnership.

Contributor-to-contributor interoperability should also be evidence-based.

How to join MyZubster as a contributor

You do not need to build an entire platform.

A useful contribution can be small.

Examples include:

bug fix
test suite
Docker setup
sensor adapter
webhook
API integration
security regression
dataset validator
KPI function
evidence schema
documentation
accessibility improvement
reproducible deployment
privacy control
RAG retrieval improvement
Qdrant metadata strategy

The main repository is:

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

A practical contributor workflow is:

1. Build something narrow

A contribution should ideally solve one clear problem.

A 20-line reproducible fix can be more valuable than a huge branch nobody can evaluate.

2. Publish the source

Give us:

GitHub username
repository
branch
pull request
commit SHA

The commit SHA is especially important.

3. Define the test contract

Bad:

Check whether my project works.

Good:

Run command X.

Input:
fixture Y.

Expected:
HTTP 401.

Negative case:
invalid token must not reach protected route.

The narrower the test contract, the easier independent reproduction becomes.

4. List dependencies

Document:

runtime
minimum CPU/RAM
ports
environment variable names
network requirements
startup command
test command
cleanup command

Never publish:

passwords
tokens
wallet seeds
private keys
personal information
private infrastructure addresses

5. Define what success means

Every verifier should have an explicit boundary.

Example:

TESTED:
delivery replay protection reproduced.

NOT ESTABLISHED:
production payment settlement.

This prevents successful technical tests from becoming exaggerated project claims.

6. Run the independent checkpoint

Depending on the contribution, we may use:

Docker
maintainer-run VPS execution
read-only integration
synthetic fixtures
zero-dependency verifier
scoped contributor VPS access

Our external contributor pilot is here:

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

What successful contribution can connect to

A useful independently reproduced contribution may later be connected to:

Contributor Passport
Knowledge Graph
related projects
related contributors
public evidence records
scoped VPS experiments
university/research demonstrations
future agreed bounties

But those are separate state transitions.

A technical test does not automatically mean payment.

A merge does not automatically mean deployment.

A graph connection does not automatically mean partnership.

This is intentional.

A note about AI

MyZubster also uses AI and semantic search.

That makes provenance even more important.

An LLM should help us:

discover
summarize
explain
compare
navigate

It should not silently change:

commit IDs
structured statuses
evidence states
authorship
verification results

If the metadata says:

status = SUPPORTED

the AI should not decide:

status = VERIFIED

because the text sounds convincing.

Structured evidence should stay authoritative.

The architecture we are working toward

Long term, we imagine something closer to this:

Contributor A              Contributor B
     |                          |
     v                          v
 own repo                    own repo
 own node                    own service
 own evidence                own evidence
     |                          |
     +------------+-------------+
                  |
                  v
          common evidence protocol
                  |
       +----------+----------+
       |                     |
       v                     v
MyZubster verifier     contributor verifier
       |                     |
       +----------+----------+
                  |
                  v
            Knowledge Graph
                  |
                  v
                Zorgax

The shared layer is not central ownership.

It is interoperability.

Lessons from today's work

A few practical lessons became very clear.

1. Immutable commits beat moving branches

A branch is for development.

A SHA is for evidence.

2. `FAILED` must remain meaningful

Do not hide failed runs.

Investigate them.

3. A verifier can be wrong

Independent validation applies to our own assumptions too.

4. Semantic search is discovery, not identity

Use deterministic metadata for authoritative lookups.

5. `TESTED` must remain bounded

A passing regression test is not certification.

6. Contributors do not need identical infrastructure

They need interoperable evidence.

Want to contribute?

Start with one small, reproducible artifact.

Repository:

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

VPS contributor pilot:

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

Contributor bridge:

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

When proposing a test, include:

GitHub username
repository / PR
commit SHA
test objective
run command
expected result
dependencies
resource requirements
public evidence you authorize

Then we can try to reproduce it independently.

Final thought

We often describe decentralization in terms of networks and consensus.

But before you can decentralize execution, you need to decentralize trust.

A contributor should not need to rely on a central maintainer saying:

Trust us, we tested your work.

The system should be able to show:

source
author
commit
environment
command
expected result
actual result
limitations

That is the direction we are exploring with MyZubster.

Different people.

Different repositories.

Different technologies.

One reproducible evidence protocol.

And eventually, more independent nodes talking directly to each other.

That is where contributor interoperability starts.

Building Evidence-First Contributor Interoperability with Qdrant, Zorgax and Reproducible Checkpoint

Tue, 06 Oct 2026 06:37:33 +0000

Building Evidence-First Contributor Interoperability with Qdrant, Zorgax and Reproducible Checkpoints

One of the harder problems in an open-source ecosystem is not getting people to contribute.

It is connecting independently built contributions without pretending that they all have the same architecture, maturity, or evidence level.

During a recent MyZubster engineering session, we worked on exactly that problem.

The objective was to build a common interoperability layer where different contributor projects could remain independent while still becoming:

reproducible,
queryable,
attributable,
evidence-scoped,
and machine-verifiable.

The result was a working pattern spanning Docker runtimes, research packages, vector retrieval, deterministic metadata lookup, independent verifier scripts, and CI security gates.

The problem

MyZubster contributors do not all produce the same kind of artifact.

One contributor may provide a runnable Docker application.

Another may provide a research and knowledge package.

Another may contribute a security or policy implementation.

So a single integration method would be artificial.

Instead, we defined a common evidence pipeline:

INDEPENDENT CONTRIBUTOR WORK
        ↓
PUBLIC REPOSITORY / PR / EVIDENCE
        ↓
CANONICAL CONTRIBUTOR RECORD
        ↓
RUNTIME / KNOWLEDGE / VERIFIER BRIDGE
        ↓
REPRODUCIBLE CHECKPOINT
        ↓
PUBLIC TECHNICAL EVIDENCE
        ↓
BOUNDED STATUS

The important word is bounded.

A successful software test should not magically become a scientific validation.

A literature-supported claim should not become a laboratory result.

A successfully reproduced commit should not be described as deployed production software.

We therefore distinguish states such as:

SUPPORTED
TESTED
VERIFIED

and use them only for the scope actually demonstrated.

1. Reproducing an independent contributor runtime

Our reference case was the N4K48 MyZubster MVP.

We independently reproduced contributor commit:

87a1021

on a MyZubster VPS.

The runtime included:

Docker
N4K48 API
Qdrant
Ollama
Open WebUI
nomic-embed-text
zorgax:latest

We tested:

Docker build
API health
observation retrieval
Nicola Comics catalog
read-only Zorgax behavior

This produced our first useful definition of technical interoperability:

A contributor checkpoint can be called TESTED when another MyZubster environment independently reproduces the exact artifact and observes the expected behavior.

That still does not mean direct peer-to-peer communication with the contributor's physical machine.

It is a reproducibility checkpoint.

2. Adding evidence to the semantic layer

After reproducing N4K48, we inserted a technical observation describing another MyZubster identity, H4X0R.

The record retained provenance:

actorRef: H4X0R
project: MyZubster
evidenceState: TESTED
sourceCommit: 87a1021
sourceIssue: MyZubster-Ecosystem/myzubster#1505

Observation ID:

d654a6bcde1ce181

We then queried it through the Qdrant + Ollama + Zorgax path.

A supported question produced a source-grounded answer.

Then we asked an unsupported question:

What is H4X0R's phone number?

The expected behavior was not a guess.

It was:

Informazione non disponibile nelle fonti MyZubster.

That test passed.

For us, anti-hallucination behavior became part of interoperability testing.

3. Connecting a research contributor

The next contributor was fundamentally different.

khongten124 contributed an Open Period Care research and knowledge package.

Instead of reproducing a Docker runtime, MyZubster created a read-only evidence bridge pinned to:

repository:
khongten124/myzubster

branch:
feat/open-period-care-research-1450

commit:
17cf7ca0a941d10e184771e574683785c1dbc8bf

Three upstream artifacts were fetched:

README.md
evidence-matrix.md
knowledge-cards.md

Each normalized record retained:

contributor
project
repository
branch
commit
source path
SHA-256
evidence states
original content
bridge status

The live VPS check passed.

So we could accurately say:

Open Period Care public evidence fetch + normalization: TESTED

But the research itself retained its original evidence states.

For example:

KC-OPC-001 → SUPPORTED
KC-OPC-002 → SUPPORTED

The interoperability test did not promote them.

4. The first semantic integration failed

Then things became more interesting.

We ingested Open Period Care evidence into the same Qdrant/Zorgax path.

The first semantic test returned something plausible — but wrong.

The model confused requirement identifiers such as:

REQ-MAT-01
REQ-ABS-02
REQ-BAR-03

with actual Knowledge Card identifiers.

It also interpreted references to standards such as GOTS as if they were personal certifications belonging to the contributor.

That is exactly the type of error that a provenance-heavy system is supposed to catch.

So the result remained:

FAILED

rather than being described as successful because "the AI basically understood it."

5. Structured facts should not be delegated to free-form generation

The first lesson was that some information should not depend on generative interpretation.

Fields such as:

knowledgeCardId
title
status
sourceCommit
credential state

are structured facts.

We created retrieval-friendly semantic anchors containing authoritative statements such as:

KC-OPC-001 —
Multi-Layer Biomaterial Architecture for Reusable Textile Absorbents.
Stato: SUPPORTED.

and:

KC-OPC-002 —
Contributor Privacy, Data Minimization & Clinical Boundaries.
Stato: SUPPORTED.

We also represented the contributor credential boundary:

professionalCredential: NOT_ESTABLISHED
medicalCredential: NOT_ESTABLISHED

This improved the data model.

But the RAG still failed.

6. Cross-contributor vector contamination

The deeper problem was Qdrant retrieval.

N4K48 used a shared collection:

myzubster

and the default search path looked approximately like:

question
   ↓
embedding
   ↓
Qdrant cosine similarity
   ↓
top N observations
   ↓
Zorgax

There was no contributor filter.

So when we asked for the description of KC-OPC-001, the top semantic match could still be the earlier H4X0R record.

This produced a particularly revealing failure:

Question:
Qual è la descrizione di KC-OPC-001?

Answer:
H4X0R è l’identità tecnica usata da Daniel...

The authoritative answer mechanism itself was doing exactly what it was programmed to do.

The problem was that the wrong record was ranked first.

7. Semantic discovery + deterministic metadata lookup

That failure led to the architecture that finally passed.

We separated two retrieval tasks.

Semantic search

Use embeddings for:

discovery
related evidence
open-ended questions

Deterministic metadata lookup

Use filters for:

identity
structured IDs
evidence state
source path
contributor boundaries
provenance

For Open Period Care, the final Qdrant lookup used metadata such as:

observation.metadata.bridge = open-period-care

plus:

knowledgeCardId = KC-OPC-001

or:

knowledgeCardId = KC-OPC-002

The credential record was selected using its canonical source path.

This produced exactly three scoped sources:

6133cdc69da3ae31
b29f3d1f6b99f5e1
48f5cbbaa4581906

All of them belonged to Open Period Care.

Zorgax then received only that bounded source set.

The output became:

KC-OPC-001
Multi-Layer Biomaterial Architecture for Reusable Textile Absorbents
SUPPORTED

and:

KC-OPC-002
Contributor Privacy, Data Minimization & Clinical Boundaries
SUPPORTED

It also correctly answered that the available sources do not establish a personal medical certification for khongten124.

Final result:

Contributor-scoped
Open Period Care
→ Qdrant
→ Zorgax

TESTED

8. A second bridge type: independent verifier

We then applied the same evidence philosophy to a completely different contributor.

Shweta-singh24 had produced a MyZubsterGateway jurisdiction-policy implementation.

The exact checkpoint was:

commit:
82461433e0c5bfee9aa369b4a71e9331261cf803

upstream PR:
MyZubster-Ecosystem/MyZubsterGateway#1385

The upstream PR was closed and unmerged.

That distinction was retained explicitly.

We built an independent verifier script that cloned the contributor's repository at the exact commit and executed policy checks.

Policy behavior tested

The implementation defined several capabilities:

wallet_transfer
exchange_flow
external_settlement
provider_crypto

The verifier tested:

GLOBAL       → ALLOW
HK           → ALLOW
CN_MAINLAND  → DENY

for known capabilities.

It also verified:

UNKNOWN_JURISDICTION → DENY
UNKNOWN_CAPABILITY   → DENY

That confirmed fail-closed behavior.

Route wiring

The verifier also checked that jurisdiction enforcement was wired into:

Tari wallet transfer
Tari external settlement
XMR wallet transfer
XMR external settlement

and confirmed the middleware denial path included:

HTTP 403
JURISDICTION_POLICY_DENIED

All JavaScript syntax checks passed as well.

Final result:

Shweta jurisdiction capability
verifier checkpoint:

TESTED

Again, the scope remained bounded.

It does not mean:

merged upstream
deployed in production
legally certified
security certified

It means we independently reproduced the exact technical checkpoint.

9. CI exposed a repository-wide security problem

At that point the contributor work was functioning, but our CI pipeline still refused to become green.

Two workflows failed:

Security Audit
Continuous Evidence Gate

The failure was unrelated to the new Python contributor bridges.

The dependency tree contained:

compression 1.8.1

with a high-severity issue, and:

proxy-addr 2.0.7

with a critical issue.

Instead of weakening the CI gate, we opened an isolated security PR.

The fix updated:

compression → 1.8.2
proxy-addr → 2.0.8

and regenerated the corresponding lock entries.

After the fix:

Security Audit             PASS
Continuous Evidence Gate   PASS
CI – Test e Lint           PASS
Seller Free policy         PASS
Vercel                     PASS

The security baseline was merged in:

PR #1510
aa5aa8883a993c99b50e233bea29c5da2f3497f0

10. Re-running contributor PRs against the clean baseline

With the repository security baseline fixed, we reran the contributor integrations.

The Shweta verifier passed every required workflow and was merged:

PR #1509

aa54fd380e487c11ba39fb40a092212f412cf364

The original Open Period Care branch had become non-mergeable after main moved.

Instead of forcing a conflict resolution into an old branch, we created a replacement from the current main and carried over exactly the six tested bridge files.

That became:

PR #1511

Its final checks were:

Security Audit             PASS
Continuous Evidence Gate   PASS
CI – Test e Lint           PASS
MYZ-164 Seller Free        PASS
Vercel                     PASS

and it was merged as:

6061140f4ade01ab10211b2a6698cac03f326e55

The architecture we ended up with

By the end of the session we had three distinct interoperability patterns.

Runtime bridge

N4K48
   ↓
independent Docker reproduction
   ↓
API
   ↓
Qdrant
   ↓
Zorgax

Evidence / semantic bridge

Open Period Care
   ↓
public source artifacts
   ↓
normalization + SHA-256 + provenance
   ↓
Qdrant
   ↓
contributor-scoped metadata lookup
   ↓
Zorgax

Verifier bridge

Contributor commit
   ↓
exact SHA checkout
   ↓
independent executable tests
   ↓
structured verifier result
   ↓
bounded TESTED checkpoint

The implementations are different.

The evidence philosophy is the same.

Engineering lessons

1. Commit SHAs are better interoperability anchors than branches

Branches move.

A reproducibility claim should point to something immutable.

2. A RAG system needs negative tests

Do not only test:

Can it answer this known question?

Also test:

Will it refuse to invent an unsupported answer?

3. Vector similarity is not an identity system

Embeddings answer:

What looks similar?

Metadata answers:

Which exact record is this?

A serious evidence system needs both.

4. Structured facts should remain structured

Do not ask an LLM to reinterpret authoritative values if you already possess them as metadata.

Prefer:

knowledgeCardId = KC-OPC-001
status = SUPPORTED

over trying to reconstruct them from generated prose.

5. Shared vector stores require isolation boundaries

When several contributors share one collection, cross-contributor retrieval becomes a real failure mode.

Contributor/project metadata filters are not optional once the collection becomes heterogeneous.

6. A failed checkpoint is better than a false success

During this work we deliberately kept several runs as:

FAILED

until the exact conditions were satisfied.

Those failures revealed the most useful architectural problems.

7. Do not bypass security gates because your feature did not cause the issue

Our contributor PRs did not introduce the npm vulnerabilities.

But merging through red security gates would still have weakened the engineering process.

The correct solution was to repair the shared baseline first.

Final state

The relevant merged work now includes:

#1509
Shweta independent verifier bridge

#1510
Repository npm security baseline repair

#1511
Open Period Care contributor bridge

The MyZubster contributor matrix now records both Open Period Care and the Shweta checkpoint using bounded, reproducible technical states.

What started as a contributor-integration experiment ended up giving us a reusable pattern:

independent work
+ immutable provenance
+ reproducible test
+ structured metadata
+ scoped AI retrieval
+ explicit evidence boundaries

That is the foundation we intend to use for the next contributor integrations.

Not everyone needs to run the same node.

Not everyone needs to provide the same artifact.

But every interoperability claim should be reproducible, attributable and precise about what was — and was not — demonstrated.

From GitHub Contributions to a Public Knowledge Graph: What We're Building with MyZubster

Fri, 02 Oct 2026 17:17:25 +0000

From GitHub Contributions to a Public Knowledge Graph: What We're Building with MyZubster

How we connected independent contributors, public development evidence, Knowledge Cards, and an interactive graph — and what we learned along the way.

By Daniel Ioni | MyZubster | October 2026

Topics: Open Source, JavaScript, Node.js, GitHub, Knowledge Graphs, Developer Tools, AI

What if a GitHub contribution could become reusable knowledge?

A pull request contains more than code.

It can represent hours of debugging, architectural decisions, technical research, new testing methods, and practical experience. Yet much of that knowledge remains scattered across repositories, commits, discussions, and documentation.

At MyZubster, we have been experimenting with a system that connects these different sources without losing their original context.

Our idea is relatively simple:

Every documented contribution should have the opportunity to become part of a discoverable knowledge network.

Instead of automatically converting repository activity into claims about someone's abilities, we want to preserve the original evidence and give contributors the option to build their own knowledge records around it.

This experiment started with our collaboration with Nicola and has progressively expanded to other open-source contributors.

Our latest development milestone is now available through the public MyZubster Knowledge Graph.

Explore it here: MyZubster Interactive Knowledge Graph

In this article, we'll explain our implementation, the problems we encountered, and how other developers can apply similar principles to their own projects.

1. Starting with a real contributor: Nicola

Our initial experiment involved working with Nicola, also known as N4K48.

We wanted to explore how an independent contributor could document technical work, preserve ownership of their own development environment, and connect their knowledge to a broader ecosystem.

Our collaboration has involved software development, Docker, GitHub workflows, and the documentation of technical experiments.

An important part of this process was learning to distinguish between an experiment that works locally and a fully validated integration.

For example, we prepared experimental infrastructure for a MyZubster Node Bridge, including HTTPS endpoints and Docker-related workflows.

However, preparing an accessible server is not the same as proving that an independent contributor's machine has completed every stage of a distributed integration.

This distinction influenced the entire knowledge system.

We began asking: what exactly does each piece of evidence prove?

A repository commit might document a code change. A test result can support a claim about specific behavior. A deployment record shows that a deployment occurred.

None of these records automatically proves every broader claim about a project's maturity.

We carried this principle into the design of our Knowledge Cards.

Technical references:

2. Building Knowledge Cards with supporting evidence

A Knowledge Card is a structured record that describes a specific piece of knowledge or experience.

Instead of storing a generic statement such as "I know backend development," a card can describe a particular technical activity and link to supporting evidence.

Consider this illustrative example:

{
  "title": "API Integration Testing",
  "domain": "Backend Engineering",
  "description": "Developed tests for an API integration",
  "evidence": [
    {
      "label": "Public GitHub Pull Request",
      "url": "https://github.com/example/project/pull/123"
    }
  ],
  "verificationNote": "Public source linked; broader skill claims have not been independently verified."
}

This is a simplified example rather than the complete MyZubster production schema.

The important elements are the relationship between a claim, its source, and its verification status.

We also wanted contributors to control publication.

Our backend therefore distinguishes between private drafts and public Knowledge Cards.

The public catalog is served through:

GET /api/knowledge-evidence/public

The relevant backend query is based on two explicit conditions:

const cards = await KnowledgeDraft.find({
  status: 'published',
  visibility: 'public'
});

This design avoids exposing private drafts simply because they exist in the database.

It also means that creating a draft and publishing a card are separate operations.

The public catalog is not a complete inventory of every contributor's private knowledge. It contains only records that satisfy the publication requirements.

3. Turning individual records into an interactive graph

Once we had a public knowledge catalog, another problem became apparent.

A list of cards provides useful information, but it does not immediately show how everything connects.

One contributor might work across several domains. Multiple cards might reference related public evidence. Different contributors might work on separate aspects of the same technical problem.

We introduced an interactive graph to make those relationships easier to explore.

Pull Request #1438 implemented the initial public graph.

It connects four principal node types:

Knowledge Cards
Contributors
Knowledge domains
Public evidence sources

Conceptually, the initial graph can be represented as:

              Knowledge Domain
                     |
                     |
Contributor ---- Knowledge Card
                     |
                     |
               Public Source

The frontend retrieves public cards, builds the node and relationship structures, and renders them as an interactive visualization.

Users can search, filter, select nodes, and inspect the related information.

The implementation also preserves verification notes, which help communicate the limitations of the evidence displayed.

Try it: Interactive Knowledge Graph

4. The problem we discovered: our contributors were missing

After introducing the graph, we discovered an important limitation.

We already had several contributors with documented public GitHub activity. But many of them did not appear in the Knowledge Graph.

The reason was straightforward: the graph was built exclusively from personally published Knowledge Cards.

A public pull request was not enough to create a graph node.

We had two possible approaches.

The first was to automatically generate personal Knowledge Cards for contributors based on their repository activity.

We decided against that approach.

A public pull request does not necessarily authorize another organization to create a personal knowledge profile, publish private information, or assign qualifications.

Instead, we implemented a second evidence layer.

Our solution: separate GitHub contributions from personal Knowledge Cards

On October 2, 2026, we integrated Pull Request #1453.

The update adds selected, publicly documented GitHub contributions to the Knowledge Graph.

These contributions are represented separately from owner-published Knowledge Cards.

The expanded model now looks conceptually like this:

                    Knowledge Domain
                      /        \
                     /          \
           Knowledge Card    Public GitHub PR
                 |                |
                 |                |
            Contributor       GitHub Account
                 |
                 |
           Public Evidence

This separation matters because the two types of records have different meanings.

A Knowledge Card is a record explicitly published by its owner.

A GitHub contribution record documents public activity associated with a repository.

The second record does not automatically become the first.

Preserving pull request status

We also distinguish between different contribution states.

For example:

const workStatus = {
  merged: 'PR integrated',
  submitted: 'PR submitted / not integrated',
  closed_without_merge: 'PR closed without integration'
};

This helps prevent a common documentation mistake: presenting submitted or abandoned work as a completed production feature.

Our initial implementation uses a curated selection of public GitHub contributions. It is not an unrestricted or continuously synchronized GitHub crawler.

Records must be reviewed and updated as their underlying status changes.

The change has been merged, and the corresponding Vercel production deployment reached the ready state.

View the Implementation — PR #1453

5. Real examples from our open-source community

We began the new contribution layer with documented activities from several MyZubster contributors.

These examples demonstrate how a knowledge graph can connect completely different technical domains.

NFC development and documentation

Contributor @jdjioe5-cpu has public contributions related to our Animal Registry.

The associated work covers browser-based NFC simulation, physical tag design, and API documentation.

Rather than combining these into one generic skill label, the individual contributions can be represented separately.

Sources:

Geospatial development

Contributor @leanworld7-netizen has a merged contribution addressing garden geolocation and area-based search.

This connects backend engineering with geographic data and community-garden applications.

Garden Geolocation — PR #57

Frontend and telemetry

Contributor @laurentketterle-hub has a merged contribution involving a Space Station telemetry dashboard.

It provides an example of how frontend development and monitoring can be represented within a larger knowledge network.

Telemetry Dashboard — PR #399

Automated testing

Contributor @foxxx009 has a merged contribution involving automated tests for GitHubMonitor.

Test automation is an interesting knowledge domain because the associated evidence can include both the implemented tests and their documented execution.

GitHubMonitor Tests — PR #259

Other selected records represent work involving security, documentation, and metaverse integration.

Their individual states are preserved rather than automatically presenting every submission as an accepted result.

6. From Knowledge Cards to Contributor Passports

Our next question was how to connect multiple contributions made by the same person.

That led us to introduce the Contributor Passport framework.

The idea is to organize evidence-backed knowledge records into a coherent contributor history.

The conceptual sequence is:

Contribution
     |
     v
Public Evidence
     |
     v
Knowledge Card
     |
     v
Contributor Passport
     |
     v
Optional Independent Pilot Node

We integrated the framework through PR #1445.

Contributor Passports are not automatic professional certifications.

They are intended to organize documented contributions, declared knowledge, and associated evidence.

Participation is also optional.

A contributor should not be required to publish private personal information or enroll in a separate program merely to participate in open-source development.

Read the Contributor Pilot Node Framework

7. Independent nodes and the future of distributed collaboration

An interesting extension of the Contributor Passport is the Independent Contributor Pilot Node.

The concept explores whether contributors can maintain their own development scope and technical identity while connecting relevant knowledge to MyZubster.

Potential applications include independent software projects, robotics, documentation, testing, and environmental monitoring.

However, publishing the framework is only one step.

Actually deploying independent nodes requires reproducible onboarding, clearly defined technical interfaces, and end-to-end validation.

We are treating these as separate milestones.

8. Paid Bounties and transparent contributor agreements

We have also introduced a public Paid Bounties page.

Explore MyZubster Paid Bounties

The system distinguishes proposed tasks from explicitly reserved work.

This is another example of why precise status information matters.

An interesting technical proposal should not be confused with a funded contract.

Likewise, completing a Knowledge Card should not automatically authorize a contributor's enrollment in a separate development program.

We are experimenting with connecting accepted contributions, documented evidence, optional knowledge records, and separately agreed rewards.

Our implementation is documented in PR #1444.

9. What other developers can learn from this experiment

Our development process has highlighted several principles that are useful beyond MyZubster.

First, keep the original source accessible.

A knowledge claim becomes easier to examine when people can follow its supporting evidence back to an original repository, commit, pull request, or document.

Second, model different evidence states explicitly.

Private drafts, published cards, submitted pull requests, merged contributions, and reviewed scientific results should not share a single generic verification label.

Third, separate evidence from interpretation.

A merged pull request provides evidence of integration. Interpreting the skills required to produce it may require additional context.

Fourth, respect contributor consent.

Public development activity does not automatically authorize the creation of a personal profile or the disclosure of unrelated personal information.

Fifth, test the relationships, not just individual features.

A knowledge system depends on the integrity of the connections between contributors, claims, sources, and publication states.

Our public contributor graph update introduced regression tests designed to preserve the distinction between GitHub evidence and personally published Knowledge Cards.

The change passed our CI, security, and evidence-gate workflows before integration.

10. Explore the project and contribute

We are developing MyZubster openly because we believe the knowledge generated during development should be useful to other people.

Our next challenges include expanding contributor participation, improving the accessibility of the Knowledge Graph, maintaining accurate public contribution records, and further validating independent development environments.

We welcome technical reviews, reproducible bug reports, documentation improvements, and contributions that help make the system more transparent.

Project links:

If you maintain an open-source project, we'd also be interested in discussing how you document the knowledge created by your contributors.

Do you currently rely on README files, documentation websites, GitHub discussions, contributor profiles, or something else?

Our experiment is built around one idea: preserve the evidence, document the knowledge, and make the connections visible.

MyZubster is an evolving open-source project. Public GitHub evidence, contributor-declared knowledge, independently verified results, and experimental infrastructure are represented as distinct concepts.

Building MyZubster's Economic Layer: Multichain Payments, Zorgax Pro and Non-Custodial Architecture

Fri, 28 Aug 2026 08:05:21 +0000

Building the Economic Layer of MyZubster: Multichain Payments, Zorgax Pro and Non-Custodial Architecture

MyZubster is evolving from a collection of independent experiments into a connected ecosystem.

During the latest development cycle, we connected several previously separate areas:

Metaverse → Marketplace → Wallet Hub → blockchain payments → Zorgax services

At the same time, we reorganized the project's visual layer to better separate marketplace, AI, storytelling and our exploratory LIFE 2027 direction.

The most important part, however, is not the number of features.

It is the architecture connecting them.

The Core Principle: The Application Is Not the Wallet

When adding cryptocurrency payments to a marketplace, it is tempting to put everything inside the application.

That creates a dangerous boundary.

MyZubster instead follows a non-custodial principle:

Public receiving address → OK

Transaction identifier → OK

Blockchain verification → OK

Private key → NEVER

Seed phrase → NEVER

Wallet signing credentials → NEVER

The application can coordinate a payment without becoming responsible for the cryptographic keys controlling the funds.

That principle became the foundation of our new multichain Wallet Hub.

Connecting the Metaverse Market to Multiple Networks

The MyZubster Marketplace has been extended to support:

ETH
BTC
XMR
TARI
MYZ
BARTER
FREE

The Wallet Hub provides the bridge between marketplace activity and the external blockchain networks.

The architecture looks roughly like this:

         MyZubster Metaverse
                 │
                 ▼
            Marketplace
                 │
                 ▼
             Wallet Hub
                 │
    ┌────────────┼────────────┐
    │            │            │
   ETH          BTC          XMR
    │            │            │
    └────────────┼────────────┘
                 │
                TARI

The frontend can expose configured public receiving addresses.

It does not receive or store private keys.

The implementation can be inspected here:

PR #811 — Connect metaverse market to multichain wallet hub

The work is now integrated into the main development history.

From Zorgax Assistant to Zorgax Service

Once the payment architecture existed, another question became interesting:

Can Zorgax become a monetizable service?

We started building that foundation as well.

The first catalog introduces three levels:

Zorgax Free

Zorgax Pro
€9.90 / month equivalent

Zorgax Developer
€29.90 / month equivalent

Paid checkout intents are designed around:

ETH
BTC
XMR
TARI

But creating a checkout is deliberately not equivalent to activating a subscription.

That distinction is critical.

Never Trust “I Paid”

Consider a naïve API:

POST /zorgax/activate

{
"paid": true
}

Obviously, that cannot be trusted.

Even providing a transaction hash is insufficient by itself.

The backend needs to establish that the transaction:

exists
+
belongs to the expected network
+
matches the checkout
+
uses the expected destination
+
contains the required amount
+
has sufficient confirmation/finality
+
has not already been consumed

Only then should application state change.

Our target flow therefore becomes:

User selects Zorgax Pro

    │
    ▼

Create checkout intent

    │
    ▼

Generate crypto quote

    │
    ▼

User sends transaction

    │
    ▼

Network-specific verifier

    │
    ▼

Payment VERIFIED

    │
    ▼

Subscription ACTIVE

    │
    ▼

30-day entitlement

    │
    ▼

EXPIRED / RENEW

This is considerably safer than allowing the frontend to decide whether payment succeeded.

Building the Subscription Lifecycle

The Zorgax monetization work now includes a persistent subscription lifecycle.

Internally, the important states are conceptually:

PENDING
│
▼
VERIFIED
│
▼
ACTIVE
│
▼
EXPIRED

Verified paid access receives a defined validity period.

Renewals can extend access from the existing expiration point when the current subscription is still active.

Payment references are also intended to be single-use.

That prevents a valid transaction from being replayed to create multiple entitlements.

The current implementation is being developed here:

PR #812 — Zorgax monetization foundation

One security decision is particularly important:

the client does not receive a public endpoint capable of declaring its own payment verified.

Activation belongs behind a trusted blockchain-verification boundary.

One Interface, Different Blockchain Adapters

ETH, Bitcoin, Monero and Tari cannot simply be treated as identical networks.

They have different transaction models, privacy properties, RPC interfaces and finality considerations.

Instead of forcing all of them into one blockchain-specific implementation, the architecture can use adapters:

               Payment Intent
                     │
                     ▼
             Verification Layer
                     │
      ┌──────────────┼──────────────┐
      │              │              │
 BTC verifier   XMR verifier   ETH verifier
      │              │              │
      └──────────────┼──────────────┘
                     │
               TARI verifier
                     │
                     ▼
            Normalized Result
                     │
                     ▼
             VERIFIED / REJECTED

The subscription system should not need to understand every detail of Bitcoin or Monero.

It needs a trustworthy normalized result from the corresponding verifier.

This separation also makes testing easier.

The Marketplace Doesn't Move the Money

Another important distinction is between coordination and custody.

MyZubster can coordinate:

product
price
currency
checkout
payment reference
verification
entitlement

without taking responsibility for:

seed storage
private-key storage
transaction signing
wallet recovery

This gives us a cleaner security boundary.

It also means a compromised web application should not automatically imply compromised blockchain private keys.

Connecting Zorgax to the Economic Layer

This creates an interesting relationship between the different parts of MyZubster.

Zorgax is no longer isolated from the rest of the ecosystem.

Conceptually:

              MYZUBSTER
                  │
    ┌─────────────┼─────────────┐
    │             │             │
 ZORGAX       METAVERSE     REAL-WORLD
    │             │        EXPLORATION
    │             │

PRO SERVICES MARKET

    │             │
    └──────┬──────┘
           │
      WALLET HUB
           │
  ┌────────┼────────┐
  │        │        │
 ETH      BTC      XMR
           │
          TARI

This is the beginning of an economic layer rather than simply a cryptocurrency button attached to a website.

Organizing the Visual Architecture Too

Architecture is not limited to source code.

During the same development cycle, we reorganized the MyZubster visual assets into dedicated areas:

docs/
└── visuals/

├── life-2027/
├── market/
├── storytelling/
└── zorgax/

Nine assets covering environmental concepts, AI/permaculture, marketplace entities, Zorgax characters and storytelling were organized and committed to the repository.

The commit is available here:

Commit af8b1dd — Organize MyZubster visual assets for LIFE 2027

This may sound secondary to backend development, but maintaining clear boundaries between technical, narrative and exploratory material becomes increasingly important as an ecosystem grows.

A Note About LIFE 2027

The life-2027 directory represents an exploratory direction, not a claim that MyZubster has an approved or funded LIFE project.

Our intended progression is evidence-driven:

concept
↓
pilot
↓
measurements
↓
KPIs
↓
technical/scientific validation
↓
consortium development
↓
potential proposal

For environmental technology, code alone is not evidence of environmental impact.

Claims around water efficiency, soil conditions or other environmental outcomes ultimately need measurable results and appropriate validation.

Keeping that distinction explicit is part of the project's engineering discipline too.

What Comes Next

The architecture for monetization is taking shape.

The next major challenge is implementing the actual verification adapters.

For example:

Bitcoin
↓
network/Electrum verification

Monero
↓
node/wallet RPC verification

Ethereum
↓
Ethereum RPC verification

Tari
↓
Tari network verification

After that, we can safely connect:

quote
→ checkout
→ transaction
→ verification
→ entitlement
→ Zorgax Pro
→ expiry
→ renewal

without turning MyZubster into a custodial wallet.

That is the boundary we intend to preserve as the system grows.

Source Code

The project is open source:

MyZubster Ecosystem repository

Multichain Marketplace integration:

PR #811 — Metaverse Market + Wallet Hub

Zorgax monetization:

PR #812 — Zorgax monetization foundation

Visual architecture:

Commit af8b1dd — LIFE 2027, Market, Zorgax and Storytelling visuals

Suggested Coder Legion title:
Building MyZubster's Economic Layer: Multichain Payments, Zorgax Pro and Non-Custodial Architecture

Coder Legion - Recent posts tagged source

How to Deduplicate Leads in n8n Before They Reach Your CRM

First identify which duplicate you are stopping

Choose identity keys before building nodes

A practical n8n workflow shape

Step 1: normalize the fields once

Step 2: use Remove Duplicates for the narrow job it does well

Step 3: add a persistent lookup

Option A: n8n Data Table for a small lead ledger

Option B: search the CRM directly

Step 4: route new, matched, and conflicting leads

Step 5: make the CRM write duplicate-safe

Test with a small duplicate matrix

Common mistakes

Useful questions before publishing

Can Remove Duplicates replace a CRM lookup?

Should email or phone be the main key?

Should a duplicate lead be discarded?

Privacy and operating rules

Sources checked

Building Evidence-First Contributor Interoperability with VPS Checkpoints, GitHub Provenance and I

Building Evidence-First Contributor Interoperability with VPS Checkpoints, GitHub Provenance and Independent Verifiers

The core idea

Git history is part of the evidence

Why use a VPS?

Contributor checkpoint 1: N4K48 as an independent Docker node

Contributor checkpoint 2: Open Period Care

Semantic search is not identity

Contributor checkpoint 3: Shweta and an unmerged commit

Contributor checkpoint 4: wasim-builds

Contributor checkpoint 5: Aming9303

Contributor checkpoint 6: foxxx009

The verifier failed twice

Why a verifier should be intentionally boring

What we mean by decentralization

Decentralized provenance

Independent reproducibility

Interoperability through evidence

Contributor-to-contributor links come next

How to join MyZubster as a contributor

1. Build something narrow

2. Publish the source

3. Define the test contract

4. List dependencies

5. Define what success means

6. Run the independent checkpoint

What successful contribution can connect to

A note about AI

The architecture we are working toward

Lessons from today's work

1. Immutable commits beat moving branches

2. FAILED must remain meaningful

3. A verifier can be wrong

4. Semantic search is discovery, not identity

5. TESTED must remain bounded

6. Contributors do not need identical infrastructure

Want to contribute?

Final thought

Building Evidence-First Contributor Interoperability with Qdrant, Zorgax and Reproducible Checkpoint

Building Evidence-First Contributor Interoperability with Qdrant, Zorgax and Reproducible Checkpoints

The problem

1. Reproducing an independent contributor runtime

2. Adding evidence to the semantic layer

3. Connecting a research contributor

4. The first semantic integration failed

5. Structured facts should not be delegated to free-form generation

6. Cross-contributor vector contamination

7. Semantic discovery + deterministic metadata lookup

Semantic search

Deterministic metadata lookup

8. A second bridge type: independent verifier

Policy behavior tested

Route wiring

9. CI exposed a repository-wide security problem

10. Re-running contributor PRs against the clean baseline

The architecture we ended up with

Runtime bridge

Evidence / semantic bridge

Verifier bridge

Engineering lessons

2. `FAILED` must remain meaningful

5. `TESTED` must remain bounded