DEV Community: Daniel Ioni

MyZubster Engineering Dev Log

Daniel Ioni — Sun, 27 Sep 2026 00:52:31 +0000

MyZubster Engineering Dev Log

Sepolia E2E Infrastructure, Google OAuth Validation, Runtime Stabilization and the Road Toward a Production-Grade Platform

Over the last development cycle, we focused on one of the least visible but most important parts of the MyZubster architecture: making the development and Sepolia environments deterministic enough to support real authentication, blockchain payment validation, persistent backend services, and auditable CI/CD workflows.

This was not simply a feature implementation.

The work involved debugging several layers of the system simultaneously:

Node.js runtime dependencies
PM2 process supervision
MongoDB connectivity
reverse-proxy behavior
Google OAuth callbacks
frontend/backend routing
Sepolia E2E infrastructure
Git branch isolation
secret hygiene
GitHub CI evidence generation
deployment diagnostics

The objective is to move MyZubster from a system where individual components work independently toward an environment where the entire lifecycle can be reproduced, tested and eventually promoted safely.

1. Starting Point

The environment initially had several runtime and infrastructure issues that prevented reliable E2E validation.

One of the first failures appeared in the UrbanLab Node.js service:

Error: Cannot find module 'helmet'
Require stack:
- /opt/I-ECO-01/server.js

Inspection of server.js showed that the application required:

require('dotenv').config();

const express = require('express');
const cors = require('cors');
const helmet = require('helmet');
const mongoose = require('mongoose');
const { createServer } = require('http');
const { Server } = require('socket.io');
const winston = require('winston');

However, the original dependency tree only contained:

cors
dotenv
express
mongoose

Three runtime dependencies were missing:

helmet
socket.io
winston

This mismatch caused PM2 to continuously restart the application.

At one point, the process had accumulated millions of restart attempts.

This is an important operational lesson:

A process manager can keep a process alive, but it cannot make an invalid runtime healthy.

PM2 was correctly restarting the process. The actual problem was an incomplete dependency graph.

2. Runtime Dependency Repair

The missing modules were installed and persisted into package.json.

The resulting dependency set included:

{
  "cors": "^2.8.5",
  "dotenv": "^17.4.2",
  "express": "^4.18.2",
  "helmet": "^8.3.0",
  "mongoose": "^9.9.2",
  "socket.io": "^4.8.4",
  "winston": "^3.19.0"
}

Module resolution was then explicitly verified.

OK: helmet
OK: socket.io
OK: winston

After repairing the dependency tree, the UrbanLab backend successfully initialized.

Runtime output confirmed:

Server started on port 5002
MongoDB connected

The health endpoint returned:

{
  "status": "ok",
  "service": "I-ECO-01",
  "mongodb": "connected"
}

More importantly, PM2 stability was tested over time.

The PID remained unchanged and the restart counter stopped increasing.

This confirmed that the restart loop had actually been eliminated rather than temporarily hidden.

3. PM2 Runtime Stabilization

The next step was validating the persistent process topology.

The VPS currently runs multiple independently supervised services, including:

cloudflared
myzubster-sepolia-e2e
myzubster-social
myzubster-web
urbanlab

For the Sepolia backend, we verified that the process remained online after restart and that a stable PID was assigned.

After the final restart:

myzubster-sepolia-e2e → online
PID → 1152840

The active PM2 process list was then persisted using:

pm2 save

which generated:

/root/.pm2/dump.pm2

This matters because runtime recovery must survive more than an individual shell session.

A service that works until the VPS reboots is not a completed deployment.

4. MongoDB Connectivity

Database connectivity was validated alongside application startup.

The backend reported:

MongoDB connected

and the public health path remained responsive.

The architecture also contains a database gate around routes requiring persistence.

Conceptually:

HTTP request
      │
      ▼
requireDatabase
      │
      ├── MongoDB available ──► route handler
      │
      └── MongoDB unavailable ──► HTTP 503

This prevents database-dependent operations from silently executing against an unavailable persistence layer.

Instead, failure becomes explicit and observable.

5. Google OAuth Investigation

The next major objective was Google OAuth.

The public provider endpoint confirmed:

{
  "success": true,
  "data": {
    "providers": {
      "google": true,
      "github": false,
      "facebook": false
    }
  }
}

This result was reproduced against both the local backend and the public Sepolia endpoint.

Therefore:

Google   → enabled
GitHub   → disabled
Facebook → disabled

The provider configuration itself was not the primary problem.

The investigation moved deeper into the OAuth callback lifecycle.

6. OAuth Callback Observability

Temporary instrumentation was introduced at multiple points in the OAuth flow.

The goal was to answer a specific question:

Does Google's callback actually reach the intended backend process with the expected OAuth parameters?

Instrumentation captured:

method
path
host
x-forwarded-host
x-forwarded-proto
code presence
state presence
error presence

A clean callback produced:

[HTTP-GOOGLE-CALLBACK] {
  method: 'GET',
  path: '/api/auth/social/google/callback',
  host: '127.0.0.1:5010',
  forwardedHost: null,
  forwardedProto: 'https',
  hasCode: true,
  hasState: true,
  hasError: false
}

This result was extremely useful.

It demonstrated that:

Google reached the callback.
The callback reached the Node.js backend.
The authorization code was present.
OAuth state was present.
Google did not return an OAuth-level error.
HTTPS information survived the proxy path.
The backend was listening behind the expected local port.

The effective request path is therefore approximately:

Google
   │
   ▼
https://sepolia.myzubster.com
   │
   ▼
reverse proxy / tunnel
   │
   ▼
127.0.0.1:5010
   │
   ▼
Express
   │
   ▼
/api/auth/social/google/callback

That eliminated several possible failure classes at once.

7. OAuth Session Error Isolation

During investigation, an earlier callback produced:

[OAUTH-CALLBACK-ERROR] {
  provider: 'google',
  message: 'Sessione OAuth mancante. Riavvia il login dal pulsante MyZubster.'
}

Instead of assuming the provider itself was broken, logs were reset and the authentication flow was reproduced from a clean state.

The backend logs were truncated intentionally before the next test so historical errors could not be confused with current behavior.

After the clean test:

ERROR LOG
empty

while the output log showed the callback arriving correctly.

This distinction is operationally important.

Historical log entries are not evidence of a current failure.

For authentication debugging, each reproduction should ideally have a clearly bounded observation window.

8. Temporary Instrumentation Cleanup

Once the callback path had been verified, temporary HTTP-level debugging was removed from server.js.

The diagnostic block used during investigation was intentionally not kept as permanent production code.

Syntax validation was then performed again:

node --check server.js

Result:

backend syntax OK

Temporary backup files created during the investigation were also identified and removed from the Git working tree.

This left the repository in a controlled state instead of accidentally committing debug artifacts.

9. Permanent OAuth Error Logging

One diagnostic improvement was intentionally retained.

Previously, callback errors were handled essentially as:

catch (error) {
  redirectError(res, error.message, provider);
}

This made failures visible to the browser but provided limited server-side evidence.

The callback now records a concise structured error:

catch (error) {
  console.error('[OAUTH-CALLBACK-ERROR]', {
    provider,
    message: String(error?.message || error)
  });

  redirectError(res, error.message, provider);
}

This gives operators useful information without intentionally logging OAuth tokens or credentials.

The objective is not maximum logging.

The objective is minimum sufficient observability.

10. Secret Hygiene

Before committing anything, the working tree was explicitly inspected.

Special attention was given to:

.env
.env.local
.env.*.local
frontend/.env
backend/.env

The repository's .gitignore already excludes these files.

Staging was also checked independently to ensure no environment file had entered the Git index.

Result:

No ENV files staged

The modified files were inspected for obvious credentials, tokens or secrets before commit.

No evident secret was found in the intended patch.

This is particularly important for OAuth work because debugging often involves credentials, authorization codes and provider configuration.

Those values must never become part of the repository history.

11. Frontend Proxy Investigation

During troubleshooting, a Create React App development proxy was considered:

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'http://127.0.0.1:5010',
      changeOrigin: true
    })
  );
};

However, inspection showed:

http-proxy-middleware → not installed

Rather than introducing an unnecessary dependency or accidentally changing the deployment topology, the temporary proxy experiment was removed.

This kept the final change set focused on the problem actually being solved.

12. Repository Cleanup

Several investigation backups existed temporarily:

server.js.before-oauth-http-debug-...
server.js.oauth-working-...
socialAuthController.js.backup-debug
socialAuthController.js.before-google-token-debug
socialAuthController.js.before-oauth-debug
socialAuthController.js.oauth-working-...

These files were useful during live debugging but were not appropriate repository artifacts.

They were removed before the final commit.

After cleanup, the Git working tree contained only the intended source modification.

13. The Final Commit

The OAuth diagnostics improvement was isolated into a dedicated commit:

02f06f22
fix(auth): improve OAuth callback error logging

The commit modified only:

src/controllers/socialAuthController.js

The patch consisted of:

19 insertions
2 deletions

This was deliberate.

Infrastructure debugging often touches many files temporarily. A good final commit should contain the solution, not the entire debugging history.

14. Branch Isolation

The work was performed on:

vps/sepolia-e2e-test

The branch was pushed to the developer fork:

danieldirimini-myzubster/myzubster

and configured to track:

origin/vps/sepolia-e2e-test

The repository was clean after the push.

This provides a reproducible boundary between:

production/main development
        │
        └── isolated Sepolia validation branch

rather than making ad-hoc changes directly against the canonical branch.

15. Pull Request Created

The work was submitted upstream as:

PR #1394
fix(auth): improve OAuth callback error logging

The PR targets:

test/eth-sepolia-e2e-validation-20260925

from:

vps/sepolia-e2e-test

The PR currently contains one commit and one changed file.

GitHub reports the PR as mergeable, meaning there is currently no Git merge conflict blocking integration.

The PR was intentionally scoped to the OAuth callback diagnostics discovered during Sepolia E2E validation.

16. CI/CD Evidence Gate

Opening the PR triggered the project's:

Continuous Evidence Gate

The pipeline performs substantially more than a basic syntax check.

The observed stages include:

Set up job
        │
        ▼
Checkout
        │
        ▼
Set up Node
        │
        ▼
Install exact dependency tree
        │
        ▼
Run tests
        │
        ▼
Run vulnerability audit
        │
        ▼
Generate CycloneDX SBOM
        │
        ▼
Build evidence manifest
        │
        ▼
Upload auditable evidence

At the latest inspection, environment setup, checkout, Node setup and exact dependency installation had completed successfully.

The test stage was running.

This is an important architectural direction for MyZubster.

A successful change should eventually mean more than:

"It works on the VPS."

It should mean:

source
  +
tests
  +
dependency reproducibility
  +
security audit
  +
SBOM
  +
evidence manifest
  +
deployment validation

17. Sepolia E2E Work Already Present

The branch sits on top of a larger Sepolia payment-validation effort.

Relevant preceding commits include work for:

real-wallet Sepolia E2E harness
Sepolia E2E verifier
Sepolia E2E runbook
manual Sepolia evidence workflow
independent payment verifier
Sepolia ETH sandbox lifecycle
MetaMask payment UI tests

This means OAuth debugging is not an isolated feature.

It is part of a broader effort to establish a real sandbox where identity, wallet interaction, payment execution and backend persistence can eventually be tested together.

The target is a complete lifecycle:

User
 │
 ▼
Authentication
 │
 ▼
MyZubster Identity
 │
 ▼
Wallet
 │
 ▼
Marketplace / Service
 │
 ▼
Sepolia Transaction
 │
 ▼
Blockchain Verification
 │
 ▼
Backend Persistence
 │
 ▼
Application State Transition
 │
 ▼
Auditable Evidence

18. What We Have Successfully Proven

At this stage, we have evidence for several important properties of the environment.

Runtime

Node.js services can remain stable under PM2 after dependency correction.

Database

MongoDB connectivity is available to the relevant backend environment.

Public routing

The Sepolia backend can be reached through the public endpoint.

OAuth provider discovery

Google is reported as enabled by both local and public provider endpoints.

OAuth transport

Google's callback reaches the intended backend with both code and state.

Proxy behavior

The callback reaches the internal service through the HTTPS-facing infrastructure.

Error observability

OAuth callback failures now produce concise structured server-side diagnostics.

Secret handling

Environment files were excluded from staging and were not intentionally committed.

Git hygiene

Temporary debugging artifacts were removed before the final commit.

Branch isolation

The work exists on a dedicated E2E validation branch.

Upstream integration

A dedicated pull request now exists for review.

CI evidence

The upstream CI evidence pipeline is executing against the exact commit submitted for integration.

19. What Is Not Finished Yet

This distinction is critical.

We have made substantial progress, but this does not yet mean that the entire MyZubster production architecture is complete.

Several layers still require additional work.

19.1 CI Must Complete

The active evidence gate must finish successfully.

In particular:

tests
vulnerability audit
SBOM generation
evidence manifest
evidence upload

need final confirmation.

A locally working OAuth callback is not sufficient reason by itself to merge.

19.2 OAuth Needs Full Application-Level Verification

Transport-level success has been demonstrated.

The next level is proving the entire application state transition.

We want to validate:

Google authorization
      │
      ▼
callback
      │
      ▼
provider profile retrieval
      │
      ▼
verified MyZubster account
      │
      ▼
social-login result ticket
      │
      ▼
frontend redirect
      │
      ▼
ticket exchange
      │
      ▼
authenticated frontend session

Each boundary should have explicit success and failure tests.

20. OAuth State and Session Hardening

The earlier:

Sessione OAuth mancante

error demonstrates why OAuth state management deserves dedicated tests.

The system should explicitly test:

valid state
missing state
expired state
replayed state
invalid state
provider mismatch
callback without code
provider-denied authorization
expired login result ticket
reused login result ticket

The long-term goal should be to make OAuth state transitions deterministic and testable rather than dependent on manual browser observation.

21. GitHub and Facebook Providers

Provider discovery currently reports:

google   = true
github   = false
facebook = false

Therefore Google should be treated as the currently validated provider.

GitHub and Facebook should not be described as completed authentication integrations until they are enabled and tested through equivalent E2E flows.

GitHub deserves particular attention because the controller already contains logic related to GitHub automation authorization and encrypted access-token storage.

That path should eventually receive separate security and authorization tests.

22. Payment E2E Completion

The broader objective is not only authentication.

The Sepolia environment exists to validate real application flows against Ethereum's Sepolia test network.

The desired payment lifecycle is approximately:

Buyer
  │
  ▼
MetaMask
  │
  ▼
Sepolia transaction
  │
  ▼
transaction hash
  │
  ▼
MyZubster backend
  │
  ▼
chain verification
  │
  ├── wrong chain      → reject
  ├── wrong receiver   → reject
  ├── wrong amount     → reject
  ├── failed tx        → reject
  └── valid payment    → accept
                            │
                            ▼
                     persist state
                            │
                            ▼
                     marketplace order

The important property is that the backend must verify blockchain truth independently.

The browser must never be considered authoritative merely because it reports a successful transaction.

23. Idempotency

Payment verification must also be idempotent.

A transaction hash should not be usable to settle multiple orders accidentally.

Conceptually:

TX_HASH = 0xabc...

must transition from:

unseen

to:

verified / associated with order X

only once according to the application's business rules.

Repeated requests must not produce repeated financial state transitions.

This needs dedicated automated coverage.

24. Chain Finality Strategy

A production-grade blockchain integration also needs a defined confirmation policy.

A transaction being visible is not necessarily equivalent to a transaction being final enough for the application's risk model.

The architecture therefore needs an explicit rule such as:

transaction found
      │
      ▼
receipt successful
      │
      ▼
correct chain
      │
      ▼
correct recipient
      │
      ▼
correct value
      │
      ▼
N confirmations
      │
      ▼
settled

The exact confirmation threshold should be documented and configurable.

25. Observability Architecture

The OAuth investigation demonstrated the value of structured logs.

The next step should be extending that principle consistently.

Instead of scattered strings such as:

something failed

important events should use structured records:

{
  "event": "oauth_callback_failed",
  "provider": "google",
  "requestId": "...",
  "reason": "state_missing"
}

For blockchain verification:

{
  "event": "payment_verification",
  "chainId": 11155111,
  "txHash": "...",
  "orderId": "...",
  "result": "verified"
}

Sensitive values must remain excluded.

26. Correlation IDs

One particularly useful improvement would be request correlation.

Today an OAuth operation crosses multiple systems:

browser
Google
reverse proxy
Express
MongoDB
frontend redirect

A generated correlation identifier would allow the same logical operation to be traced across those boundaries.

For example:

requestId=oauth_01H...

could appear in every safe diagnostic event related to that authentication attempt.

This would dramatically reduce debugging time without requiring verbose or sensitive logs.

27. Metrics and Alerting

PM2 status is useful operationally, but long-term infrastructure should expose machine-consumable metrics.

Useful signals include:

HTTP request rate
HTTP 4xx rate
HTTP 5xx rate
OAuth success rate
OAuth failure rate
MongoDB connection failures
payment verification failures
RPC latency
blockchain RPC errors
process restart count
memory usage
event-loop lag

The millions of historical UrbanLab restarts illustrate why this matters.

A restart loop should generate an alert quickly rather than being discovered manually.

28. Dependency Reproducibility

The initial UrbanLab incident also revealed a broader engineering requirement.

The repository must be sufficient to reconstruct the runtime.

That means the following must stay synchronized:

source imports
package.json
lockfile
CI dependency installation
deployment dependency installation

If the application imports a package that is absent from the dependency manifest, the build should fail before deployment.

This is precisely the type of issue CI should prevent.

29. Deployment Reproducibility

The long-term deployment goal should be:

git commit
    │
    ▼
CI validation
    │
    ▼
immutable build artifact
    │
    ▼
staging / Sepolia
    │
    ▼
E2E validation
    │
    ▼
promotion
    │
    ▼
production

rather than:

SSH into server
    │
    ▼
edit files
    │
    ▼
npm install
    │
    ▼
restart PM2

Manual VPS work is useful during investigation.

It should not remain the final deployment architecture.

30. Infrastructure as Code

Another logical next step is representing deployment configuration as code.

The desired state of:

Node version
PM2 processes
environment requirements
reverse proxy
ports
health checks
MongoDB connectivity
Cloudflare tunnel
service restart behavior

should be reproducible.

The goal is to be able to rebuild the Sepolia environment from documented configuration instead of relying on historical knowledge of the current VPS.

31. Environment Separation

MyZubster should maintain strict boundaries between:

development
test
Sepolia staging
production

Each environment should have independent:

credentials
OAuth configuration
database
RPC endpoints
wallet configuration
frontend origin
backend origin
logging policy

A Sepolia environment should never accidentally consume production credentials or production payment configuration.

32. Security Model

Authentication and blockchain payments both operate on trust boundaries.

The backend must remain authoritative.

The browser may claim:

Google authenticated me.

The server must verify the provider result.

The browser may claim:

I paid this order.

The server must independently verify the chain.

The browser may claim:

This wallet belongs to me.

Ownership should be demonstrated cryptographically when required.

This leads to a simple architectural principle:

Client claims intent.
Server verifies truth.

33. Target Architecture

The system we are working toward can be represented as:

                    ┌─────────────────────┐
                    │      Browser        │
                    │ React / Web Client  │
                    └─────────┬───────────┘
                              │
                              ▼
                    ┌─────────────────────┐
                    │ Edge / Proxy Layer  │
                    │ TLS / Cloudflare    │
                    └─────────┬───────────┘
                              │
                              ▼
                ┌─────────────────────────────┐
                │      MyZubster API          │
                │ Node.js / Express           │
                │                             │
                │ Auth                        │
                │ Marketplace                 │
                │ Payments                    │
                │ Wallet                      │
                │ Zorgax                      │
                │ Metaverse                   │
                └──────┬───────────┬──────────┘
                       │           │
              ┌────────▼───┐   ┌───▼──────────────┐
              │  MongoDB   │   │ Blockchain RPC   │
              │ persistence│   │ Sepolia / Mainnet│
              └────────────┘   └──────────────────┘

                       External Trust Providers
                              │
                 ┌────────────┼────────────┐
                 ▼            ▼            ▼
              Google        GitHub      Facebook

Around all of this should exist another layer:

CI
security audit
SBOM
tests
logs
metrics
deployment evidence
rollback capability

That operational layer is as important as the application itself.

34. Definition of Done

For this architecture, "done" should eventually have a strict technical meaning.

A feature should not be considered complete merely because a browser demonstration succeeds.

A stronger definition is:

implementation complete
        +
unit tests
        +
integration tests
        +
E2E tests
        +
security checks
        +
dependency audit
        +
no committed secrets
        +
observability
        +
documented deployment
        +
documented rollback
        +
reproducible environment

For payment-related functionality, add:

independent on-chain verification
idempotency
chain validation
recipient validation
amount validation
confirmation policy

For OAuth:

state validation
provider validation
ticket expiration
replay protection
safe logging
failure-path tests

35. Immediate Engineering Roadmap

The next development sequence should be:

PR #1394
   │
   ▼
CI Evidence Gate passes
   │
   ▼
review / merge
   │
   ▼
full Google OAuth E2E automation
   │
   ▼
OAuth state/replay/error tests
   │
   ▼
Sepolia payment lifecycle validation
   │
   ▼
idempotency + confirmation policy
   │
   ▼
structured observability
   │
   ▼
deployment reproducibility
   │
   ▼
staging promotion gate
   │
   ▼
production-readiness review

After that, additional providers and higher-level platform features can be introduced on top of a much stronger foundation.

36. Where We Want to Arrive

The ultimate objective is not simply to have Google Login working or to send an ETH transaction on Sepolia.

Those are individual capabilities.

The real target is a platform where a complete operation can be trusted from beginning to end.

For example:

User authenticates
        │
        ▼
Identity is verified
        │
        ▼
User enters marketplace
        │
        ▼
Wallet is connected
        │
        ▼
Transaction is initiated
        │
        ▼
Blockchain records transaction
        │
        ▼
Backend independently verifies transaction
        │
        ▼
Database records authoritative state
        │
        ▼
Application unlocks purchased resource/service
        │
        ▼
Evidence remains auditable

And the entire system should be deployable again from source without depending on undocumented manual VPS state.

That is the engineering milestone we are moving toward:

a reproducible, observable, security-conscious and independently verifiable MyZubster platform spanning Web2 identity, persistent application state and Web3 settlement.

Current Status

At the end of this development cycle:

UrbanLab runtime dependency failure     → FIXED
UrbanLab PM2 restart loop               → FIXED
MongoDB runtime connectivity            → VERIFIED
Sepolia backend public endpoint         → VERIFIED
Google provider configuration           → VERIFIED
Google callback transport               → VERIFIED
OAuth code/state arrival                → VERIFIED
Temporary OAuth instrumentation         → REMOVED
Persistent OAuth error diagnostics      → IMPLEMENTED
Secret/staging hygiene                  → VERIFIED
Temporary backup files                  → CLEANED
Dedicated Git commit                    → CREATED
Developer branch                        → PUSHED
Upstream PR                             → OPEN
PR mergeability                         → CONFIRMED
Continuous Evidence Gate                → RUNNING
Full production readiness               → NOT YET COMPLETE

The most important result is not any individual fix.

We now have a clearer boundary between what has actually been proven, what remains under validation, and what engineering work is required to transform the Sepolia environment into a reliable promotion gate for MyZubster production releases.

🚀 MyZubster Development Update — Sepolia E2E, Google OAuth & I-ECO-01 Infrastructure Stabilization

Daniel Ioni — Sat, 26 Sep 2026 14:15:47 +0000

🚀 MyZubster Development Update — Sepolia E2E, Google OAuth & I-ECO-01 Infrastructure Stabilization

Today we completed a major infrastructure stabilization phase across the MyZubster Sepolia E2E environment and the connected I-ECO-01 / UrbanLab Escrow infrastructure.

The work focused on three critical areas: Google OAuth authentication, PM2 runtime configuration, and the stability of the I-ECO-01 Node.js service.

The result is a significantly cleaner and more stable development environment, with the main backend services running correctly and several previously hidden configuration issues identified and resolved.

🔐 Google OAuth — End-to-End Backend Flow Completed

A major part of today's work was dedicated to validating the Google authentication flow used by MyZubster.

The OAuth implementation was inspected from the initial authentication request all the way through the Google callback and backend processing.

We verified the public authentication endpoint and confirmed that MyZubster correctly generates the Google authorization request with the expected Client ID and callback URL.

The Sepolia callback is now correctly configured as:

https://sepolia.myzubster.com/api/auth/social/google/callback

During debugging, the backend was instrumented with additional OAuth tracing so that each important stage of the authentication flow could be observed directly from the PM2 logs.

The callback successfully reached the MyZubster backend with both the authorization code and signed state parameter.

An initial failure was then isolated during the token exchange stage.

Google returned:

401 invalid_client

with an indication that the configured client secret was invalid.

This allowed us to distinguish the problem from several other possible causes such as an incorrect callback URL, broken routing, invalid OAuth state, Cloudflare routing, frontend behavior, or an unavailable authentication provider.

After correcting the OAuth configuration, the backend successfully completed the Google authentication process.

The final trace reached:

OAUTH-CALLBACK-ENTER

followed by:

OAUTH-CALLBACK-SUCCESS

This confirms that the Google OAuth backend flow is operational.

🌐 Sepolia Runtime URL Configuration

Another issue was discovered after successful Google authentication.

Although the .env configuration correctly referenced:

https://sepolia.myzubster.com

the running PM2 process was still capable of using stale runtime environment values.

This caused successful authentication attempts to redirect users toward an older Vercel deployment instead of the intended Sepolia environment.

The runtime configuration was inspected at multiple levels:

• .env configuration

• Node.js + dotenv environment

• PM2 process environment

• OAuth callback generation

• frontend redirect generation

• running process configuration

The Sepolia runtime was then explicitly aligned so that the active backend process uses:

FRONTEND_URL=https://sepolia.myzubster.com

PUBLIC_APP_URL=https://sepolia.myzubster.com

GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com

The active PM2 process was verified directly after the update.

This was important because having the correct value inside .env is not sufficient if a long-running process manager is still carrying older environment state.

🏭 I-ECO-01 / UrbanLab Investigation

During the infrastructure review we also discovered a serious stability problem affecting the I-ECO-01 / UrbanLab service.

The PM2 process had accumulated more than 6.5 million restarts.

Despite appearing as online in PM2, the process was continuously crashing and being restarted.

This is an important operational lesson: an online status alone does not necessarily mean that a service is healthy.

We inspected:

• PM2 process configuration

• executable path

• working directory

• restart counter

• process PID

• CPU usage

• Node.js error logs

• package dependencies

• server entrypoint

• health endpoint

The active process was confirmed to be executing:

/opt/I-ECO-01/server.js

🔎 Root Cause Identified

The crash loop was traced to missing Node.js dependencies.

The I-ECO-01 server.js required several modules that were not declared or installed in the project dependencies.

The missing packages were:

helmet

socket.io

winston

The server was failing immediately at:

require('helmet')

with:

MODULE_NOT_FOUND

Because PM2 was configured to automatically restart the process, every crash immediately triggered another launch attempt.

This created the extremely high restart count.

🔧 Dependency Repair

The complete set of external dependencies referenced by the server entrypoint was inspected before modifying the project.

The missing dependencies were then installed and added to package.json.

The resulting dependency set now includes the required server components:

• Express

• CORS

• dotenv

• Mongoose

• Helmet

• Socket.IO

• Winston

Each newly installed package was then independently loaded through Node.js to confirm that module resolution was working correctly.

All three previously missing modules passed the verification.

✅ UrbanLab Restart Loop Resolved

After repairing the dependencies, the UrbanLab service was restarted and monitored.

The server successfully initialized the Escrow controller and started listening on port 5002.

MongoDB also connected successfully.

Most importantly, we performed a timed stability test rather than relying only on PM2's reported status.

Before the test:

PID: 1026452

Restart count: 6548384

After waiting 15 seconds:

PID: 1026452

Restart count: 6548384

The PID remained unchanged and the restart counter did not increase.

This confirms that the restart loop was successfully stopped.

UrbanLab is now running as a stable process rather than continuously crashing and restarting.

❤️ I-ECO-01 Health Check

The service health endpoint was tested directly on the VPS:

http://127.0.0.1:5002/health

The service returned a healthy response reporting:

status: ok

service: I-ECO-01

mongodb: connected

This provides direct application-level confirmation that the service is alive and its database connection is operational.

🔐 Escrow Multisig Service

The I-ECO-01 Escrow controller is also initializing successfully.

The active configuration reports:

Multisig threshold: 2/3

Escrow timeout: 24 hours

Escrow fee: 0.5%

The service exposes its Escrow API and initializes WebSocket support alongside the HTTP server.

This gives the I-ECO-01 environment the foundation required for the next stages of escrow and transaction-flow testing.

📡 WebSocket Infrastructure

Socket.IO is now installed and successfully loaded by the server.

The service initializes WebSocket functionality together with the main HTTP server on port 5002.

This prepares the infrastructure for real-time communication between the backend and connected MyZubster / UrbanLab components.

🍃 MongoDB Connectivity

MongoDB connectivity was verified after the dependency repair.

The server reports:

MongoDB connected

and the health endpoint independently reports:

mongodb: connected

This is particularly important because application startup alone would not demonstrate that the persistence layer is actually available.

⚙️ PM2 & VPS Infrastructure

The broader VPS process environment was also inspected.

The system currently includes services for:

• MyZubster Sepolia backend

• MyZubster Sepolia frontend

• MyZubster Social

• MyZubster Web

• UrbanLab / I-ECO-01

• Cloudflared

PM2 itself is managed through systemd using the pm2-root service.

This means the process manager is integrated with the VPS boot environment rather than existing only inside an interactive shell session.

The corrected process state can therefore be persisted through PM2 after stability verification.

☁️ Cloudflare / Public Routing

The public Sepolia environment continues to operate through the existing Cloudflare infrastructure.

The public MyZubster Sepolia endpoint remains:

https://sepolia.myzubster.com

while the relevant backend services remain bound locally on the VPS.

This keeps internal services separated from the public entrypoint while allowing the Sepolia environment to expose the required application routes.

🧪 Why This Debugging Phase Was Important

Several of today's issues demonstrate why infrastructure validation must go beyond checking whether a process simply says online.

We encountered three very different classes of problems:

1. OAuth configuration mismatch

Google authentication reached the correct backend but failed during token exchange because of an invalid client credential.

2. Runtime environment mismatch

The .env file contained the correct Sepolia URLs, while the running application could still operate with stale process-level configuration.

3. Dependency-driven restart loop

PM2 displayed the UrbanLab service as online while it was actually crashing and restarting continuously because required Node.js packages were missing.

Each issue required validation at a different layer.

📊 Current Development Status

MyZubster Sepolia public environment: ✅ Operational

Google OAuth provider detection: ✅ Operational

Google OAuth callback: ✅ Operational

Google OAuth backend token flow: ✅ Completed successfully

OAuth callback state/code handling: ✅ Verified

Sepolia frontend redirect configuration: ✅ Corrected

PM2 runtime environment: ✅ Corrected

I-ECO-01 / UrbanLab startup: ✅ Operational

UrbanLab restart loop: ✅ Resolved

Node.js dependencies: ✅ Repaired

MongoDB connectivity: ✅ Verified

I-ECO-01 health endpoint: ✅ Healthy

Escrow controller initialization: ✅ Operational

2-of-3 Escrow configuration: ✅ Loaded

WebSocket infrastructure: ✅ Initialized

PM2/systemd infrastructure: ✅ Verified

🔒 Security

No API keys, OAuth secrets, database credentials, wallet private keys, JWT secrets, or other sensitive configuration values are included in this development update.

Infrastructure credentials remain environment-level configuration and must never be committed to public repositories or included in public debugging output.

Credential rotation is also part of the security process whenever secrets may have been exposed during development or debugging.

🛣️ Next Phase

With the core infrastructure stabilized, development can move away from basic process recovery and toward higher-level integration testing.

The next stages can focus on:

• complete browser-level Google authentication verification

• social-login ticket exchange and session persistence

• Sepolia frontend/backend integration

• authenticated user flows

• wallet integration testing

• Escrow API testing

• multisig workflow validation

• WebSocket event testing

• failure and recovery scenarios

• production-readiness checks

The important milestone is that we now have a much more predictable foundation.

Google OAuth can complete successfully on the backend, the Sepolia runtime configuration is aligned with the intended public environment, MongoDB is connected, and I-ECO-01 is no longer trapped in a restart loop.

Infrastructure debugging is not just about making a process start — it is about proving that every layer remains healthy after it starts.

Today, we moved MyZubster another significant step in that direction.

MyZubster #Sepolia #Web3 #Blockchain #NodeJS #MongoDB #GoogleOAuth #OAuth2 #PM2 #Cloudflare #Monero #Escrow #Multisig #SocketIO #UrbanLab #Infrastructure #BackendDevelopment #DevOps #BuildInPublic #DevelopmentUpdate

MyZubster Marketplace + MetaMask: First Real Ethereum Sepolia Integration Test

Daniel Ioni — Fri, 25 Sep 2026 05:51:03 +0000

MyZubster Marketplace + MetaMask: First Real Ethereum Sepolia Integration Test

We are moving the MyZubster Marketplace toward a flow where identity, wallet ownership, marketplace requests, and blockchain payments are clearly separated.

The target flow is:

MyZubster account → verified wallet → signed marketplace request → accepted order → ETH payment on Ethereum Sepolia → server-side blockchain verification → completed order

During this development session, we successfully validated several important parts of that architecture in a real test environment.

Just as importantly, we now have a clear picture of what still needs to be completed before we can call the full Marketplace ETH flow end-to-end verified.
A Separate E2E Environment

The first decision was to avoid experimenting directly on production.

We created a dedicated Git worktree on the VPS for the Sepolia E2E branch and kept the production checkout untouched.

The test backend runs separately on:

127.0.0.1:5010

The React test frontend runs on:

127.0.0.1:3010

Production continues using its existing service and port.

This gives us an isolated environment where wallet signing, Marketplace requests, and blockchain transactions can be tested without changing the public deployment.
Ethereum Sepolia RPC Is Working

We configured an Ethereum Sepolia RPC endpoint through Alchemy.

The connection was tested directly with JSON-RPC and successfully returned a Sepolia block number.

That confirms the backend has working blockchain access.

This is important because MyZubster's payment verifier needs to independently inspect the blockchain and validate:

transaction hash;

sender address;

recipient address;

amount;

network;

transaction status;

confirmation count.

The RPC credential stays on the server and is not exposed to the browser.
The Test Environment Is Not Publicly Exposed

Instead of opening ports 3010 and 5010 to the Internet, we kept both services bound to localhost on the VPS.

Access from the development machine is provided through an SSH local tunnel:

ssh -N \
-L 127.0.0.1:3010:127.0.0.1:3010 \
root@SERVER

The tunnel was successfully verified from Windows:

TcpTestSucceeded : True

The frontend also returned:

HTTP/1.1 200 OK

This allowed us to use the real browser and MetaMask extension while keeping the development server private.
The React Marketplace Is Running Through the Test Backend

The React development frontend uses relative API calls such as:

/api/wallet/me
/api/marketplace/...

For the E2E environment, the frontend development proxy points to the isolated backend on port 5010.

That means:

Browser
↓
127.0.0.1:3010
↓
React development proxy
↓
127.0.0.1:5010
↓
MyZubster Sepolia backend

Both frontend loading and backend health checks are working.
Real MyZubster Authentication Was Reused

The test frontend requires a valid MyZubster session before a wallet can be connected.

Because the account being tested uses Google/GitHub OAuth, we reused an already authenticated MyZubster session for the localhost environment.

No password or private wallet key was required.

Once the valid MyZubster authentication token was available in the local test origin, the wallet integration became accessible.
MetaMask Wallet Ownership Verification Works

This is one of the most important results of the test.

The Marketplace wallet panel initially showed:

ETH / EVM wallet

Not verified

After authenticating the MyZubster account, we selected:

Connect MetaMask

The browser successfully communicated with the MetaMask extension.

MyZubster then requested a wallet challenge from the backend and MetaMask signed that challenge using:

personal_sign

This is an off-chain signature.

It is not a blockchain transaction.

It does not transfer ETH.

It does not consume gas.

It only proves that the current MyZubster user controls the selected EVM wallet.

The final UI state became:

Verified · 0xBBBc51B471…03f514bCBb

Wallet MetaMask verified and linked to your MyZubster account.

This confirms that the complete wallet ownership flow is working:

MyZubster authenticated user
↓
MetaMask account
↓
server-generated challenge
↓
personal_sign
↓
server signature verification
↓
wallet linked to MyZubster account

Wallet Verification Is Separate From Payment

One architectural detail is especially important.

The wallet was verified while MetaMask reported:

chain ID 84532

That network is Base Sepolia.

The Marketplace ETH payment system, however, targets:

Ethereum Sepolia
chainId: 11155111
hex: 0xaa36a7

This is not a problem for wallet ownership verification.

The signature proves control of the EVM address independently of an ETH payment.

When an actual Marketplace payment starts, the frontend checks the network again and requests MetaMask to switch to Ethereum Sepolia if necessary.

This gives us an important separation:

CONNECTED
≠ VERIFIED
≠ AUTHENTICATED
≠ REQUEST SIGNED
≠ TX SUBMITTED
≠ PAID

Each state represents a different security boundary.
Signed Marketplace Requests Are Implemented

The Marketplace code can also require a Buyer to sign a Marketplace request.

The intended process is:

Buyer selects listing
↓
MyZubster creates order challenge
↓
Buyer signs challenge with MetaMask
↓
Backend verifies signature
↓
Marketplace request is created

Again, this signature is not a payment.

It proves that the wallet attached to the request is controlled by the authenticated Buyer.

The request can therefore carry verified wallet evidence to the Seller before any blockchain payment occurs.
Seller Wallet Evidence Is Implemented

The Marketplace order flow includes wallet evidence that can be shown to the Seller.

This is intended to allow the Seller to verify that the Buyer request is associated with a wallet already verified by MyZubster.

The payment lifecycle is therefore not simply:

click → send ETH

Instead it becomes:

identity
→ verified wallet
→ signed request
→ Seller acceptance
→ payment intent
→ blockchain transaction
→ independent verification

That separation is deliberate.
Ethereum Sepolia Payment Flow Is Implemented

For ETH orders, the backend can generate a payment intent containing the expected:

sender
recipient
amount
chain

The browser then checks that the currently selected MetaMask wallet matches the verified Buyer wallet.

It also checks that MetaMask is connected to Ethereum Sepolia.

If necessary, it calls:

wallet_switchEthereumChain

with:

0xaa36a7

Only after those checks does the browser call:

eth_sendTransaction

MetaMask still requires explicit user confirmation.

MyZubster does not hold the user's private key and cannot silently send the transaction.
Server-Side Payment Verification

Submitting a transaction hash does not automatically make an order paid.

The backend independently checks the Sepolia transaction.

The verifier is designed to validate:

transaction exists
sender matches Buyer
recipient matches Seller
amount matches payment intent
network is Ethereum Sepolia
transaction succeeded
minimum confirmations reached

The current lifecycle includes states such as:

CONFIRMING
PAID
FAILED

The target minimum for the current test is:

3 confirmations

This means a transaction may exist on-chain but still remain:

CONFIRMING

until the confirmation threshold has been reached.

Only after successful blockchain verification should the Marketplace order move to:

PAID

What We Have Actually Verified

At this point, we have successfully verified the following in a real environment:

isolated VPS E2E environment;

production kept separate from the test stack;

Ethereum Sepolia JSON-RPC connectivity;

backend connection to MongoDB;

test backend running independently;

React test frontend running independently;

frontend-to-backend API proxy;

secure browser access through an SSH tunnel;

real MyZubster authenticated session;

MetaMask detected by the browser;

MetaMask account connection;

server-generated wallet challenge;

real personal_sign signature;

server-side wallet signature verification;

EVM wallet successfully linked to a MyZubster account.

That last point is the first major milestone of the real wallet E2E flow.
What Still Needs To Be Tested

The full Marketplace payment lifecycle is not yet fully E2E validated.

The next test requires two distinct actors:

Buyer
Seller

and ideally two distinct MyZubster accounts with two distinct EVM wallets.

The remaining E2E sequence is:

Seller account
→ verify Seller MetaMask wallet
→ activate Seller
→ enable ETH acceptance
→ create ETH listing

Buyer account
→ verify Buyer MetaMask wallet
→ open Seller listing
→ sign Marketplace request

Seller
→ inspect Buyer wallet evidence
→ accept request

Buyer
→ receive ETH payment intent
→ switch MetaMask to Ethereum Sepolia
→ approve Sepolia transaction

Backend
→ detect transaction
→ verify sender
→ verify recipient
→ verify amount
→ verify successful receipt
→ wait for confirmations
→ mark order PAID

Seller
→ complete order

That is the next milestone.
Negative Tests Are Still Required

A payment system also needs to prove that invalid transactions are rejected.

The E2E suite still needs real negative-path tests for cases such as:

wrong Buyer wallet;

wrong network;

wrong recipient;

wrong payment amount;

failed transaction;

insufficient confirmations;

reused transaction hash;

transaction submitted before Seller acceptance;

Seller without a verified EVM wallet;

Seller not configured to accept ETH.

These tests are as important as the successful payment path.
No Private Keys on the Server

A core property of the current architecture is that MyZubster never needs access to the MetaMask private key.

The browser wallet signs locally.

For ownership verification:

MetaMask → personal_sign

For payment:

MetaMask → eth_sendTransaction

The server only receives public information such as:

address
signature
transaction hash

and independently verifies them.

This keeps the system non-custodial.
Current Architecture

The current design can be summarized as:

            MyZubster Account
                   │
                   ▼
           Wallet Challenge
                   │
                   ▼
                MetaMask
                   │
            personal_sign
                   │
                   ▼
            Verified Wallet
                   │
                   ▼
          Marketplace Request
                   │
            signed off-chain
                   │
                   ▼
            Seller Acceptance
                   │
                   ▼
             Payment Intent
                   │
                   ▼
         Ethereum Sepolia TX
                   │
                   ▼
        Blockchain Verification
                   │
                   ▼
         CONFIRMING → PAID
                   │
                   ▼
               COMPLETED

Why This Matters

The important result is not simply that “MetaMask connects.”

The useful result is that we now have several independent trust boundaries working together:

MyZubster authentication proves who the platform user is.

MetaMask signature proves who controls the wallet.

Marketplace request signatures prove which wallet approved a request.

The blockchain proves that a payment transaction occurred.

The MyZubster backend independently verifies whether that transaction satisfies the Marketplace payment intent.

That is much stronger than trusting a transaction hash supplied by the browser.
Next Milestone

The next development milestone is straightforward:

complete one real Buyer → Seller transaction using Sepolia test ETH and observe the order move from request creation all the way to PAID and COMPLETED.

After that, the same environment can be used to exercise the negative payment cases and strengthen the verifier before any mainnet discussion.

For now, the most important milestone is confirmed:

A real MyZubster account can authenticate, connect MetaMask, sign an off-chain wallet challenge, and have that EVM wallet independently verified and linked by the MyZubster backend.

The wallet layer is working.

The next challenge is completing the entire Marketplace payment lifecycle.

From “Connect MetaMask” to Verifiable Marketplace Intent: What We Built in MyZubster and What Comes Next

Daniel Ioni — Fri, 25 Sep 2026 04:42:30 +0000

From “Connect MetaMask” to Verifiable Marketplace Intent: What We Built in MyZubster and What Comes Next

I’ve been working on a new Ethereum / MetaMask layer for MyZubster.

What started as:

“Let’s add MetaMask.”

quickly became a much more interesting architecture problem.

Because adding a wallet button is easy.

Defining what a wallet means inside a real application is not.

Over the latest development cycle, I implemented four connected pieces:

MyZubster account
↓
verified MetaMask wallet
↓
optional Ethereum login
↓
signed Marketplace request
↓
Seller-visible cryptographic evidence

But one principle has guided the entire implementation:

CONNECTED
!= VERIFIED
!= AUTHENTICATED
!= REQUEST_SIGNED
!= ACCEPTED
!= PAID
!= SETTLED

Keeping those states separate is probably the most important part of the work.

Why I didn’t want “Web3 everything”

One possible approach would have been:

User opens MyZubster
↓
Connect wallet
↓
Every important action becomes a blockchain transaction
↓
Pay gas
↓
Wait for confirmations

I deliberately did not take that route.

MyZubster is not intended to become unusable for people who do not already live inside the crypto ecosystem.

So MetaMask remains an additional capability.

Users can still access MyZubster through traditional authentication methods.

The emerging identity model is:

Email / password
Google
GitHub
Facebook
MetaMask
↓
MyZubster account

But the wallet adds cryptographic capabilities when they are actually useful.

Milestone 1: proving wallet ownership

The first problem was simple to describe:

How does MyZubster know that the authenticated user really controls a particular Ethereum address?

Reading an address from MetaMask is not sufficient.

This:

const accounts = await window.ethereum.request({
method: 'eth_requestAccounts'
});

only proves that the browser exposed an account.

It does not give the backend a trustworthy ownership proof.

So the first implementation introduced a challenge-signature flow.

The architecture is:

Authenticated MyZubster user
↓
Connect MetaMask
↓
eth_requestAccounts
↓
read chain ID
↓
POST /api/wallet/challenge
↓
server-generated nonce + challenge
↓
personal_sign
↓
POST /api/wallet/verify
↓
ethers.verifyMessage()
↓
recovered signer == expected wallet
↓
WALLET_VERIFIED

The backend, not the frontend, decides whether a wallet is verified.

The challenge

The challenge is tied to:

MyZubster account
wallet address
chain ID
domain
application URI
random nonce
issued time
expiration
LINK_WALLET action

And the message explicitly tells the user:

This is not a payment and does not spend ETH.

That sentence is more important than it might appear.

Wallet UX should not blur the difference between:

sign message

and:

send transaction
What MyZubster does not store

The wallet integration is non-custodial.

MyZubster does not need:

private keys
seed phrases
mnemonics
MetaMask passwords
wallet secrets

The application stores only the relationship needed to represent verified wallet ownership.

Conceptually:

evmWallet: {
walletType: 'EVM',
provider: 'metamask',
address: '0x...',
chainId: 1,
status: 'WALLET_VERIFIED',
verifiedAt: Date,
lastVerifiedAt: Date
}

The user remains in control of the wallet.

Milestone 2: signing Marketplace intent

Once wallet ownership existed, the next question became:

Can the buyer cryptographically prove that they intended to request a particular Marketplace listing?

Without paying gas?

Yes.

That became the second milestone.

Instead of broadcasting an Ethereum transaction, MyZubster creates a canonical off-chain request.

The flow is now:

Verified MyZubster wallet
↓
Buyer clicks Request
↓
POST /api/marketplace/orders/challenge
↓
canonical MARKETPLACE_REQUEST generated
↓
MetaMask signs it
↓
backend verifies signer
↓
MarketplaceOrder created
↓
status = REQUESTED

No ETH is transferred.

No gas is required.

What exactly gets signed?

The server builds a structured request containing information such as:

{
"schema": "myzubster.marketplace-request.v1",
"intent": "MARKETPLACE_REQUEST",
"listingId": "...",
"quantity": 1,
"buyerAccountReference": "...",
"walletAddress": "0x...",
"chainId": 1,
"listingSnapshot": {
"title": "...",
"price": 25,
"currency": "EUR",
"exchangeMode": "payment",
"sellerId": "..."
},
"nonce": "...",
"issuedAt": "...",
"expiresAt": "..."
}

The listing snapshot is important.

The signature should represent what the buyer actually saw and requested.

It should not silently become authorization for a listing after its commercial terms have changed.

Replay protection

A signed payload should not be reusable forever.

The Marketplace challenge therefore includes:

random nonce
expiration
user binding
wallet binding
listing binding
quantity binding

Once successfully used, the challenge becomes consumed.

A second attempt is rejected.

Conceptually:

challenge
↓
signed
↓
verified
↓
order created
↓
CONSUMED

Not:

same signature
↓
order 1
↓
order 2
↓
order 3
What gets stored on the Marketplace order?

The order now has a dedicated wallet evidence layer.

Conceptually:

walletEvidence: {
status: 'VERIFIED',
walletAddress: '0x...',
networkFamily: 'EVM',
chainId: 1,
payloadHash: '...',
challengeId: '...',
requestSchema: 'myzubster.marketplace-request.v1',
signedAt: Date,
verifiedAt: Date
}

The raw signature exists as evidence but is hidden from normal Mongoose queries.

The important public-facing evidence is the verified relationship and cryptographic hash, not dumping internal authentication material everywhere.

Milestone 3: Sign-In with Ethereum

After wallet ownership verification, another possibility became available.

If a MyZubster account already has a verified EVM wallet, that wallet can also become an optional authentication method.

So I added an Ethereum login path.

The login page can now conceptually support:

Email + password
Google
GitHub
Facebook
MetaMask

MetaMask does not replace the existing authentication system.

It extends it.

Ethereum login flow

The flow is:

/social-login
↓
Continue with MetaMask
↓
eth_requestAccounts
↓
eth_chainId
↓
POST /api/auth/ethereum/challenge
↓
short-lived SIWE-style challenge
↓
personal_sign
↓
POST /api/auth/ethereum/verify
↓
server recovers Ethereum signer
↓
find existing MyZubster account with verified wallet
↓
issue normal MyZubster JWT

The result is still a normal MyZubster session.

MetaMask is the authentication proof.

It does not mean the rest of MyZubster suddenly needs blockchain calls.

An intentional limitation: no automatic wallet-only account creation yet

For the first version, a random Ethereum wallet cannot silently create a brand-new MyZubster account.

The wallet must already be linked to an existing account.

So:

unknown wallet
+
valid Ethereum signature

does not automatically become:

new MyZubster user

Instead, the user is asked to first enter through an existing identity method and link the wallet.

That is intentional.

Wallet-only onboarding introduces additional questions:

How does account recovery work?

What happens if the wallet is lost?

How do we attach an email later?

Can wallets be rotated?

Can an account have multiple wallets?

How do support and abuse recovery work?

I want those questions answered before wallet-only registration becomes possible.

Milestone 4: showing the proof to the Seller

Cryptographic evidence is not very useful if nobody can understand it.

So the next step was the Seller experience.

When a Seller receives a Marketplace request that was signed using a verified wallet, MyZubster now displays:

✓ Richiesta firmata · wallet verificato

The Seller can see information such as:

buyer wallet
EVM chain ID
request payload hash
verification time

The address and hash are abbreviated in the interface, while the complete values remain available where useful.

What the Seller does not see

I deliberately introduced an API projection instead of blindly returning the stored evidence object.

The participant-facing endpoint returns only information required to understand the proof.

It does not expose:

raw MetaMask signature
internal challenge ID
private challenge state

This is a small implementation detail, but it represents an important rule:

cryptographic evidence does not mean every internal cryptographic artifact should automatically become public.

Seller UX: signed is not paid

The evidence panel also explicitly says:

This signature proves request intent
and wallet control.

It is not a payment.
It does not transfer ETH.
It does not mean the Seller accepted the request.
It does not mean the order is settled.

This distinction is essential to the architecture.

Today the lifecycle looks like:

Wallet verified
↓
Request signed
↓
REQUESTED
↓
Seller accepts
↓
ACCEPTED
↓
payment, if required
↓
payment verification
↓
COMPLETED

Signing step 2 does not magically jump to step 6.

Why I think this architecture is more useful than “put everything on-chain”

A Marketplace contains many actions.

Examples:

browse listing
request item
ask question
accept request
reject request
cancel
review
moderate
pay
settle
record evidence

Putting every one of those on-chain would introduce enormous friction.

Instead, MyZubster can use different evidence layers for different actions.

For example:

ordinary application action
→ database

important user intent
→ signed off-chain payload

payment
→ payment rail

permanent public evidence
→ optional blockchain anchor

That is much closer to how I think blockchain integration should work.

Use cryptography where cryptography adds something.

Use blockchain where permanence adds something.

Don’t turn every button into gas.

The current PR stack

The implementation is currently divided into several pull requests.

PR #1385 — MetaMask wallet ownership linking

Introduces:

Connect MetaMask
wallet challenge
signature verification
verified EVM wallet state
disconnect flow
PR #1386 — Signed MetaMask Marketplace requests

Introduces:

MARKETPLACE_REQUEST challenge
canonical request payload
off-chain signature
replay protection
walletEvidence on MarketplaceOrder
PR #1387 — Optional Sign-In with Ethereum

Introduces:

Continue with MetaMask
Ethereum authentication challenge
signature verification
existing account lookup
normal MyZubster JWT
PR #1388 — Seller-visible wallet evidence

Introduces:

verified request badge
wallet address
chain ID
payload hash
verification timestamp
safe API projection
signed-intent vs payment explanation

So the architecture is now becoming:

ACCOUNT
↓
WALLET OWNERSHIP
↓
AUTHENTICATION
↓
SIGNED INTENT
↓
MARKETPLACE STATE
↓
PAYMENT
↓
SETTLEMENT
↓
OPTIONAL PERMANENT EVIDENCE
What is still missing?

Quite a lot.

And I think documenting the unfinished parts is as important as documenting what works.

Merge and production validation

The wallet work currently exists as a stack of development pull requests.

Before calling the system production-ready, I still need to complete:

CI validation
security checks
merge ordering
deployment
production smoke tests
real MetaMask browser tests

Passing unit tests is not the same as validating the complete browser-wallet-server journey.

Real Seller acceptance evidence

The buyer can sign a request.

The Seller currently accepts it through the normal authenticated application flow.

A future version could optionally introduce:

SELLER_ACCEPTANCE

as a separately signed intent.

For example:

buyer:
MARKETPLACE_REQUEST signed

seller:
MARKETPLACE_ACCEPTANCE signed

That could produce bilateral evidence.

But this should remain optional rather than forcing both parties through wallet signatures for every exchange.

ETH payment flow

The biggest missing layer is still actual Ethereum payment.

The architecture should eventually distinguish:

PAYMENT_REQUESTED
PAYMENT_SUBMITTED
PAYMENT_CONFIRMING
PAID
SETTLED
FAILED

A buyer signature is not payment evidence.

Actual ETH payment needs transaction-level evidence.

That means checking things like:

network
transaction hash
sender
recipient
amount
block inclusion
confirmation count
transaction status

before saying:

PAID

Network policy

MetaMask can be connected to many EVM networks.

MyZubster therefore needs an explicit network policy.

For example:

Ethereum Mainnet
Ethereum Sepolia
Base
Base Sepolia
future EVM chains

Wallet ownership itself can be chain-agnostic in some contexts.

Payments cannot.

If an order expects ETH on Ethereum mainnet, a transaction on another chain must not satisfy it.

Wallet switching

Another real-world UX problem:

A user verifies:

0xAAA

but later MetaMask is currently using:

0xBBB

The frontend already detects some wallet mismatch situations, but this needs stronger product handling.

Eventually MyZubster should clearly show:

Verified wallet:
0xAAA

Currently selected MetaMask account:
0xBBB

Switch account to continue.

Wallet recovery and rotation

This becomes important once MetaMask can authenticate users.

What happens if somebody loses a wallet?

The application needs a recovery model.

Possible future flow:

authenticate through another verified MyZubster identity
↓
request wallet replacement
↓
security confirmation
↓
old wallet revoked
↓
new wallet challenge
↓
new wallet verified

Without that, wallet authentication risks becoming a trap for users who lose access.

Multiple wallets

Today the model is essentially:

MyZubster account
↓
one verified EVM wallet

Long term, a user might reasonably need:

primary wallet
Marketplace wallet
personal wallet
project wallet
DAO wallet

That would require a proper wallet registry rather than a single wallet property.

Standard SIWE compatibility

The Ethereum authentication message is currently SIWE-style.

A future improvement is stricter compatibility with the formal Sign-In with Ethereum model and dedicated parsing/validation instead of relying only on the application’s own message construction.

That would improve interoperability and reduce ambiguity.

Mobile wallet support

window.ethereum works well for browser-extension environments such as desktop MetaMask.

That is not enough for everyone.

Mobile support may eventually require:

MetaMask mobile deeplinks
WalletConnect
other EIP-1193 compatible providers

I don’t want the feature to become “MetaMask desktop only”.

Better evidence inspection

The Seller currently gets a compact evidence summary.

A future interface could provide an expandable verification view:

Request schema
Payload hash
Wallet
Network
Signed at
Verified at
Listing snapshot
Verification result

without exposing secrets.

Potentially something like:

Verify signed request

where MyZubster independently recomputes the payload hash.

Payment evidence must remain separate

This needs to remain a permanent architectural rule:

wallet verified
!= payment verified

Even if the wallet that signed the request later sends the payment.

Those are two distinct cryptographic events.

Request evidence says:

this wallet expressed intent.

Payment evidence says:

this blockchain transaction moved value according to the expected payment conditions.

They should never be collapsed into one status.

Blockchain anchoring

Once an exchange is completed, MyZubster already has experiments around evidence anchoring.

Eventually the complete evidence chain could look like:

buyer wallet proof
↓
signed request
↓
seller acceptance
↓
payment evidence
↓
completed Marketplace order
↓
canonical completion evidence
↓
optional Base / Ethereum anchor

Again, blockchain anchoring should be optional and evidence-driven.

A Marketplace order should never be described as “on-chain” simply because the application supports blockchain somewhere else.

What I learned from this implementation

The interesting lesson is that integrating MetaMask is not really about MetaMask.

The JavaScript call itself is tiny.

window.ethereum.request(...)

The real engineering work is defining what a signature means.

For every wallet action, the application has to answer:

Who is signing?

What exactly are they signing?

Why are they signing it?

How long is that signature valid?

Can it be replayed?

What account is it bound to?

What does the signature authorize?

What does it explicitly NOT authorize?

What evidence should another participant see?

What must remain private?

That is where the real architecture lives.

Where MyZubster is heading

The broader idea is becoming clearer.

MyZubster does not need one giant identity system or one giant blockchain transaction system.

It can combine several independently verifiable layers:

MyZubster identity
GitHub identity
Ethereum wallet control
signed intent
Marketplace lifecycle
payment evidence
community reputation
Zorgax assistance
optional blockchain permanence

Each layer has its own meaning.

And Zorgax can eventually help users understand those meanings rather than pretending everything is the same kind of “verification”.

Current architecture

Today, the direction is:

Human
↓
MyZubster account
↓
optional verified identities
├── GitHub
├── Google
└── Ethereum wallet
↓
signed action
↓
application state
↓
human counterparty decision
↓
payment evidence
↓
optional blockchain evidence

That feels much more useful to me than:

Connect wallet
↓
Web3
Next development milestone

The next major technical milestone is the payment boundary:

SIGNED REQUEST
↓
SELLER ACCEPTANCE
↓
ETH PAYMENT REQUEST
↓
MetaMask transaction approval
↓
Ethereum transaction
↓
server-side verification
↓
confirmations
↓
PAID

Only there should MyZubster start talking about actual ETH movement.

Until that point:

A signature is evidence of intent, not evidence of payment.

And I want that distinction to remain visible in both the code and the product.

Project: MyZubster
Stack: Node.js, Express, MongoDB, React, ethers, MetaMask
Architecture: non-custodial wallet verification + off-chain signed intent
Status: active development / PR validation
Next major milestone: verified ETH payment lifecycle

Repository:

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

Current implementation PRs:

1385 — MetaMask wallet ownership

1386 — signed Marketplace requests

1387 — optional Sign-In with Ethereum

1388 — Seller-visible wallet evidence

DEV.to tags

Connecting MetaMask to MyZubster: Building Wallet Ownership Without Turning Every Action Into a Blockchain Transaction

Daniel Ioni — Fri, 25 Sep 2026 04:21:25 +0000

Connecting MetaMask to MyZubster: Building Wallet Ownership Without Turning Every Action Into a Blockchain Transaction

I’m currently adding MetaMask and EVM wallet ownership verification to MyZubster.

At first sight, this might sound like a simple “Connect Wallet” feature.

It isn’t.

The real problem I wanted to solve was:

How can a MyZubster user prove that they control an Ethereum wallet without giving MyZubster custody of that wallet, without exposing private keys, and without turning every Marketplace action into an on-chain transaction?

This distinction is becoming increasingly important as MyZubster grows.

The ecosystem already contains Marketplace flows, GitHub integrations, AI-assisted workflows through Zorgax, blockchain evidence experiments, Base Sepolia anchoring, internal MYZ accounting, and support for multiple crypto assets.

Adding MetaMask therefore cannot just mean placing a button in the UI.

It needs a clear security and product model.

The architecture I’m implementing is based on one central principle:

Connected wallet
!=
Verified wallet ownership
!=
Signed Marketplace intent
!=
Payment authorization
!=
Payment
!=
Settlement

Those states must remain separate.

Why add MetaMask to MyZubster?

Until now, a MyZubster account could interact with the Marketplace using the normal application identity.

That works.

But there are cases where it becomes useful to have an additional cryptographic proof tied to a user-controlled wallet.

For example, imagine a Marketplace request.

A buyer could say:

I want to request this item.

Today that intention is represented by the authenticated MyZubster account.

With a verified wallet, the same user could additionally sign a canonical request payload.

That would create cryptographic evidence that:

this wallet controlled by this user
signed this exact request
at this specific moment

without sending a transaction.

No gas.

No transfer.

No smart contract interaction.

Just an off-chain signature.

This is the direction I want MyZubster to take.

The first milestone: proving wallet ownership

The first feature is deliberately small.

Before thinking about payments, tokens or escrow, MyZubster needs to answer one question reliably:

Does the authenticated MyZubster user actually control the wallet address they want to connect?

Simply receiving an Ethereum address from the browser is not enough.

A frontend can obtain an address from MetaMask using:

const accounts = await window.ethereum.request({
method: 'eth_requestAccounts'
});

const address = accounts[0];

But at this stage MyZubster should only consider the wallet:

CONNECTED

not:

VERIFIED

The proof comes from signing a server-generated challenge.

Current architecture

The flow I’m implementing looks like this:

MyZubster authenticated user
↓
Connect MetaMask
↓
eth_requestAccounts
↓
Read wallet address
↓
Read chain ID
↓
POST /api/wallet/challenge
↓
MyZubster generates a one-time challenge
↓
MetaMask signs the challenge
↓
personal_sign
↓
POST /api/wallet/verify
↓
Server recovers signer with ethers
↓
Recovered address == requested wallet?
↓
YES
↓
WALLET_VERIFIED

The important part is that verification happens on the server.

The browser never gets to say:

{
"walletVerified": true
}

and have the backend trust it.

That would defeat the entire purpose.

The API

The first implementation introduces four authenticated endpoints:

GET /api/wallet/me
POST /api/wallet/challenge
POST /api/wallet/verify
DELETE /api/wallet/disconnect

They intentionally represent a very small wallet lifecycle.

GET /api/wallet/me returns the wallet state associated with the authenticated MyZubster account.

POST /api/wallet/challenge starts ownership verification.

POST /api/wallet/verify validates the signature.

DELETE /api/wallet/disconnect removes the relationship between the MyZubster account and the EVM wallet.

Generating the challenge

The challenge is generated server-side.

It is bound to several pieces of information:

MyZubster user
wallet address
chain ID
MyZubster domain
application URI
cryptographically random nonce
issued time
expiration time
intended action

The intended action for this flow is:

LINK_WALLET

A simplified challenge looks conceptually like this:

www.myzubster.com wants you to link your Ethereum account to MyZubster:

0x1234...abcd

Sign this message to prove wallet control.
This is not a payment and does not spend ETH.

URI: https://www.myzubster.com
Version: 1
Chain ID: 1
Nonce: d70b4f...
Issued At: 2026-09-25T04:00:00.000Z
Expiration Time: 2026-09-25T04:05:00.000Z
Request ID: LINK_WALLET:user-123

That wording is intentional.

A wallet signature must never be presented to the user as if it were a payment.

Why the nonce matters

Without a nonce, a signature can potentially be replayed.

For example, imagine MyZubster accepted the same signature indefinitely.

Someone could capture the signed message and submit it again later.

Instead, every challenge gets a cryptographically random nonce:

crypto.randomBytes(16).toString('hex');

The challenge also expires after a short period.

For the first implementation, the default validity window is around five minutes.

So the verification logic checks:

challenge exists
↓
challenge has not expired
↓
requested address matches
↓
message matches the server challenge
↓
signature is valid
↓
recovered signer matches wallet address

Only after all of those conditions succeed does MyZubster persist the wallet as verified.

Signature verification with ethers

MyZubster already uses ethers, so the backend can recover the signer directly.

Conceptually:

const recovered = verifyMessage(message, signature);

Then:

if (recovered !== expectedAddress) {
throw new Error('Wallet signer mismatch');
}

Addresses are normalized before comparison.

That avoids accidental mismatches caused by formatting or checksum casing.

What gets stored?

MyZubster does not store:

private keys
seed phrases
mnemonics
wallet passwords
MetaMask secrets

The account only needs metadata about the wallet relationship.

Conceptually:

evmWallet: {
walletType: 'EVM',
provider: 'metamask',
address: '0x...',
chainId: 1,
status: 'WALLET_VERIFIED',
verifiedAt: Date,
lastVerifiedAt: Date
}

During verification there is also temporary challenge state containing things such as:

address
chainId
nonce hash
message hash
issuedAt
expiresAt
action

The challenge metadata is not part of the public wallet profile.

Wallet state matters

I’m explicitly modelling wallet state instead of using one boolean.

The first states are:

WALLET_NOT_CONNECTED

WALLET_CHALLENGE_PENDING

WALLET_VERIFIED

WALLET_DISCONNECTED

This becomes useful later because Zorgax and the UI can explain exactly what has happened.

For example:

MetaMask is connected.

is different from:

MetaMask ownership has been cryptographically verified.

And both are different from:

You paid for this order.
Connecting MetaMask in the frontend

The existing MyZubster Wallet Hub is being extended instead of creating a completely separate wallet system.

The user sees:

Connect MetaMask

The browser first asks MetaMask for the account:

const accounts = await window.ethereum.request({
method: 'eth_requestAccounts'
});

Then MyZubster reads the chain:

const chainHex = await window.ethereum.request({
method: 'eth_chainId'
});

After receiving the challenge from the backend, MetaMask signs the exact message:

const signature = await window.ethereum.request({
method: 'personal_sign',
params: [message, address]
});

That signature is then sent back to MyZubster.

The server decides whether the wallet becomes verified.

Preventing one wallet from silently belonging to multiple accounts

There is another interesting product question.

What happens if:

MyZubster account A

verifies:

0xABC...

and then account B attempts to verify the same address?

For now, the implementation treats an already verified relationship as a conflict.

Conceptually:

MyZubster Account A
↓
0xABC
↓
VERIFIED

MyZubster Account B
↓
attempts 0xABC
↓
WALLET_ALREADY_LINKED

This does not mean the Ethereum address is a person's legal identity.

It simply prevents MyZubster from claiming contradictory account-to-wallet relationships at the same time.

What changes in MyZubster?

This feature changes more than the wallet UI.

It introduces a new cryptographic identity layer into the ecosystem.

Today MyZubster can already know things such as:

MyZubster account identity
GitHub identity
community profile
Marketplace role
Zorgax profile context

Now it can additionally know:

this authenticated account proved control
of this EVM wallet
at this time

That becomes a reusable primitive.

The next step: signed Marketplace requests

This is where the feature starts becoming much more interesting.

Once a wallet is verified, a Marketplace request can be signed off-chain.

Imagine a listing:

Listing ID: garden-tools-103
Quantity: 2
Buyer: account-42
Wallet: 0xABC...

MyZubster could generate a canonical payload:

{
"schema": "myzubster.marketplace-request.v1",
"intent": "MARKETPLACE_REQUEST",
"listingId": "garden-tools-103",
"quantity": 2,
"buyerAccountReference": "account-42",
"walletAddress": "0xABC...",
"nonce": "6f4c...",
"issuedAt": "2026-09-25T10:00:00Z",
"expiresAt": "2026-09-25T10:05:00Z"
}

The buyer signs it.

The server verifies it.

Then the Marketplace order can be created as:

REQUESTED

with accompanying cryptographic evidence.

But still:

REQUEST_SIGNED != PAYMENT

That distinction is extremely important.

Why not put every Marketplace request on-chain?

Because I don’t think blockchain should be used simply because blockchain exists.

If every Marketplace request required an Ethereum transaction, the flow would become:

request item
↓
open wallet
↓
estimate gas
↓
approve transaction
↓
wait for blockchain
↓
continue

That adds cost and friction without necessarily adding proportional value.

Instead, the initial architecture is:

Marketplace request
↓
off-chain wallet signature
↓
seller acceptance
↓
exchange lifecycle
↓
structured evidence
↓
optional blockchain anchor

Blockchain is used when permanence adds value.

Not as mandatory friction.

MyZubster already has EVM infrastructure

This MetaMask work is not happening in isolation.

The codebase already contains Ethereum-related infrastructure.

There is currently support or experimental infrastructure around:

ethers
Ethereum Sepolia
Base Sepolia
Marketplace ETH payment verification
blockchain evidence anchoring
NFT experimentation
knowledge evidence commitments

For example, MyZubster already has server-side verification code capable of checking Ethereum Sepolia transactions.

It also has Base Sepolia evidence flows where a canonical payload can be anchored and independently verified.

The wallet-linking feature connects the user-controlled EVM side of that architecture.

User wallet vs server wallet

This distinction is also critical.

MyZubster already uses dedicated server-side wallets for certain blockchain evidence experiments.

Those wallets must remain completely separate from user wallets.

The architecture should always preserve:

User MetaMask wallet
!=
MyZubster server anchoring wallet

A user signs actions with their own wallet.

A server evidence wallet performs explicitly defined infrastructure operations.

Private keys for infrastructure wallets never go to the frontend.

User private keys never go to MyZubster.

What this could enable later

Once wallet verification and signed intents are reliable, several future features become technically possible.

For example:

signed Marketplace agreements
optional blockchain settlement
escrow experiments
NFT ownership interactions
portable proof of participation
token-gated experiences
signed contribution evidence
Metaverse ownership features
cross-application identity proofs

But I’m deliberately not implementing all of these at once.

The foundation has to be trustworthy first.

What it changes for Zorgax

Zorgax can also become more useful when wallet state is explicit.

Instead of guessing, the assistant can answer questions like:

User:
Is my wallet connected?

Zorgax:
Your MetaMask wallet is linked and ownership has been verified.

Or:

User:
Did I pay for this Marketplace request?

Zorgax:
No. Your wallet signed the request, but there is no confirmed payment evidence.

That may sound like a small distinction.

In financial or blockchain-related systems, it is not.

It prevents the AI layer from confusing:

signature
transaction
payment
settlement
Human approval remains part of the design

This also follows the architecture I recently implemented for Zorgax and GitHub:

AI proposes
↓
human reviews
↓
human approves
↓
system executes
↓
external result can be verified

Wallet interactions should follow the same principle.

MyZubster should never silently ask a wallet to perform economically meaningful actions.

If a future operation transfers ETH or another asset, the user should see clearly:

network
asset
amount
destination
action
estimated cost

before MetaMask asks for confirmation.

Security lessons

Building wallet integration makes one thing very clear:

The hardest part is not opening MetaMask.

This is easy:

window.ethereum.request({
method: 'eth_requestAccounts'
});

The harder problem is designing the meaning of everything around that call.

What does “connected” mean?

What does “verified” mean?

Can a challenge be replayed?

Does the signature expire?

Is the signature bound to the authenticated account?

Can the same signature be used in another environment?

Does the interface clearly explain that signing a message is not paying?

Can the same wallet become associated with multiple MyZubster users?

What happens when someone loses control of the wallet?

Those are the questions that turn a wallet button into an actual product feature.

Tests

I’m also adding automated tests around these boundaries.

The current implementation tests cases such as:

valid wallet signs challenge
→ accepted

different wallet signs challenge
→ rejected

expired challenge
→ rejected

message explicitly states that signing is not payment
→ required

There are also wiring tests checking that the API is authenticated and that the frontend uses the expected MetaMask provider methods.

Current status

The first implementation is now in a GitHub pull request:

PR #1385 — MetaMask wallet ownership linking

It contains the wallet model, challenge service, API endpoints, frontend integration and tests.

This should be considered the wallet ownership foundation, not the final Ethereum payment implementation.

The next milestone is:

Verified MetaMask wallet
↓
canonical MARKETPLACE_REQUEST
↓
off-chain signature
↓
server verification
↓
MarketplaceOrder REQUESTED

After that, payment flows can remain a completely separate layer.

The bigger architectural change

For me, the most interesting part is not “MyZubster supports MetaMask”.

It is that MyZubster is gradually gaining multiple independent layers of verifiable intent.

GitHub can prove public development activity.

MyZubster accounts represent application identity.

MetaMask can prove control of an EVM address.

Off-chain signatures can prove intent.

Marketplace state can represent agreement.

Payment verification can prove payment.

Blockchain anchors can preserve selected evidence.

Zorgax can help humans navigate all of those states without becoming the source of truth itself.

That produces an architecture that looks more like:

Identity
↓
Cryptographic control
↓
Signed intent
↓
Application state
↓
Payment evidence
↓
Optional permanent blockchain evidence

instead of:

Connect wallet
↓
everything is blockchain

And I think that distinction will matter a lot as MyZubster evolves.

Project: MyZubster
Stack: Node.js, Express, MongoDB, React, ethers, MetaMask
Current focus: non-custodial EVM wallet ownership verification
Next milestone: signed Marketplace requests without gas

GitHub:

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

MetaMask implementation:

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

From Zero to Community: GitHub, Zorgax, Pilot Projects and the MyZubster Metaverse

Daniel Ioni — Thu, 24 Sep 2026 12:48:08 +0000

From Zero to Community: GitHub, Zorgax, Pilot Projects and the MyZubster Metaverse

We have been working on a new onboarding flow for MyZubster with one main goal:

Make it possible for someone to start from zero and progressively become part of a real open-source community.

You should not need to already know GitHub, understand the architecture of the project, or know where to start contributing.

The new flow connects Zorgax, GitHub, community projects, pilot projects, the MyZubster Metaverse and the Comic Universe into one continuous experience.

Start from zero

A new user can begin without an existing developer profile.

MyZubster can guide them through creating or connecting a GitHub account and then use Zorgax to help build their public identity step by step.

The important part is that Zorgax does not simply publish something automatically.

The user can review the proposed profile, edit it and explicitly approve what should be published.

The flow can manage:

GitHub display name and bio
GitHub profile README
MyZubster profile information
community and project discovery
access to pilot-project paths
the user's Metaverse identity
the user's node inside the MyZubster Comic Universe

This turns GitHub from a simple login provider into part of the user's portable project identity.

Zorgax as the onboarding layer

Instead of landing on a large repository and wondering what to do next, a user can talk to Zorgax.

Zorgax can help understand the user's interests and connect them to relevant areas of the ecosystem.

The idea is to move from:

I discovered MyZubster

to:

Create / connect GitHub
        ↓
Build an approved profile with Zorgax
        ↓
Discover communities
        ↓
Enter pilot projects
        ↓
Become a character / node in the Metaverse
        ↓
Appear in the Comic Universe
        ↓
Contribute back through GitHub

This creates a bridge between technical contribution and community participation.

Communities become entry points

We also worked on making communities more than static categories.

They can now become entry points into contribution flows.

A person interested in privacy, open source, circular economy, local communities, visual culture or other areas can enter through the topic they understand first.

From there, Zorgax can guide them toward projects, documentation and contribution opportunities.

For example, the current ecosystem includes paths connected to areas such as Monero/privacy, circular projects, community initiatives and open-source development.

The goal is not to force every participant to become a developer.

A contribution can start from code, documentation, testing, design, research, local experience or a pilot-project observation.

Pilot projects become interactive

One of the most important ideas behind MyZubster is connecting online collaboration with real-world pilot projects.

Instead of reading about a project and stopping there, users should be able to move directly from a community into a project flow.

Zorgax becomes the guide between:

interest → community → project → action → documented contribution

This is especially useful for experimental projects where technical developers and people with practical experience need to work together.

GitHub profile automation — with human approval

We also introduced a more complete GitHub profile automation flow.

A connected user can let Zorgax prepare a complete profile proposal including a name, bio and README.

Before anything is published, the user sees the final version and explicitly approves it.

The system also keeps rollback information so previous profile content can be restored.

This means AI assistance can help with the boring part of building a developer identity without removing human control over what becomes public.

From GitHub profile to Metaverse character

The profile does not stop at GitHub.

Once the identity is approved, it can become part of the MyZubster Metaverse / Neon Plaza experience.

The same identity can then be represented as a character or node inside the virtual environment.

This gives the onboarding process a visual continuation.

Instead of creating an account and immediately seeing another dashboard, a user can move into a world that represents communities, projects and people.

The Comic Universe

The same identity can also be connected to the MyZubster Comic Universe.

The comic is not only storytelling.

We are experimenting with it as another interface for understanding the ecosystem.

Projects, people, communities and concepts can become visual nodes inside a shared narrative.

A user can therefore move from:

GitHub identity
→ MyZubster profile
→ community
→ pilot project
→ Metaverse character
→ Comic Universe node

while keeping GitHub as the public technical source of identity and contribution history.

Why we are building it this way

Open-source projects often assume that new contributors already understand GitHub, issues, pull requests, repositories and project structure.

That creates a large entry barrier.

We want to test a different approach.

Someone should be able to arrive because they are interested in a community, a real-world project, a technology or even the visual world of MyZubster.

Zorgax can then progressively explain the technical layers as they become necessary.

The objective is to create a loop where participation produces identity, identity produces connections and those connections lead to new contributions.

PERSON
  ↓
IDENTITY
  ↓
COMMUNITY
  ↓
PROJECT
  ↓
EXPERIENCE
  ↓
EVIDENCE
  ↓
CONTRIBUTION
  ↓
OPEN SOURCE
  ↺

What comes next

There is still a lot to improve.

We want to keep connecting communities with real pilot projects, improve the onboarding experience and make the transition between GitHub, Zorgax, the Metaverse and the Comic Universe increasingly seamless.

The broader experiment is simple:

Can an open-source ecosystem make joining a project feel less like learning a toolchain and more like entering a living community?

That is what we are trying to build with MyZubster.

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

MyZubster: https://www.myzubster.com/

Zorgax Profile Onboarding: https://www.myzubster.com/zorgax-profile-onboarding

Metaverse: https://www.myzubster.com/metaverse

Comic Universe: https://www.myzubster.com/fumetto

opensource #github #ai #community

Rebuilding the MyZubster Knowledge Explorer as a Static, Evidence-Aware Knowledge Interface

Daniel Ioni — Wed, 23 Sep 2026 05:21:10 +0000

Rebuilding the MyZubster Knowledge Explorer as a Static, Evidence-Aware Knowledge Interface

The MyZubster Knowledge Explorer already exposed a catalogue of canonical records across domains such as Fermentation, Monero, Programming, Art, Sport, Martial Arts and Animals.

The problem was not data availability. The problem was interaction architecture.

The previous page mixed domain discovery, record search, evidence interpretation and record inspection in one long visual flow. It was possible to browse the catalogue, but difficult to answer basic operational questions:

Which records belong to a domain?
Is this item a personal practice, an observation, a protocol or an external source?
Can I search by stable record ID?
How do I distinguish a documented claim from independently verified guidance?

We rebuilt public/knowledge.html as a static, client-side knowledge explorer with explicit evidence boundaries.

The updated page is deployed at:

https://myzubster-knowledge-myzubster.vercel.app/knowledge.html

Deployment surface

The implementation intentionally uses the smallest possible deployment surface:

myzubster-knowledge/
└── public/
    └── knowledge.html

There is no new backend service, database migration, serverless function or framework runtime.

The page is a self-contained HTML document containing:

semantic HTML;
CSS design tokens and responsive layout rules;
a client-side record registry;
domain navigation;
full-text filtering;
evidence-state filtering;
an inline record-detail renderer.

The Vercel deployment path remains static:

cd /root/myzubster-knowledge

cp public/knowledge.html \
  "public/knowledge.html.bak.$(date +%F-%H%M%S)"

install -m 0644 /tmp/knowledge.html public/knowledge.html

vercel --prod --yes --scope myzubster

A timestamped backup is created before replacement. The deployment can therefore be rolled back without relying on an untracked local copy.

The record model

The initial implementation uses an in-memory JavaScript registry:

{
  id: "MZ-001",
  title: "Knowledge Layer — canonical record protocol",
  domain: "MyZubster",
  state: "PROTOCOL",
  description:
    "Defines the Knowledge Explorer as a catalogue of traceable records with a stable ID, domain, evidence state, provenance and review boundary."
}

The model is intentionally minimal, but it establishes the fields required for a future canonical-record format:

Field	Purpose
`id`	Stable, human-readable identifier
`title`	Record title
`domain`	Knowledge domain
`state`	Evidence classification
`description`	Human-readable context and limitations

The next iteration should externalize these records into versioned Markdown files with validated front matter:

id: AHP-002
title: Absorbent-product experience contribution model
domain: CIRCULAR_ECONOMIES
evidence_state: PROTOCOL
review_status: PROPOSED
provenance: UNKNOWN
source_version: 1

That would make the website a generated view over source-controlled knowledge objects rather than a manually maintained client-side array.

Evidence states are a first-class UI concern

The explorer does not present every entry as equally reliable.

Current values include:

PERSONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
PROTOCOL

These are not cosmetic labels. They encode the epistemic boundary of a record:

PERSONAL_PRACTICE: first-hand practice reported by a contributor;
OBSERVATION: a documented observation that may still require reproduction;
EXTERNAL_SOURCE: a claim linked to an identifiable external source;
PROTOCOL: a proposed method, data model or verification procedure.

The core product rule is:

A stored record is not automatically verified guidance.

This is especially important for health-adjacent, environmental and circular-economy content. Data integrity, document provenance and scientific validity are separate properties.

Search implementation

The page supports a composable filter pipeline based on:

selected domain;
selected evidence state;
free-text query.

The current filtering implementation is deliberately framework-free:

const list = records.filter((record) =>
  (active === "All" || record.domain === active) &&
  (!state || record.state === state) &&
  `${record.id} ${record.title} ${record.domain} ${record.description}`
    .toLowerCase()
    .includes(query)
);

This approach is sufficient for a small static catalogue and has predictable runtime behaviour:

no server round trip;
no dependency on a search provider;
no indexing infrastructure;
deterministic results;
zero persistence requirements.

For larger catalogues, the next step should be build-time index generation and client-side indexed search rather than a backend search API by default.

Domain navigation

The domain list is derived from a fixed domain registry and rendered dynamically:

const allDomains = [
  "All",
  "MyZubster",
  "Circular economies",
  "Fermentation",
  "Monero",
  "Sound system",
  "Music",
  "Art",
  "Sport",
  "Martial arts",
  "Programming",
  "University",
  "Animals",
  "Permaculture",
  "Collaboration"
];

Each domain displays its active record count. Empty domains remain visible rather than being removed.

That is intentional. An empty domain is not necessarily a missing feature. It can represent a mapped knowledge area that is ready to receive documented contributions.

New MyZubster protocol records

We added a dedicated MyZubster domain with five protocol records:

MZ-001 — Knowledge Layer — canonical record protocol
MZ-002 — Evidence states — from collection to independent review
MZ-003 — Zorgax — AI assistance with human verification
MZ-004 — Development requests — turning patterns into testable work
MZ-005 — Circular economies — verified contribution model

These records document the intended system architecture:

AI may structure, retrieve and connect knowledge;
AI is not the authority that determines truth;
a content hash can establish integrity, not scientific validity;
a repeated pattern can become a scoped DevelopmentRequest;
a digital event trail does not prove a physical-world outcome without measurement and independent review.

This is the foundation for a knowledge layer that can grow without silently converting proposals into facts.

Circular economies and absorbent hygiene products

We also introduced a Circular economies domain with the AHP-### identifier family:

AHP-001 — Circular Hygiene — evidence pilot framework
AHP-002 — Absorbent-product experience contribution model
AHP-003 — Absorbent materials — test and traceability template
AHP-004 — Circular economies — reproducible pilot catalogue

All four entries are classified as PROTOCOL.

That status is critical. The records define how evidence may be collected and structured; they do not claim that material recovery, safety, environmental impact, product performance or clinical outcomes have already been verified.

For example, AHP-002 establishes a possible contribution model for lived product experience:

lived experience
  → documented observation
  → aggregate pattern
  → DevelopmentRequest
  → prototype or research task
  → independent review

A user report can be valuable input to design. It is not a substitute for clinical evidence, product testing or external validation.

Record inspection

Selecting a card renders a detail panel from the selected record:

function open(id) {
  selected = records.find((record) => record.id === id);

  detail.className = "detail visible";
  detail.innerHTML = `
    <div class="detail-grid">
      <div>
        <div class="meta">
          <span>${selected.id}</span>
          <span>${selected.domain}</span>
        </div>
        <h2>${selected.title}</h2>
        <p>${selected.description}</p>
      </div>
      <ul class="facts">
        <li><b>Evidence state</b>${label(selected.state)}</li>
        <li><b>Domain</b>${selected.domain}</li>
        <li><b>Record ID</b>${selected.id}</li>
      </ul>
    </div>
  `;
}

The current panel intentionally exposes only the available metadata. It does not fabricate source URLs, review results, hashes or relation graphs that are not yet defined by the canonical source.

Verification performed before deployment

The static page JavaScript was parsed before publication:

node -e '
const fs = require("fs");
const source = fs.readFileSync("dist/index.html", "utf8");
const script = source.match(/<script>([\s\S]*?)<\/script>/)[1];
new Function(script);
console.log("JavaScript valid");
'

The VPS-side artifact was then verified before replacing the production file:

grep -n "MZ-001\|AHP-001\|Circular economies" /tmp/knowledge.html

The expected identifiers were present before deployment.

What is not implemented yet

This release is a static product slice, not a complete evidence protocol.

It does not yet include:

Markdown or JSON source ingestion;
schema validation in CI;
record-level source URLs;
canonical content hashes;
contributor identity verification;
consent-aware submission forms;
reviewer permissions;
relation graph traversal;
external validation workflows;
physical-world audit evidence;
automatic status promotion from PROTOCOL to verified guidance.

Those omissions are deliberate. The interface must not imply capabilities that do not exist.

Next implementation steps

The technical roadmap is:

Store records as Markdown files with YAML front matter.
Add a schema validator for IDs, domains, evidence states and provenance fields.
Generate the record registry and domain counts at build time.
Add stable routes such as /knowledge/AHP-001.
Add source, evidence and relation links.
Implement contribution intake with explicit consent and UNKNOWN defaults.
Add independent review records before exposing any VERIFIED_GUIDANCE state.
Keep the distinction between data integrity and physical/scientific validation explicit in both code and UI.

Conclusion

The Knowledge Explorer is no longer only a list of documents.

It is now a lightweight, static interface for an evidence-aware knowledge model:

share
→ document
→ classify
→ inspect
→ test
→ review
→ improve

The important architectural decision is not the UI framework. It is the refusal to treat a digital record, an AI summary or a contributor claim as verified truth by default.

That boundary is what allows MyZubster to evolve from a catalogue into a traceable knowledge infrastructure.

From GitHub to the Metaverse: Building Verified Profiles and Knowledge with MyZubster and Zorgax

Daniel Ioni — Wed, 23 Sep 2026 03:00:45 +0000

From GitHub to the Metaverse: Building Verified Profiles and Knowledge with MyZubster and Zorgax

Over the last few days, we have been working on a part of MyZubster that is becoming increasingly important to the whole project:

turning a simple user account into a verified digital identity connected to real skills, experiences, projects, evidence, contributors and knowledge.

The goal is not to build another social network where people write a short bio and stop there.

The idea behind MyZubster is broader.

A profile should be able to explain:

who you are;
what you can actually do;
what you are learning;
what projects you have worked on;
what evidence exists;
who you have collaborated with;
which parts of your experience are verified;
and which information you explicitly want to make public.

At the same time, MyZubster should avoid inventing skills or turning weak signals into professional qualifications.

That is where Zorgax enters the picture.

GitHub as a verified identity layer

One of the systems we are developing is the connection between MyZubster and GitHub.

When a user authenticates through GitHub, MyZubster can associate the account with a verified GitHub identity.

That is very different from simply allowing someone to write:

"My GitHub username is this."

Instead, MyZubster can know that the GitHub identity is actually connected to the authenticated account.

From there, Zorgax can use publicly available information such as:

GitHub profile information;
repositories;
profile README;
repository descriptions;
programming languages;
public project activity.

But an important principle is:

data is not automatically a skill.

Having a JavaScript repository does not automatically mean someone is an advanced JavaScript developer.

Having cybersecurity repositories does not automatically make someone a professional security engineer.

The system should distinguish between:

evidence;
declared experience;
verified activity;
inferred context;
and actual professional claims.

This distinction is very important for us.

Yassen: from GitHub authentication to the MyZubster Metaverse

We have already seen this workflow become real with Yassen.

Yassen configured his GitHub profile and connected it to MyZubster.

Through that process, he entered the MyZubster Metaverse with a complete authenticated identity.

This is important because the Metaverse character is not just an anonymous avatar disconnected from everything else.

The identity can be linked back to the authenticated MyZubster account and its verified GitHub profile.

So the flow becomes something like:


text
GitHub identity
        ↓
MyZubster authentication
        ↓
verified account
        ↓
Metaverse character
        ↓
projects, contributors and evidence
Yassen also added danieldirimini-myzubster as a contributor.
That creates another important connection.
Instead of thinking about profiles as isolated pages, we can start thinking about a network of people who have actually collaborated.
A contribution can become part of a larger graph:
Person
  ↓
Project
  ↓
Contribution
  ↓
Evidence
  ↓
Other contributors
This is one of the directions we want MyZubster to develop further.
Profiles should describe real people, not AI-generated identities
While building the profile onboarding system, we also found an interesting problem.
Zorgax is an AI assistant inside MyZubster.
During early profile onboarding tests, a question such as:
"What practical activities can you do?"

could sometimes be interpreted by the assistant as a question directed at Zorgax itself.
That produced answers about what the AI could do instead of interviewing the user.
We corrected this behavior.
The onboarding system now explicitly tells Zorgax:
- it is interviewing the user;
- the questions are about the user's professional profile;
- it must not answer questionnaire questions as itself;
- it must not attribute Zorgax capabilities to the user;
- it should ask one question at a time;
- it should wait for the user's answer.
This sounds like a small change, but it represents a fundamental rule.
AI must help structure a person's identity, not create one for them.
Building my own professional profile inside MyZubster
We are now using the same system to structure my own profile.
Instead of creating a generic biography, we went through my experiences one by one.
We separated:
- skills I can use operationally;
- long-term practical experience;
- self-taught knowledge;
- things I am currently learning;
- available evidence;
- interests;
- professional goals;
- collaboration availability.
We also deliberately avoided presenting self-taught experience as formal certification.
For example, my profile includes areas such as:
MyZubster
I directly manage the development and evolution of MyZubster.
My work includes:
- project coordination;
- testing;
- identifying problems;
- following deployments;
- documentation;
- coordinating contributors;
- using GitHub, Linear and Vercel;
- using AI tools such as ChatGPT and Zorgax;
- working with the VPS and terminal when necessary.
At the same time, I do not describe myself as an advanced software developer if that level of expertise has not yet been reached.
That distinction matters.
Cybersecurity and Kali Linux
I have spent more than ten years studying and experimenting with Kali Linux and cybersecurity in a self-taught way.
The public professional profile only represents legitimate skills such as:
- Linux;
- terminal usage;
- networking;
- scanning;
- configuration;
- security testing in authorized environments or laboratories.
The profile system is designed to exclude unrelated or sensitive information that should not become part of a public professional identity.
Calisthenics
I practiced calisthenics for approximately four years.
My practical experience includes movements such as:
- human flag;
- L-sit;
- V-sit;
- muscle-up;
- freestyle;
- back lever;
- front lever.
There are video records available as evidence.
Again, the system does not convert this into invented certifications or coaching qualifications.
It simply records the experience that actually exists.
Thai boxing and MMA
My profile also includes:
- around four years of Thai boxing;
- around two years of MMA;
- training and sparring with other athletes.
This is recorded as practical experience, not as professional coaching or competitive certification.
Event organization and free parties
Another significant part of my experience comes from events.
I have participated in free party culture for almost twenty years and personally organized more than ten events.
This involved practical responsibilities such as:
- finding locations;
- coordinating people;
- DJs and music;
- sound systems;
- bar organization;
- shifts;
- communication;
- security;
- transport;
- technical setup;
- visual setup.
I have also worked directly with:
- lasers;
- LaserCube;
- projectors;
- screens;
- visual effects.
I am also learning video mapping.
For audio systems, I have practical basic knowledge of:
- connections;
- mixers;
- speakers;
- levels;
- simple troubleshooting.
The profile explicitly avoids describing this as professional audio engineering expertise.
Barista experience
I also have around four years of experience working as a barista.
That includes:
- coffee preparation;
- café work;
- preparation of alcoholic drinks.
Kefir as practical knowledge
Another important area for me is kefir.
I have approximately seven years of practical experience with:
- preparation;
- maintaining kefir grains;
- fermentation;
- managing fermentation time;
- sharing grains;
- teaching other people how to prepare and maintain kefir.
This is particularly interesting for MyZubster because kefir is not only a profile skill.
It can also become part of the knowledge system.
A practical skill can generate:
experience
   ↓
evidence
   ↓
structured knowledge
   ↓
verification
   ↓
knowledge available to others
That is one of the core ideas behind MyZubster Knowledge.
Permaculture, gardening and botany
I have also studied permaculture independently through books and practical experimentation.
My experience includes:
- gardening;
- plants;
- botany;
- practical cultivation.
These activities were also part of my volunteer experience.
Volunteer experience
I spent around two years volunteering with the Comunità Papa Giovanni XXIII.
My practical responsibilities included:
- helping manage the facility;
- organizing work;
- supporting young people;
- coordinating daily activities;
- participating in and coordinating group meetings.
The professional profile deliberately describes this as practical organizational and support experience.
It does not assign medical, psychological or therapeutic professional qualifications that I do not hold.
That is another important principle of the system:
experience should be represented accurately without inflating it into credentials.
Psychology as self-directed study
I have also spent approximately seven years studying psychology independently through books.
This includes interests such as:
- Freud;
- dreams;
- psychological dynamics;
- fragility and personal development.
Again, MyZubster represents this as:
self-directed study
and not as a psychologist or therapist qualification.
The structured professional profile
To support all of this, we added a structured professional profile model to MyZubster.
The profile can contain:
headline
summary
skills
experience level
evidence
practical experiences
interests
professional goals
collaboration availability
approval status
visibility
version
timestamps
One example of a skill can look conceptually like this:
{
  "name": "Kali Linux / Cybersecurity",
  "experience": "10+ years of self-directed study and practice",
  "level": "Self-taught practical experience",
  "evidence": [
    "Personal practice"
  ],
  "notes": "Only legitimate and authorized security activities are represented"
}
Explicit approval before saving or publishing
One of the most important rules we implemented is that Zorgax cannot simply decide to publish a professional profile.
The API requires explicit approval.
A profile update must include something equivalent to:
{
  "approved": true,
  "visibility": "private"
}
or:
{
  "approved": true,
  "visibility": "public"
}
Without explicit approval, the server refuses to register the professional profile.
This means the user remains in control.
The onboarding interface now presents two distinct actions:
Approve and save privately
or:
Approve and publish on MyZubster
The AI can help organize information.
The human decides whether it becomes part of the profile.
Private and public identity are not the same thing
This distinction is very important.
Not everything a person knows, has experienced or has discussed with an AI belongs on a public profile.
For that reason, MyZubster is being designed around different states.
Conceptually:
Private information
       ↓
Profile candidate
       ↓
User review
       ↓
Explicit approval
       ↓
Private profile
       OR
Public profile
This model will also be important for the Knowledge system.
From profiles to knowledge
The next layer is MyZubster Knowledge.
A user's experience should not automatically become universal knowledge.
For example:
"I have made kefir for seven years"

is a personal experience.
It can become evidence for a contribution.
But it is not automatically the same as:
"This is the scientifically correct way to make kefir."

Those are different claims.
So we use another principle:
message != knowledge
candidate != verified
verified != public
A contribution can start as a candidate.
Then it can be connected to:
- evidence;
- sources;
- people;
- projects;
- GitHub activity;
- practical demonstrations;
- reviewers.
Only after verification should it become part of the public Knowledge layer.
Zorgax as the connection layer
Zorgax is becoming the system that connects these pieces.
It is important to clarify that Zorgax is not simply "a language model trained from scratch."
Zorgax is the AI and orchestration layer inside MyZubster.
It can combine:
- language models;
- verified knowledge;
- evidence;
- workflows;
- user profiles;
- GitHub;
- MyZubster projects;
- contributors;
- human approvals.
So the architecture starts looking more like:
                MyZubster
                    |
        +-----------+-----------+
        |                       |
      Users                  Knowledge
        |                       |
    Profiles                 Evidence
        |                       |
      GitHub                  Sources
        |                       |
 Contributions ------------ Verification
        |                       |
        +--------- Zorgax ------+
                    |
                Metaverse
The Metaverse becomes more than avatars
This is where the Yassen example becomes especially interesting.
If a Metaverse user can be connected to:
- an authenticated MyZubster account;
- a verified GitHub profile;
- real repositories;
- contributions;
- other contributors;
- professional knowledge;
- evidence;
then the Metaverse stops being just a virtual world populated by anonymous avatars.
A character can become a representation of a real digital identity.
Imagine entering the MyZubster Metaverse and meeting someone.
Instead of only seeing:
Yassen
the system could eventually allow you to understand:
Yassen
├── Verified MyZubster account
├── Verified GitHub identity
├── Projects
├── Contributions
├── Collaborators
├── Skills
├── Knowledge contributions
└── Evidence
Of course, only information the user has chosen to make public should appear.
Contributors as part of the identity graph
When Yassen added danieldirimini-myzubster as a contributor, it demonstrated another direction for the ecosystem.
A project is not only code.
It is a network of people.
That network can eventually connect:
Developer
   ↓
Repository
   ↓
Contribution
   ↓
Contributor
   ↓
Evidence
   ↓
Reputation
   ↓
Knowledge
This can become much more meaningful than follower counts.
Instead of asking:
"How popular is this person?"

we can ask:
"What have they actually contributed?"

Why we are doing this
I want MyZubster to become my main professional project.
But at the same time, I am using the project itself as a way to continuously develop my skills.
That means MyZubster is also becoming a record of the learning process.
Instead of pretending to already know everything, the profile can distinguish between:
I know this
I have practical experience with this
I am currently learning this
I have evidence for this
I want to improve this
For me, this is much more honest and useful than a traditional CV.
The bigger idea
What we are building can eventually connect four important concepts:
Identity
Who is this person?
Evidence
What proof exists?
Contribution
What has this person actually done?
Knowledge
What can the community verify and reuse?
And Zorgax can help connect them without replacing human judgment.
The long-term model looks something like this:
IDENTITY
   ↓
EXPERIENCE
   ↓
EVIDENCE
   ↓
CONTRIBUTION
   ↓
VERIFICATION
   ↓
KNOWLEDGE
   ↓
COLLABORATION
That is the direction we are exploring with MyZubster.
Not just a marketplace.
Not just a Metaverse.
Not just an AI assistant.
Not just GitHub integration.
But an ecosystem where people, projects, real-world experience, evidence and knowledge can become connected.
And, most importantly, where the person remains in control of what becomes public.
What we have working now
At the current stage we have already implemented important pieces of this architecture:
- GitHub-based verified identities;
- authenticated MyZubster accounts;
- GitHub-linked Metaverse characters;
- structured professional profiles;
- skills and experience with evidence;
- explicit user approval before profile persistence;
- private and public profile visibility;
- Zorgax-guided profile onboarding;
- protection against AI inventing user capabilities;
- a public Knowledge Explorer;
- a verification-oriented Knowledge layer;
- contributor relationships;
- Vercel deployment infrastructure.
The professional profile implementation has also been tested with automated regression tests before deployment.
What we are doing next
The next step is not simply to add more fields.
The real challenge is connecting the graph.
We want to increasingly connect:
MyZubster profile
       ↓
GitHub
       ↓
projects
       ↓
contributors
       ↓
evidence
       ↓
Knowledge
       ↓
Zorgax
       ↓
Metaverse identity
My own profile is currently being used as one of the real examples for building this system.
The goal is to make the profile itself useful to the ecosystem:
not just a biography,
but a structured representation of what I can do, what I have done, what I am learning, what evidence exists and how I can collaborate with others.
That is the direction we are taking MyZubster.

Building MyZubster in Public: Marketplace Validation, Metaverse Progress, and the Bugs We Found

Daniel Ioni — Tue, 22 Sep 2026 15:49:03 +0000

Ti conviene pubblicarlo dopo una piccola revisione: il contenuto è buono, ma nel testo che hai incollato ci sono alcuni problemi di Markdown e il link finale al repository punta ancora al vecchio MyZubster-Ecosystem. Qui sotto ti lascio una versione pulita e pronta da incollare su DEV.to, mantenendo il tono tecnico e “build in public”.
Building MyZubster in Public: Marketplace Validation, Metaverse Progress, and the Bugs We Found
MyZubster is an open-source ecosystem connecting community projects, a Marketplace, internal MYZ utility credits, environmental pilots, contributor workflows, Zorgax, and an experimental browser-based Metaverse.
Right now, we are following a simple principle:
Before adding more blockchain complexity, we must prove that the basic product works for real people.

That means testing the Marketplace, validating Seller onboarding, improving account security, collecting privacy-respecting product evidence, and documenting failures as carefully as successful tests.
A free-first Marketplace
The current Seller model is designed to be free-first.
Users can explore the Marketplace without paying. Creating a basic Seller profile does not require a card or bank account, and payment onboarding begins only when a Seller wants to receive real payments.
The intended model is:
Marketplace visitor
↓
Free account
↓
Free Seller activation
↓
Limited commercial listings
↓
Optional payment onboarding
↓
Paid transactions
A wallet or cryptocurrency is not required for basic participation.
During our latest production test, the interface correctly displayed:

“Become a Seller for free”
no initial Stripe Checkout
no mandatory wallet or Monero setup
the platform commission disclosure for eligible paid transactions
access to the listing form after Seller activation But the test also exposed an important defect. The sixth-listing limit failed The Free Seller policy is supposed to allow a maximum of five active commercial listings. Five existing test listings were already visible. We then prepared a controlled sixth listing: TEST — Seller Free limit verification

Technical test listing.
Do not purchase.
The expected result was:
FREE_SELLER_ACTIVE_LISTING_LIMIT
The actual result was:
Listing published
The sixth commercial listing became publicly visible.
That matters because a frontend policy is not enough.
If a business rule exists, it must be enforced by the server before persistence.
The fix needs to address several layers:
Client validation
↓
Authentication
↓
Authorization
↓
Server-side policy
↓
Database persistence
↓
Regression tests
The server must enforce the listing limit before writing the new listing.
It must also handle concurrent publication attempts safely, distinguish commercial listings from documented free, barter, or community categories, and prevent unauthorized Seller activation or publication.
This is exactly why we test against production-like workflows.
A rule that exists only in the UI is not a reliable rule.
Neon Plaza Metaverse validation
We also tested the MyZubster Metaverse flow.
The account-linked experience successfully completed several important steps:
Canonical linked character loaded
↓
User entered Neon Plaza
↓
World reached online state
↓
Keyboard movement worked
↓
First portal reached
↓
First Zorgax mission completed
↓
Visited-zone counter updated
↓
Progress associated with account
At the time of the test, the world displayed a small number of created characters and one active online session.
Those figures are only point-in-time technical observations.
They should not be interpreted as adoption metrics.
The important part of the test was that the browser experience did not require:

a wallet
a payment
a VR headset
a local installation A normal browser was enough. Why we are not rushing into WebXR The Metaverse roadmap currently follows this order: Foundation ↓ Authentication ↓ Account security ↓ Privacy and abuse controls ↓ Realtime observability ↓ End-to-end acceptance ↓ WebXR runtime ↓ Public events ↓ Virtual twins It would be easy to jump directly to more visually impressive features. But adding advanced WebXR, creator-economy systems, or complex token mechanics before identity, moderation, reliability, and acceptance testing are stable would only increase technical debt. So we are deliberately doing the less glamorous work first. Privacy-respecting analytics One of the next Metaverse improvements is a small allowlisted analytics funnel. We want to understand a few basic events: Onboarding view Return visit Mission start First mission completion But analytics should not become uncontrolled tracking. The payload should only contain bounded properties such as: surface guest/account mode fixed mission identifier known landmark identifier It should not contain: character names display names GitHub usernames session identifiers chat messages MYZ account identifiers wallet information authentication tokens This is an important architectural principle for us: Collect the minimum evidence required to understand whether the product works.

Not every piece of available data needs to become analytics.
GitHub integration and development evidence
GitHub is becoming increasingly important in MyZubster, but we treat it as an evidence source rather than an automatic source of truth.
A commit proves that a commit exists.
It does not automatically prove that:
the feature works
the requirements were satisfied
the implementation is secure
the architecture is correct
the work was independently verified
This distinction is becoming central to the architecture we are building around Zorgax and DevelopmentRequest.
The longer-term goal is to connect:
Developer
↓
DevelopmentRequest
↓
Issue
↓
Commit
↓
Pull Request
↓
Tests
↓
Review
↓
Verified Contribution
That gives us a much stronger basis for contributor history than simply counting commits.
MYZ accounting
MYZ is currently treated as an internal utility and accounting credit.
It is not designed as an investment promise.
Before production MYZ accounting can be enabled, the canonical ledger needs durable storage and stronger accounting guarantees.
The target architecture requires:
Atomic debit/credit entries
↓
Fixed-point arithmetic
↓
Unique transfer IDs
↓
Idempotency constraints
↓
Concurrency protection
↓
Durable history
↓
Backup and restore evidence
A local JSON file may be useful during early experimentation.
It is not sufficient as a production financial ledger.
The migration toward durable database-backed accounting therefore has to happen before automated production settlement.
External settlement is a separate gate
External XMR settlement remains a later stage.
The intended flow is:
Approved contribution
↓
MYZ ledger credit
↓
Treasury reconciliation
↓
Monero RPC staging
↓
Controlled low-value payout
↓
Independent TX verification
↓
Production automation
One rule is non-negotiable:
A payment must never be marked as completed without independently verifiable transaction evidence.

A successful API response is not enough.
A local database flag is not enough.
Settlement needs independent evidence.
Zorgax and verified knowledge
Another major area of development is Zorgax.
One of the principles guiding this work is:
A conversation is not knowledge.

An AI response may be useful.
It may also be incomplete, outdated, or wrong.
So the architecture distinguishes between different states:
Message
↓
Candidate information
↓
Sources
↓
Evidence
↓
Review
↓
Verified Knowledge
Our Knowledge Layer is being designed around concepts such as:
content
contentHash
version
provenance
sources
evidence
visibility
lineage
verification status
The objective is to allow Zorgax to assist users without treating everything generated by an AI model as verified truth.
DevelopmentRequest
We have also started connecting verified knowledge to software development.
The core abstraction is called DevelopmentRequest.
Its lifecycle looks like this:
DRAFT
↓
OPEN
↓
IN_PROGRESS
↓
SUBMITTED
↓
VERIFIED / REJECTED
A DevelopmentRequest can include:
title
description
verified Knowledge references
requirements
acceptance tests
required evidence
assignee
submission
review
It deliberately does not require a bounty.
Development work and economic incentives are different concerns.
That means this flow can exist independently:
Verified Knowledge
↓
DevelopmentRequest
↓
Developer
↓
Implementation
↓
Evidence
↓
Independent Review
A bounty, reward, or settlement mechanism can later be attached when appropriate.
Submission is not verification
This is an important distinction.
A developer submitting code does not automatically mean that the work is complete.
And a commit reference is not sufficient evidence for every type of requirement.
For example, imagine a DevelopmentRequest requiring:

Unit tests pass
Security review completed
Metaverse integration demonstrated A single commit cannot prove all three. The stronger model we are building maps evidence explicitly: { "evidence": [ { "requirement": "Unit tests pass", "reference": "ci:test-run:4821" }, { "requirement": "Security review completed", "reference": "review:security:913" }, { "requirement": "Metaverse integration demonstrated", "reference": "demo:metaverse:42" } ] } The goal is simple: VERIFIED only when every required evidence item has been covered That gives VERIFIED a much stronger meaning. Building a feedback loop All of these components are starting to converge into the same architecture: Real person ↓ Real activity ↓ Data / Evidence ↓ MyZubster ↓ Verified Knowledge ↓ Zorgax ↓ DevelopmentRequest ↓ Developer ↓ GitHub ↓ Tests ↓ Independent verification ↓ New Knowledge Eventually the Metaverse can become one of the interfaces used to navigate this system. The wallet can become one component of identity. GitHub can preserve technical history. Zorgax can assist with knowledge and development. DevelopmentRequest can connect knowledge to actionable work. But none of these components should automatically create trust by themselves. What comes next Our immediate engineering priorities are:
Complete the Marketplace Seller-limit and authorization validation.
Finish the authenticated Marketplace end-to-end flow.
Continue hardening Metaverse authentication and sessions.
Add privacy-safe onboarding and mission analytics.
Improve realtime reliability and acceptance testing.
Continue building the Zorgax verified Knowledge Layer.
Strengthen DevelopmentRequest evidence verification.
Connect DevelopmentRequest with GitHub and the Contribution Graph.
Move MYZ accounting to durable storage before production settlement.
Keep external payouts gated behind independently verified evidence. MyZubster is still experimental. Several important production gates remain open. That is intentional. Building in public should not mean publishing only successful demos. It should also mean documenting: what worked what failed why it failed what evidence we collected what needs to change and what we still cannot claim That is how we want to build MyZubster. Not by automating trust. By making the system increasingly inspectable, testable, and verifiable. Repository: https://github.com/danieldirimini-myzubster/myzubster Website: https://www.myzubster.com Metaverse: https://www.myzubster.com/metaverse

MyZubster After the Institutional Hearing: From the Metaverse to Real-World Pilots and Verifiable Knowledge

Daniel Ioni — Tue, 22 Sep 2026 15:28:58 +0000

MyZubster After the Institutional Hearing: From the Metaverse to Real-World Pilots and Verifiable Knowledge
September 22, 2026 — MyZubster
Today we presented MyZubster starting from what already exists: a virtual environment that could be opened and tested live, a real pilot involving a real person, a technical history that can be linked to GitHub, a Knowledge Layer for Zorgax, and an initial structured workflow designed to transform verified knowledge into development work.
The occasion was an institutional hearing connected to the ongoing work around Italy’s national strategy for Artificial Intelligence.
For us, the most important part of the meeting was practical. We did not have to describe only a future vision. We were able to show how several parts of the ecosystem are already beginning to connect.
Showing the MyZubster Metaverse
During the hearing, we opened the MyZubster metaverse and allowed the participants to explore and test it directly.
This gave us the opportunity to explain that, in our vision, a metaverse is not simply a virtual environment where an avatar moves around.
The goal is to progressively build an environment where a person can enter with a digital identity, interact with other people and services, use a wallet, and connect those interactions with a verifiable history of contributions and activities.
In this model, GitHub can play an important role.
A commit, a pull request, a resolved issue, or a piece of software can represent technical evidence of work that was actually performed.
A wallet can represent another component of identity and interaction.
The metaverse therefore becomes the visible interface of a broader chain:
person → identity → activity → contribution → evidence → knowledge → new interaction
Nicola as a Real Pilot Case
To make the concept concrete, we presented the case of Nicola.
We did not present Nicola as a theoretical example, nor as scientific validation.
He is a real person who has participated in the MyZubster ecosystem and in practical experimentation.
One of the first cases was deliberately simple: a physical handover of kefir.
The workflow recorded the delivery, the confirmation of receipt, and the final completion of the process.
The handover was free, with no payment involved, and in this specific case it was not recorded as a blockchain transaction.
The purpose of this small pilot was not to scientifically validate anything about kefir.
The purpose was to test whether a real-world activity could be represented digitally and leave behind usable evidence.
This leads to one of the central questions behind MyZubster:
How can a simple activity become evidence, and how can a collection of evidence become usable knowledge?

From User to Contributor and Developer
Nicola's involvement did not stop with the pilot.
He also tested parts of MyZubster, reported issues, and worked on his own technical software.
During the hearing, we also explained the software he has been developing using artificial intelligence.
The concept behind that work is to use AI to assist the creation of software, virtual environments, metaverse-related systems, and technical ideas that can potentially connect back into the MyZubster ecosystem.
This gives us a broader model of participation:
user → tester → contributor → developer → producer of new evidence and knowledge
GitHub becomes important again at this stage.
The goal is not to automatically assign value to someone simply because they have a wallet or a GitHub account.
The goal is to be able to reconstruct, when necessary, what was actually built, tested, changed, or contributed.
Zorgax: A Conversation Is Not Knowledge
Another important part of the presentation focused on Zorgax.
One of the principles behind our recent development work is simple:
A conversation is not knowledge.

An AI model can generate a convincing answer and still be wrong.
For this reason, we have started separating different stages:
Conversation
↓
Candidate Information
↓
Sources and Evidence
↓
Review
↓
Verified Knowledge
↓
Use by Zorgax
We have implemented a Knowledge Layer that can preserve information such as provenance, versioning, visibility, sources, evidence, and relationships between knowledge items.
The direction is clear:
Zorgax can assist with research, organization, retrieval, and development, but information should not automatically become verified knowledge simply because an AI generated it.
Turning Knowledge Into Development
The next problem was equally important.
Once knowledge has been verified, how do we transform it into software development?
This led us to implement the first vertical slice of DevelopmentRequest.
A DevelopmentRequest is designed to act as a neutral technical contract between verified knowledge and implementation work.
The current lifecycle is:
DRAFT
↓
OPEN
↓
IN_PROGRESS
↓
SUBMITTED
↓
VERIFIED / REJECTED
A DevelopmentRequest can contain requirements, acceptance tests, required evidence, and references to the verified Knowledge from which the request originated.
Before creating the persistent request, the system generates a preview and a digest and requires explicit confirmation.
The Knowledge references are also captured with their content hash and version, creating a snapshot of the information on which the development request was based.
This is important because knowledge can evolve over time.
A development task should be able to show which version of the knowledge it was based on.
Development Is Separate From Payment
We also made another architectural decision:
A DevelopmentRequest does not automatically mean a bounty, reward, or payment.

Development work should exist independently from its economic model.
A technical request can therefore be created, assigned, implemented, submitted, and verified without automatically triggering funding or settlement.
Payment systems can be attached later, where appropriate, as a separate layer.
This separation is important for universities, open-source contributors, research environments, volunteers, funded work, and community experimentation.
They do not all operate under the same economic model.
Evidence Before Verification
Another principle we are strengthening is the difference between submission and verification.
Submitting code does not mean the work is verified.
Adding a commit reference does not automatically prove that every requirement has been satisfied.
For this reason, DevelopmentRequest includes explicit evidence requirements.
The current work is strengthening the rule that a request should only reach VERIFIED when every required evidence item has been properly covered and reviewed.
We also separate the contributor from the reviewer.
The person who created or implemented the work should not automatically be the person who independently verifies it.
This gives us a much clearer chain:
Knowledge
↓
DevelopmentRequest
↓
Developer
↓
Implementation
↓
Tests and Evidence
↓
Independent Review
↓
Verified Result
↓
New Knowledge
Connecting Everything Together
When these pieces are combined, the broader MyZubster architecture becomes easier to understand:
Real Person
↓
Real-World Activity
↓
Data / Evidence
↓
MyZubster
↓
Knowledge
↓
Zorgax / AI Assistance
↓
DevelopmentRequest
↓
Developer
↓
Code / GitHub
↓
Tests
↓
Independent Verification
↓
New Knowledge
↓
Wallet / Identity
↓
MyZubster Metaverse
↓
New Activities
This also helps explain what MyZubster is not trying to become.
We are not trying to build only a chatbot.
And we are not trying to build only a metaverse.
We are trying to build the connection between people, artificial intelligence, knowledge, software development, identity, evidence, and verifiable contributions.
The University Path
During the hearing, we also explained the dialogue we have started with universities and research groups.
We have contacted academic teams working in areas such as artificial intelligence, agriculture and food science, fermentation, circular economy, LCA/LCSA, water management, monitoring, and impact measurement.
We were careful not to present these discussions as formal partnerships.
In several cases we have shared documentation, received requests for additional information, or started preliminary conversations.
At this stage, we are waiting for further evaluations and feedback.
During the institutional discussion, we were encouraged to continue exploring the university path, with particular attention to the University of Bologna for the AI-related aspects of the project.
A possible future discussion involving Professor Michela Milano was also mentioned.
At this stage, this should be understood as a possible next contact or academic direction, not as an already established collaboration.
Why Universities Matter
This university dimension is important because it defines a boundary between what software can do and what requires scientific expertise.
MyZubster can build workflows, traceability systems, software, knowledge infrastructure, and evidence mechanisms.
But when a pilot becomes a scientific experiment, other requirements become necessary:
protocols, methodology, measurements, controls, ethics, safety, scientific interpretation, KPIs, and validation.
This is where universities and research institutions can play an essential role.
The AI should assist the process.
It should not replace scientific responsibility.
The LIFE 2027 Direction
We also discussed the exploratory LIFE 2027 path.
At this stage, there is no approved or funded MyZubster LIFE project.
The work is still exploratory.
The idea is to start from small real-world cases and determine whether some of them can evolve into scientifically structured pilots.
Areas we have explored include:
kefir and fermentation, circular water, circular economy, Living Labs, traceability, and measurable environmental or social impact.
The important principle remains the same:
MyZubster can help collect data, structure evidence, connect people and tools, and preserve knowledge.
Scientific validation must come from the appropriate experts and institutions.
AI as an Assistant, Not as the Final Authority
The hearing also gave us the opportunity to clarify how we see the role of artificial intelligence.
The objective is not to automate responsibility.
The objective is to use AI to:

help people navigate complex information;
connect problems with relevant knowledge;
assist software development;
organize evidence;
improve traceability;
preserve useful knowledge;
help transform verified knowledge into actionable development work. The final responsibility for consequential decisions should remain with people. What We Learned From the Hearing The hearing forced us to explain MyZubster without hiding behind technical complexity. That was useful. The project can ultimately be described in a much simpler way: We start from real people, collect real evidence, use artificial intelligence to assist the process, and try to make the path from an idea to something actually built increasingly verifiable.

The metaverse is one interface.
The wallet is one tool.
GitHub preserves part of the technical history.
Zorgax connects assistance and knowledge.
DevelopmentRequest connects knowledge with development work.
Developers build.
Other people review.
Universities can help define the scientific method when the process enters the research domain.
What Comes Next
The next step returns to engineering.
We are continuing to strengthen DevelopmentRequest, especially the relationship between required evidence and verification.
After that, the goal is to progressively connect DevelopmentRequest with the Contribution Graph and GitHub activity.
At the same time, we will continue developing the Zorgax Knowledge Layer and wait for the next steps emerging from the institutional and university discussions.
The hearing was not an endpoint.
It was another real test of the question behind MyZubster:
Can we build an ecosystem where people, AI, software, and virtual environments collaborate without automating trust — but instead making what happened increasingly verifiable?

That is what we are trying to build.
MyZubster
Open Source • Verified Knowledge • Zorgax • Metaverse • Developers • Community • Research

Building a Verified Knowledge Layer for Zorgax — and Turning It Into a Developer Marketplace

Daniel Ioni — Tue, 22 Sep 2026 06:18:14 +0000

Building a Verified Knowledge Layer for Zorgax — and Turning It Into a Developer Marketplace
How we moved Zorgax from a conversational assistant toward a persistent, reviewable knowledge system — and what comes next for MyZubster Development.
During the last development cycle of MyZubster, we reached an important architectural question:
What happens when an AI assistant stops being only a chat interface and starts accumulating knowledge about the system it helps build?

For Zorgax, our answer is not “let the model remember everything.”
It is almost the opposite.
We are building a verified knowledge layer where information has provenance, review status, visibility rules, evidence, and an explicit path from discovery to publication.
This is the first step toward something larger: Zorgax Development, a marketplace where verified knowledge can become specifications, development requests, bounties, implementations, reusable modules, and new knowledge.
The Problem: Chat Is Not Knowledge
An AI conversation can contain useful information, but that does not make every statement true.
The same applies to:

web search results,
repository observations,
user messages,
model-generated explanations,
old documentation,
test output,
roadmap ideas. We therefore started with one fundamental rule: message != knowledge candidate != verified verified != public This distinction is becoming one of the most important architectural boundaries inside Zorgax. Instead of allowing the assistant to silently “learn” whatever appears in a conversation, knowledge goes through an explicit lifecycle. We Already Had More Infrastructure Than We Expected Before creating another database or another model, we audited the existing MyZubster architecture. We found that the project already contained several useful building blocks: KnowledgeContribution Knowledge reward flows Knowledge evidence Evidence hashing ResearchDocument ZorgaxMemory MYZ reward lifecycle Independent review That changed the implementation strategy. Rather than creating a completely separate KnowledgeAsset system, we extended the existing knowledge infrastructure and made Zorgax a consumer and producer of that system. This matters because duplicated truth systems eventually disagree. We want one canonical knowledge lifecycle. The New Zorgax Knowledge Flow The first implemented vertical slice now looks like this: User / Engineering Work ↓ Zorgax Knowledge Preview ↓ Deterministic SHA-256 Digest ↓ Explicit Human Confirmation ↓ PENDING_REVIEW ↓ Independent Review ↓ APPROVED ↓ Internal Zorgax Retrieval ↓ Explicit Publication ↓ PUBLIC Knowledge There are several deliberate safety boundaries inside this flow.
Zorgax Does Not Persist Knowledge Automatically When knowledge is prepared, Zorgax first creates a preview. Conceptually: { title: "Kefir community contract", category: "marketplace", description: "Kefir culture listings are FREE-only." } A deterministic SHA-256 digest is generated from the normalized preview. The user then receives an explicit confirmation token such as: CONFERMA a1b2c3d4 Nothing persistent has happened yet. Only after the exact preview is confirmed can it enter the knowledge database. If the preview changes after confirmation, the digest changes and the write is rejected. This gives us a useful invariant: Human confirmation applies to the exact data being persisted, not merely to the general intention to save something.

New Knowledge Starts as INTERNAL A confirmed knowledge contribution does not immediately become public documentation. It starts as: status = PENDING_REVIEW visibility = INTERNAL That gives us two independent dimensions: verification state visibility state They are intentionally separate. For example: PENDING_REVIEW + INTERNAL APPROVED + INTERNAL APPROVED + PUBLIC REWARDED + PUBLIC A contribution can therefore be verified without automatically becoming public.
Legacy Knowledge Fails Closed
One subtle problem appears when adding visibility rules to an existing database.
What should happen to older records that do not yet contain a visibility field?
We chose the conservative behavior:
missing visibility = INTERNAL
Not PUBLIC.
That means deploying the new feature cannot accidentally expose historical knowledge.
This is a small implementation detail, but it represents a larger rule we use throughout MyZubster:
When authorization or privacy metadata is missing, fail closed.
Public and Internal Retrieval Are Different
Zorgax now distinguishes two knowledge scopes.
For normal or guest requests:
PUBLIC knowledge only
For explicitly authorized internal/admin contexts:
PUBLIC + INTERNAL verified knowledge
The assistant never receives PENDING_REVIEW or REJECTED contributions as canonical context.
The verified states currently accepted by retrieval are:
APPROVED
REWARD_ELIGIBLE
REWARDED
That gives us a much stronger model than “search every document and put it into the prompt.”
Verified Knowledge Is Injected Into the Zorgax Prompt
Once retrieval was working, we connected it to the shared Zorgax assistant prompt.
The runtime context can now contain a section conceptually similar to:
INTERNAL VERIFIED KNOWLEDGE

[K1] Public marketplace invariant
status=APPROVED
visibility=PUBLIC
category=marketplace

Kefir culture listings are FREE-only.
Internal items are injected only when the request has the appropriate scope.
This means Zorgax can now answer using three different classes of context:
Canonical runtime facts
Verified internal/public knowledge
Live external research
Those sources are not treated as equivalent.
That distinction will become increasingly important as the system grows.
Knowledge Is Not the Same as Memory
MyZubster already has ZorgaxMemory, but we intentionally did not turn it into the canonical knowledge database.
They serve different purposes.
Zorgax Memory
Useful for temporary/user-related conversational context.
It already distinguishes claims such as:
verified
uncertain
speculative
fictional
and can expire through TTL.
ResearchDocument
Stores retrieved/crawled material.
It includes fields such as content hashes and crawl timestamps.
But retrieved material is still evidence — not automatically truth.
KnowledgeContribution
This is where reviewed shared knowledge lives.
That separation gives us:
Memory
≠
Research
≠
Verified Knowledge
We Kept Knowledge Rewards Separate From Knowledge Truth
MyZubster already has a knowledge-to-MYZ contribution flow.
We preserved an important invariant:
Creating knowledge does not automatically create a reward.

The lifecycle can move through states including:
PENDING_REVIEW
APPROVED
REJECTED
REWARD_ELIGIBLE
REWARDED
Independent review is required.
Reward eligibility is another step.
And final reward state requires authoritative ledger evidence.
The knowledge system therefore does not say:
AI generated something
→ pay someone
Instead:
Contribution
→ Review
→ Verification
→ Eligibility
→ Ledger process
This will matter a lot once we connect knowledge to development work.
We Also Fixed Zorgax Live Research
While integrating the knowledge layer, one regression test exposed another useful architectural inconsistency.
The Zorgax capability endpoint said that Google News was available, and the tests expected current/time-sensitive queries to use it before Wikipedia.
But the implementation still contained:
async function googleNewsSearch() {
return [];
}
The capability existed conceptually, but not operationally.
We implemented a lightweight Google News RSS fallback without introducing another parsing dependency.
For time-sensitive queries, the search strategy now becomes conceptually:
Brave Search
Tavily
Google News
Wikipedia
When paid search API keys are absent:
Google News
Wikipedia
For non-current informational queries, Wikipedia remains a useful background fallback.
This distinction matters because these questions are fundamentally different:
"What is climate?"
and:
"What are the latest climate developments today?"
Freshness is part of the query semantics.
The targeted Zorgax assistant and Knowledge regression tests are now green. Full-suite verification remains a release gate before considering that stabilization cycle complete.
Testing the Knowledge Boundary
We added tests specifically for the new invariants.
Among other things, the tests verify that:
A preview does not persist data.

Changing a preview invalidates its digest.

Confirmed knowledge enters as PENDING_REVIEW.

New contributions default to INTERNAL.

Public retrieval returns only explicitly PUBLIC knowledge.

Internal retrieval can include verified INTERNAL knowledge.

Unreviewed knowledge never reaches the assistant prompt.

Guest prompts cannot receive INTERNAL knowledge.

Admin/internal prompts can receive INTERNAL knowledge.

Knowledge retrieval fails safely when MongoDB is unavailable.
The current focused regression set for this vertical slice passes:
5 test suites
25 tests
25 passing
We also integrated the work using an isolated Git worktree so an unrelated Zorgax research fix and another untracked verifier project were not accidentally mixed into the Knowledge commit.
That operational discipline matters too.
A reliable architecture can still be damaged by careless integration.
The Larger Goal: Zorgax Development
The Knowledge DB is not the final product.
It is infrastructure for the next layer.
We want knowledge to become executable development coordination.
The future loop looks like this:
Engineering Work
↓
Evidence
↓
Candidate Knowledge
↓
Verification
↓
Knowledge DB
↓
Specification
↓
Development Request
↓
Proposal
↓
Bounty
↓
Implementation
↓
Tests
↓
Verification
↓
Accepted Delivery
↓
Reward
↓
Reusable Module
↓
New Knowledge
This is the foundation of what we call Zorgax Development.
Knowledge Should Be Open. Execution Has Value.
We do not want to put a paywall around every technical fact.
The more interesting economic model is:
Knowledge is open. Execution has value.

A verified architecture decision can be public.
A privacy invariant can be public.
A testing pattern can be public.
But someone may still need help turning that knowledge into:

an implementation,
an integration,
a migration,
an audit,
a reusable module,
an automation,
a deployment,
a security review,
a verified delivery. That is where a development marketplace becomes useful. A Future Development Request Could Look Like This Instead of publishing only free-form job descriptions, Zorgax could generate machine-readable development requests from verified knowledge. For example: { "title": "Add verified Knowledge retrieval to an assistant", "domain": "ai-infrastructure", "requirements": [ "Only reviewed knowledge can enter canonical context", "Internal knowledge must never reach guest users", "Persistent writes require explicit confirmation", "Legacy records must fail closed" ], "acceptanceTests": [ "guest receives PUBLIC knowledge only", "admin may receive INTERNAL knowledge", "PENDING_REVIEW records are excluded" ], "evidenceRequired": [ "passing tests", "commit reference", "review record" ] } That request could then become: DevelopmentRequest → Proposal → Bounty → Delivery → Verification The knowledge itself becomes part of the specification. Evidence-Based Reputation Instead of Stars A development marketplace also needs reputation. We do not want reputation to be only: ★★★★★ Instead, reputation can be derived from actual evidence:
accepted pull requests,
verified deliveries,
passing contract tests,
maintained modules,
successful security reviews,
useful knowledge contributions,
independent reviews,
resolved disputes,
reverted or failed deliveries. The goal is not to create a popularity score. The goal is to answer: What has this contributor demonstrably delivered?

Selective Decentralization
We are also interested in decentralized verification, but that does not mean putting the entire Knowledge DB on-chain.
That would be expensive, inflexible, and unnecessary.
A more useful split is:
Off-chain
documentation
source code
knowledge content
search indexes
embeddings
development artifacts
Verifiable / potentially on-chain
content hashes
authorship references
licenses
bounty references
acceptance commitments
settlement references
evidence anchors
The chain can help verify commitments.
It does not need to become the document database.
Search and Embeddings Will Be Derived, Not Canonical
The current MVP can work with MongoDB and structured filtering.
Later we can add:
full-text search
semantic search
embeddings
vector indexes
graph relationships
But those will be derived indexes.
The canonical object remains the reviewed Knowledge record.
This prevents a vector database from silently becoming the definition of truth.
Automatically Generated Knowledge — Without Automatically Generated Truth
Eventually, Zorgax should be able to observe engineering evidence such as:
commits
test results
pull requests
architecture decisions
runtime contracts
evidence hashes
documentation changes
and propose new Knowledge candidates automatically.
For example:
Commit:
fix(kefir): enforce free-only culture donations

Tests:
kefirMarketplaceContract
kefirHandDelivery

Extracted candidate:
"Kefir culture listings in the community marketplace are FREE-only."
But the important word is candidate.
Automation can accelerate extraction.
It should not silently promote its own conclusions to verified truth.
So the future system remains:
automatic extraction
↓
candidate
↓
evidence
↓
verification policy / human review
↓
canonical knowledge
What Comes Next
The immediate roadmap is now clearer.
We want to extend Knowledge records with stronger provenance and versioning, connect engineering evidence automatically, improve internal search, expose selected verified assets through the public MyZubster Knowledge site, and then introduce the first DevelopmentRequest lifecycle.
From there, Zorgax can begin transforming questions into structured work.
A user could eventually ask:
“Can MyZubster support verified repair services in the Marketplace?”

Instead of producing only an answer, Zorgax could reason through the existing Knowledge DB and generate:
Known architecture
Missing capability
Required invariants
DevelopmentRequest
Acceptance tests
Evidence requirements
Potential bounty
That is where the assistant becomes more than a chatbot.
It becomes part of the development coordination layer.
The Direction
The architecture we are building can be summarized with one loop:
QUESTION
↓
KNOWLEDGE
↓
ARCHITECTURE
↓
DEVELOPMENT REQUEST
↓
IMPLEMENTATION
↓
TESTS
↓
VERIFICATION
↓
DELIVERY
↓
REWARD
↓
NEW KNOWLEDGE
Zorgax is starting to sit in the middle of that loop.
Not as an autonomous authority.
Not as a model that “knows everything.”
But as an evidence-aware system capable of turning verified knowledge into useful action while keeping human confirmation, review, privacy, and verification boundaries explicit.
That is the foundation we want for Zorgax Development.
We did not come to automate trust. We came to make trust verifiable.

From Automated Knowledge to a Developer Marketplace: How We’re Structuring Zorgax Development

Daniel Ioni — Tue, 22 Sep 2026 05:47:06 +0000

From Automated Knowledge to a Developer Marketplace: How We’re Structuring Zorgax Development
Software projects usually accumulate knowledge in the worst possible places.
Some of it lives in source code. Some is hidden inside test failures. Some appears in GitHub issues. Some survives only in deployment notes, terminal sessions, architectural decisions, or conversations between developers.
Over time, this creates a strange situation: the project contains a huge amount of knowledge, but the knowledge itself is difficult to search, reuse, verify, or turn into new work.
With MyZubster and Zorgax, we are starting to structure a different model.
The idea is to build a pipeline where engineering activity produces structured knowledge automatically, that knowledge becomes part of a canonical technical knowledge base, and selected parts of it can then become the foundation of a development marketplace.
The goal is not to sell documentation.
The goal is to make knowledge executable.
The problem: engineering knowledge disappears after the fix
Consider a normal debugging session.
A failing test leads to an investigation. The investigation reveals that a privacy field is leaking through a public API. The production code is fixed. A regression test is added. A commit is created.
From a Git perspective, the job is done.
But several valuable pieces of knowledge were created during that process:
Public cultural APIs must never expose account ownership.

Restricted location information must remain server-side.

PRIVATE and unreleased AUTHORIZED_RELEASE locations must not expose
public location text.

Tests should verify the privacy invariant rather than obsolete field names.
Those principles are more valuable than the individual patch.
They can be reused in another API, another marketplace, another application, or another developer’s project.
The same thing happened while stabilizing payments, social authentication, Seller onboarding, community exchanges, and the test architecture.
So we started asking a different question:
What if every important engineering decision could become reusable structured knowledge?
Knowledge should be generated from real engineering work
We are building the MyZubster Knowledge layer around evidence produced by the development process itself.
Instead of writing documentation only after the fact, knowledge can be extracted from things such as:
tests
production fixes
commit history
architecture decisions
API contracts
security invariants
payment rules
deployment procedures
incident investigations
bounties
verification results
The important part is that the resulting knowledge should not simply be an AI-generated summary.
It should have provenance.
A knowledge entry should be connected to the implementation, tests, decisions, and version that justify it.
Conceptually, a knowledge asset might look like this:
{
"id": "knowledge-public-api-privacy-v1",
"title": "Public API ownership and location privacy",
"domain": "security",
"version": "1.0.0",
"status": "verified",
"source": {
"repository": "myzubster",
"tests": [
"zorgaxCulturalApi.test.js"
],
"implementation": [
"zorgaxCulturalController.js"
]
},
"invariants": [
"Public event reads do not expose ownerId",
"Restricted location text is never public"
]
}
Now the information is no longer just prose.
It has identity, versioning, provenance, and an explicit contract.
Zorgax becomes the interface to this knowledge
Zorgax is not meant to be only a chatbot sitting in front of documentation.
The more interesting role is to make the knowledge operational.
A developer could ask:
How should I design a public event API without leaking organizer identity?

Zorgax could retrieve the relevant architectural knowledge and explain the pattern.
But that is only the first layer.
The user could then say:
Apply this architecture to my project.

At that point we move from knowledge retrieval into development work.
That transition is where Zorgax Development becomes important.
From knowledge to development requests
We are structuring Zorgax Development around a simple progression:
Question
↓
Knowledge
↓
Architecture
↓
Development request
↓
Proposal
↓
Implementation
↓
Tests
↓
Verification
↓
Delivery
This creates a natural bridge between an AI knowledge system and a developer marketplace.
Someone may start by reading a free article about payment verification.
Then they ask Zorgax how that architecture would apply to their application.
Zorgax can produce a technical specification.
That specification can become a development request.
A developer, team, or eventually an authorized development agent can propose an implementation.
The implementation can be tested against explicit acceptance criteria.
Only then does the work become a verified delivery.
Knowledge is open. Execution has value.
This distinction is central to the model.
We do not want to build a platform where every useful idea disappears behind a paywall.
Open knowledge creates trust, improves the ecosystem, helps developers learn, and allows technical claims to be examined publicly.
The commercial layer begins when someone wants that knowledge transformed into a result.
The model we are exploring is:
OPEN

architecture
engineering principles
public documentation
security patterns
testing strategies
basic implementation guidance

MONETIZED

custom implementation
integration
migration
security review
technical audit
verified delivery
reusable production modules
development bounties
ongoing support
This is similar to open-source software.
The source can be open while professional implementation still has economic value.
Building a marketplace around verified development
A development marketplace should not work like a generic gig board.
Software work has structure.
A request can have requirements, a repository, tests, acceptance criteria, dependencies, security constraints, budget, and an expected delivery artifact.
So a development request could eventually be represented explicitly:
{
"title": "Add privacy-safe event locations",
"repository": "example/project",
"requirements": [
"Public API must not expose account ownership",
"Exact location must remain private",
"Existing organizer access must continue working"
],
"acceptance": {
"testsRequired": true,
"humanReviewRequired": true
},
"reward": {
"asset": "MYZ",
"amount": 500
}
}
This is far more useful than:
“Need backend developer, $200.”

The task becomes machine-readable.
Zorgax can understand it.
Developers can reason about it.
Tests can verify parts of it.
Payment systems can reference it.
And the knowledge produced while solving it can potentially return to the ecosystem.
Development creates more knowledge
This produces an interesting feedback loop.
Imagine that a developer completes the task above.
During implementation, they discover an edge case involving delayed location release.
They add a new test and document the rule.
That new rule becomes another knowledge asset.
Now the system looks like this:
Knowledge
↓
Development
↓
Implementation
↓
Verification
↓
New knowledge
↓
Better future development
The marketplace is no longer consuming knowledge.
It is producing it.
That is one of the ideas we find most interesting.
Knowledge assets can become reusable modules
Some solutions will eventually move beyond documentation.
A repeated architecture may become a reusable module.
For example, after implementing the same pattern several times, the platform could evolve from:
Knowledge:
"How to verify server-owned payment expectations"
to:
Reference implementation
and eventually to:
Reusable verified module
Examples could include authentication, payment verification, marketplace listings, identity linking, privacy projections, entitlement management, reputation, escrow coordination, or development workflow automation.
The knowledge explains why the module exists.
The tests explain what it guarantees.
The implementation makes it usable.
That combination is much more valuable than code alone.
What decentralization actually needs
We are also exploring how this could support a decentralized marketplace.
That does not mean putting everything on a blockchain.
Most engineering knowledge does not belong on-chain.
Large documents, source code, conversations, and specifications are better stored in Git repositories, databases, or content-addressed storage.
A decentralized layer is more useful for small pieces of verifiable state.
For example:
content hashes
authorship attestations
licenses
ownership
bounty references
payment settlement
delivery acceptance
reputation events
verification records
This allows the marketplace to prove that a particular artifact existed, who published it, which version was accepted, and how a reward was settled without forcing the entire development process onto a blockchain.
Human approval remains important
AI can help generate specifications, search knowledge, compare architectures, prepare code changes, and analyze tests.
But development marketplaces involve consequential actions.
Publishing code, spending money, releasing escrow, accepting a delivery, or changing production infrastructure should not silently happen because an AI model decided it looked correct.
The architecture we are moving toward keeps explicit boundaries around those actions.
Zorgax can advise.
Zorgax can prepare.
Zorgax can verify evidence.
But important execution steps should remain attributable and reviewable.
That principle also makes the marketplace easier to audit.
Reputation should come from evidence
Traditional marketplace reputation often becomes a star rating.
For software development, we can do better.
A development reputation graph could be based on evidence such as:
accepted pull requests
verified deliveries
passing contract tests
maintained modules
resolved bounties
security reviews
documented knowledge contributions
reverted or disputed deliveries
A developer who repeatedly produces maintainable code with good tests should accumulate a very different reputation from someone who simply receives five-star ratings.
This also gives AI systems better signals when helping users choose contributors.
MYZ can represent internal economic coordination
The MyZubster ecosystem already distinguishes between internal accounting and external settlement.
That same separation can be useful here.
Development rewards could be denominated in MYZ where appropriate, while external settlement remains a separate concern.
The important rule is that rewards should be based on verified state.
A test passing should not magically create money.
A pull request existing should not automatically mean a bounty is complete.
A delivery needs an explicit lifecycle.
Conceptually:
CREATED
↓
FUNDED
↓
IN_PROGRESS
↓
DELIVERED
↓
VERIFIED
↓
ACCEPTED
↓
REWARDED
Disputes and cancellations need their own states as well.
This prevents the marketplace from confusing activity with completion.
The Knowledge site becomes the canonical layer
DEV articles like this one explain what we are building and why.
The MyZubster Knowledge site has a different role.
It should become the canonical technical layer.
Instead of storytelling, it should contain things like:
Architecture
Privacy invariants
Authentication contracts
Payment architecture
Marketplace rules
Testing strategy
Development protocols
Decision records
Knowledge assets
Verification rules
That means the same engineering work can produce multiple forms of value.
A debugging session can produce:
a production fix
a regression test
a Git commit
a knowledge entry
a DEV article
a reusable architecture
a future marketplace asset
Nothing has to be thrown away.
Automated knowledge does not mean automated truth
This distinction matters.
An AI can generate thousands of documents very quickly.
That does not create a useful knowledge system.
Knowledge becomes valuable when it is connected to evidence.
We want automated extraction to help answer questions such as:
What changed?

Why did it change?

Which invariant does it protect?

Which tests verify it?

Which implementation currently enforces it?

Which version introduced it?

Is it still true today?
If those questions cannot be answered, the output is probably documentation, not verified knowledge.
The longer-term architecture
The system we are gradually structuring can be summarized like this:
Engineering activity
│
▼
Evidence extraction
│
▼
Structured Knowledge
│
├──────────────► Public Knowledge Base
│
▼
Zorgax
│
▼
Architecture / Specification
│
▼
Zorgax Development Marketplace
│
┌───┼───────────────┐
▼ ▼ ▼
Bounties Services Modules
│ │ │
└───┴───────┬───────┘
▼
Verified Delivery
│
▼
Reward
│
▼
New Engineering Evidence
│
└────────► New Knowledge
It is a loop.
And that is intentional.
What we are building toward
The vision is not an AI that pretends to know everything.
It is an ecosystem where knowledge can be traced back to real engineering work.
Where developers can reuse that knowledge.
Where Zorgax can turn it into actionable specifications.
Where implementations can be commissioned through a marketplace.
Where delivery can be verified through explicit contracts.
Where useful solutions return to the knowledge base.
And where the economic layer rewards actual implementation and contribution instead of simply locking information behind a paywall.
We are still building the pieces.
But the architecture is becoming clearer:
open knowledge, verifiable engineering, paid execution, reusable results.
If that loop works, a software project stops being only a repository.
It becomes a system that learns from its own development.

opensource #ai #webdev #marketplace #nodejs

DEV Community: Daniel Ioni

MyZubster Engineering Dev Log

MyZubster Engineering Dev Log

Sepolia E2E Infrastructure, Google OAuth Validation, Runtime Stabilization and the Road Toward a Production-Grade Platform

1. Starting Point

2. Runtime Dependency Repair

3. PM2 Runtime Stabilization

4. MongoDB Connectivity

5. Google OAuth Investigation

6. OAuth Callback Observability

7. OAuth Session Error Isolation

8. Temporary Instrumentation Cleanup

9. Permanent OAuth Error Logging

10. Secret Hygiene

11. Frontend Proxy Investigation

12. Repository Cleanup

13. The Final Commit

14. Branch Isolation

15. Pull Request Created

16. CI/CD Evidence Gate

17. Sepolia E2E Work Already Present

18. What We Have Successfully Proven

Runtime

Database

Public routing

OAuth provider discovery

OAuth transport

Proxy behavior

Error observability

Secret handling

Git hygiene

Branch isolation

Upstream integration

CI evidence

19. What Is Not Finished Yet

19.1 CI Must Complete

19.2 OAuth Needs Full Application-Level Verification

20. OAuth State and Session Hardening

21. GitHub and Facebook Providers

22. Payment E2E Completion

23. Idempotency

24. Chain Finality Strategy

25. Observability Architecture

26. Correlation IDs

27. Metrics and Alerting

28. Dependency Reproducibility

29. Deployment Reproducibility

30. Infrastructure as Code

31. Environment Separation

32. Security Model

33. Target Architecture

34. Definition of Done

35. Immediate Engineering Roadmap

36. Where We Want to Arrive

Current Status

🚀 **MyZubster Development Update — Sepolia E2E, Google OAuth & I-ECO-01 Infrastructure Stabilization**

🔐 Google OAuth — End-to-End Backend Flow Completed

🌐 Sepolia Runtime URL Configuration

🏭 I-ECO-01 / UrbanLab Investigation

🔎 Root Cause Identified

🔧 Dependency Repair

✅ UrbanLab Restart Loop Resolved

❤️ I-ECO-01 Health Check

🔐 Escrow Multisig Service

📡 WebSocket Infrastructure

🍃 MongoDB Connectivity

⚙️ PM2 & VPS Infrastructure

☁️ Cloudflare / Public Routing

🧪 Why This Debugging Phase Was Important

📊 Current Development Status

🔒 Security

🛣️ Next Phase

MyZubster #Sepolia #Web3 #Blockchain #NodeJS #MongoDB #GoogleOAuth #OAuth2 #PM2 #Cloudflare #Monero #Escrow #Multisig #SocketIO #UrbanLab #Infrastructure #BackendDevelopment #DevOps #BuildInPublic #DevelopmentUpdate

MyZubster Marketplace + MetaMask: First Real Ethereum Sepolia Integration Test

From “Connect MetaMask” to Verifiable Marketplace Intent: What We Built in MyZubster and What Comes Next

1385 — MetaMask wallet ownership

1386 — signed Marketplace requests

1387 — optional Sign-In with Ethereum

1388 — Seller-visible wallet evidence

Connecting MetaMask to MyZubster: Building Wallet Ownership Without Turning Every Action Into a Blockchain Transaction

🚀 MyZubster Development Update — Sepolia E2E, Google OAuth & I-ECO-01 Infrastructure Stabilization