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
