Building Decentralized Knowledge: Our MyZubster Journey with Docker, Monero, PGP, Tor and Verifiable GitHub Contributions
How Daniel and Nicola are building an independent-node experiment, documenting technical knowledge, and exploring a future where open-source activity contributes to a verifiable professional reputation.
Tags: #opensource #docker #web3 #github
Introduction: Your GitHub Activity Is Part of Your Professional Story
What if your professional CV could be supported by the actual work you have completed?
What if you could connect your GitHub contributions, technical experiments, mentoring activities and acquired knowledge to reproducible tests and cryptographic evidence?
This is one of the ideas we are exploring with MyZubster.
My name is Daniel Ioni, and I am collaborating with Nicola on an open-source development and knowledge-sharing experiment.
Our goal is to explore how independent developers can build their own infrastructure, learn from each other, document their activities and progressively establish verifiable technical portfolios.
We are beginning with something practical: installing MyZubster locally, configuring Docker, connecting an independent development node to our VPS, and gradually testing cryptographic technologies such as PGP, Monero and blockchain-based document verification.
Rather than presenting decentralization as an abstract concept, we want to build and document the process.
Every meaningful technical milestone should eventually become a reproducible guide that other developers can follow.
1. From Knowledge Transfer to Independent Infrastructure
Our collaboration includes developing MyZubster, configuring a local development environment and experimenting with AI-assisted technical workflows.
I have guided Nicola through installing MyZubster locally. He is also using ChatGPT to assist with configuring his computer and continuing his technical experimentation.
His public repository contains a Docker-based MyZubster MVP, an API, AI-related components and the Nicola Comics project.
Repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
This creates an opportunity to study an important question:
Can a developer run an independent MyZubster installation while participating in a wider ecosystem without surrendering control of the local machine?
We are designing our first independent-node pilot to explore that question.
Nicola will maintain his own local environment, while a separately deployed bridge will allow specifically authorized information to pass between his installation and our infrastructure.
The initial architecture is deliberately limited.
We do not need access to Nicola's entire computer, private databases or personal files. We only need to demonstrate that two separate MyZubster installations can exchange approved technical requests and responses.
2. Our First Working Component: A Docker Bridge on the VPS
We have started developing the server-side component of our independent-node experiment.
Our VPS runs Ubuntu 24.04 LTS. It already hosts other infrastructure, including an existing Tor Onion container, so we decided to deploy the new bridge separately rather than modify running services.
The initial bridge uses Docker Compose and an isolated Python service.
Its HTTP interface is bound exclusively to the VPS loopback address:
ports:
- "127.0.0.1:8092:8092"
This means we are not exposing the experimental service directly to the public Internet.
We also configured separate credentials for administrative requests and requests originating from the future local node.
What have we tested?
Our first local tests confirmed that:
- The bridge container builds and starts successfully.
- The container reaches a healthy state.
- Its local health endpoint returns HTTP 200.
- Requests without credentials are rejected with HTTP 401.
- Requests authenticated with the administrator token are accepted.
- A simulated node can retrieve an authorized request and return a response.
- The administrator can retrieve the completed result.
During our first request-response test, we submitted a demonstration gallery request.
The simulated node returned:
{
"action": "gallery",
"titles": [
"Fumetto dimostrativo - Test VPS"
]
}
The bridge recorded the request as completed.
This is our first working communication milestone.
However, there is an important distinction: the successful test used a simulated node running against the VPS bridge. Nicola's actual computer is not connected yet.
HTTPS configuration, an external connection test, additional security reviews and deployment of Nicola's local connector are our next tasks.
We want to document these boundaries clearly rather than confuse a successful prototype test with a completed decentralized network.
3. Connecting Nicola's Local MyZubster Installation
Our proposed architecture is:
NICOLA'S COMPUTER
---------------------------
Local MyZubster
Docker Compose
Local API
Nicola Comics
Optional local AI services
Outbound-only connector
|
| Authenticated HTTPS
|
v
MYZUBSTER VPS
---------------------------
Independent-node bridge
Authorized request queue
Node identification
Request validation
Response verification
|
v
FUTURE INTEGRATIONS
---------------------------
MyZubster
Zorgax
Public technical demonstrations
Approved knowledge records
The connector will initiate outbound communication from Nicola's machine.
For the initial pilot, we will not expose his local API directly to the Internet.
We will also restrict the first integration to explicitly approved, read-only operations.
Our initial candidate is Nicola Comics, an experimental project that already has a documented local catalog interface.
The objective is to demonstrate a complete request-response exchange between two physically separate systems.
We also want to test what happens when Nicola disconnects his computer, when requests time out, or when credentials are invalid.
An independent node should remain under its operator's control.
What will other developers learn?
As the project develops, we intend to publish practical guides covering:
- Preparing an Ubuntu development server.
- Installing and configuring Docker and Docker Compose.
- Running MyZubster locally.
- Configuring a restricted API.
- Establishing authenticated communication between independent installations.
- Testing request validation, authentication and network failures.
- Collecting reproducible technical evidence.
The goal is not simply to distribute software. It is also to distribute the knowledge needed to understand, configure, test and maintain that software.
4. Our Decentralization Roadmap
Connecting two installations is the beginning of our experiment, not the final definition of decentralization.
Our development roadmap includes several separate stages.
| Stage | Objective | Current status |
|---|---|---|
| Local infrastructure | Run MyZubster independently with Docker | Local development documented |
| VPS bridge | Build and test the central bridge service | Initial VPS tests completed |
| Independent-node pilot | Connect Nicola's local installation | Planned |
| HTTPS and authentication | Secure communication between installations | Further configuration required |
| PGP | Explore signatures, key ownership and verifiable authorship | Planned |
| Monero | Study safe, read-only wallet integration and related APIs | Planned |
| Tor Onion | Evaluate private service connectivity and operational security | Existing infrastructure; further tests planned |
| Knowledge verification | Link documented activity to cryptographic evidence | Initial implementation and evidence available |
| Public developer profiles | Associate declared skills with independently inspectable work | Continuing development |
Each completed stage should produce technical documentation, test results and clearly identified limitations.
We intend to publish guides as the work progresses so that developers can repeat our experiments without depending on our specific infrastructure.
5. Monero: Exploring Financial Privacy Without Sacrificing Security
Monero is one of the technologies we want to investigate further.
MyZubster already contains Marketplace functionality for selecting cryptocurrency preferences, including XMR, BTC and ETH.
However, selecting an accepted currency is not the same as implementing a secure payment system.
Automatic currency conversion is not currently enabled in this functionality.
Our immediate Monero objective is therefore technical research rather than production payment processing.
We want to investigate the Monero Wallet RPC interface and study how an application can safely observe wallet-related information.
Our first experiments will focus on isolated environments and read-only operations.
Topics include:
- Separating wallet infrastructure from publicly accessible application services.
- Understanding pending, unconfirmed and confirmed transfer states.
- Safely handling RPC authentication and connection failures.
- Testing APIs without exposing spending credentials.
- Documenting security boundaries before considering any transaction-related features.
I have also previously prepared a proposed clarification for the Monero Wallet RPC documentation concerning the pending field in get_transfers.
That proposal was submitted as an upstream pull request but was closed without being merged.
It represents documentation and research activity, not an accepted upstream contribution or proof of a completed Monero integration.
The distinction matters because we want our professional records to reflect what actually happened.
6. PGP: Moving From Public Keys to Demonstrable Authorship
We also want to explore OpenPGP as part of the MyZubster knowledge-verification system.
MyZubster's existing user model already contains a field for storing a PGP public key.
That is a useful starting point, but storing a public key does not establish who controls its corresponding private key.
Our proposed next step is a proof-of-possession experiment.
For example, a developer could use their own private key to sign a temporary challenge associated with an authenticated account.
The system could then verify the signature using the registered public key.
We want to study:
- Public-key registration and fingerprint display.
- Verification of digital signatures.
- Signed technical documents.
- Key replacement and revocation.
- Replay protection.
- Secure separation between user-controlled private keys and public application services.
Private keys must remain under their owners' control.
The initial experiments will use dedicated test keys rather than personal production identities.
PGP could eventually help developers demonstrate that specific technical documents or knowledge records were signed by the holder of a particular key.
It cannot, by itself, establish that every statement inside a signed document is true.
That distinction is essential to our approach.
7. Tor Onion and Independent Services
MyZubster already has documented Docker infrastructure for a Tor v3 Onion service.
Our VPS also has an existing Onion container running.
This provides another area for practical research: making selected services reachable through an alternative network while preserving appropriate security boundaries.
We want to document:
- Configuring a Tor Onion service inside Docker.
- Managing persistent Onion identities securely.
- Separating internal application services from exposed interfaces.
- Testing service reachability using an external Tor client.
- Safely restarting services without unintentionally rotating identities.
- Verifying that private identity keys never enter public repositories.
An important principle is that a healthy Docker container does not automatically prove that its Onion endpoint is reachable.
External end-to-end verification is a separate requirement.
When we begin working on Nicola's local Onion configuration, we will treat it as a new test rather than assuming that the existing VPS installation proves his environment is correctly configured.
8. Blockchain Verification and the Limits of Cryptographic Proof
Another part of our collaboration is investigating how blockchain technologies can support verifiable technical documentation.
Nicola's repository includes Ethereum Sepolia proof experiments and Python verification utilities.
Our collaboration also has a documented snapshot of 30 GitHub commits associated with a Base Sepolia knowledge-transfer record.
These experiments help us study the relationship between:
- GitHub activity.
- Versioned documentation.
- Cryptographic hashes.
- Public blockchain attestations.
- Independently reproducible verification procedures.
For example, a SHA-256 digest can identify the exact bytes of a document.
A blockchain transaction or immutable smart-contract record can then help establish that a corresponding digest was recorded.
A verifier can compare the original document with the recorded value.
However, there are several important limitations.
A hash match proves an integrity relationship. It does not automatically prove that a developer wrote the document, successfully executed its instructions, acquired a particular skill or participated in every activity mentioned.
Those claims require appropriate additional evidence.
For our project, we want to combine technical evidence with transparent attribution and explicit participant confirmation.
We also intend to strengthen our existing experiments by reproducing verification through independently configured blockchain RPC services.
9. Building a Verifiable CV From Public GitHub Activity
This brings us to one of our longer-term objectives.
Traditional professional profiles frequently depend on self-reported experience.
GitHub provides a more concrete record of technical activities, but commits alone do not explain every contribution or demonstrate that a particular developer understands every technology used in a repository.
Our idea is to connect several different forms of evidence.
A developer's MyZubster profile could eventually contain:
Declared knowledge
Technologies, professional experience, interests and learning objectives provided by the developer.
Documented activities
GitHub commits, pull requests, technical documentation, reproducible experiments and public project contributions.
Technical verification
Test reports, cryptographic hashes, digital signatures and independently inspectable evidence.
Knowledge transfer
Documented mentoring sessions, technical guides, collaborative experiments and confirmation from participants.
Publication
Developer-approved Knowledge Cards connected to public repositories and professional profiles.
The result would not be an automatic certification of everything a developer claims.
Instead, it would be an evidence-based technical portfolio that helps other people understand what has been declared, what has been documented and what can actually be verified.
This could be particularly useful for independent developers, open-source contributors and people who acquire knowledge through practical experience rather than formal educational pathways alone.
Participation should remain voluntary, with clear control over what becomes public.
10. Zorgax and the Distribution of Technical Knowledge
Zorgax is part of our wider MyZubster experiment.
We want to investigate how it can help developers navigate technical procedures, understand documentation, inspect approved evidence and eventually discover useful guides created by other participants.
Our vision is that developers should not have to reinvent every configuration procedure independently.
If Nicola completes a reproducible Docker experiment, we should be able to document the process.
If another developer reproduces that experiment, they should be able to compare the instructions with their own results.
If we successfully test a PGP verification workflow, we should publish the procedure, including its failure cases and security limitations.
This is how knowledge can circulate throughout an open-source community.
At the same time, Zorgax must not become a shortcut around security.
An AI assistant should not automatically gain access to wallets, private keys, shell commands or publication permissions merely because a user requests an operation in natural language.
For critical actions, our roadmap requires appropriately scoped authorization and explicit human approval.
11. How We Intend to Publish Our Development Guides
We want our documentation to evolve alongside the software.
Whenever we complete a meaningful technical milestone, we intend to publish a corresponding guide.
A useful guide should include:
- The objective of the experiment.
- Required software and compatible versions.
- A description of the environment.
- Installation and configuration instructions.
- Reproducible test commands.
- Expected results and known failure conditions.
- Security considerations.
- Relevant GitHub commits and source files.
- Evidence of successful testing.
- Remaining limitations and future development tasks.
Where appropriate, we can also attach a cryptographic digest or digital signature to the resulting documentation.
This approach creates two different outcomes from the same development activity.
First, we improve the software itself.
Second, we create technical knowledge that can be independently studied, repeated and shared.
The knowledge record becomes a product of the development process rather than an unsupported claim made afterward.
12. What Comes Next?
Our immediate priority is completing the secure connection between the MyZubster VPS bridge and Nicola's independent local installation.
The server-side prototype is running and has passed its initial local request-response test.
The next milestones are:
- Review and configure HTTPS without exposing the internal bridge port.
- Test the bridge's security controls and failure behavior.
- Prepare Nicola's opt-in local connector.
- Demonstrate an actual exchange between the two separate machines.
- Document the complete process as a reproducible Docker guide.
- Continue the independent cryptographic verification experiments.
- Develop isolated PGP and Monero prototypes.
- Investigate additional Onion connectivity and resilience tests.
Only after these steps will we consider broader integrations.
We want to build gradually, document failures as well as successes, and keep experimental functionality separate from production services.
Conclusion: Decentralizing Infrastructure and Knowledge
Our ambition is not simply to connect computers.
We want to connect independent developers through software, documented activities and shared technical knowledge.
By experimenting with Docker, independent nodes, Tor, Monero, PGP, GitHub and cryptographic verification, we are exploring how a collaborative open-source project could support more transparent professional portfolios.
Every developer should have the opportunity to demonstrate what they have built, explain what they have learned and share the technical processes that helped them achieve those results.
A verifiable CV cannot depend on cryptography alone.
It needs reproducible technical evidence, accurate attribution, transparent limitations and the participation of the people involved.
That is the direction we are exploring with MyZubster.
We are still building it.
And as we build, we intend to publish the knowledge so that others can experiment with us.
Explore Our Work
MyZubster open-source ecosystem
https://github.com/MyZubster-Ecosystem/myzubster
Nicola's MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Our independent-node pilot architecture
Our Monero, PGP and cryptographic testing roadmap
Our collaboration documentation and review
https://github.com/MyZubster-Ecosystem/myzubster/pull/1434
Daniel's published Knowledge Card
https://www.myzubster.com/knowledge-card?id=6abf47c9a01a7570c0f26f36
Written by Daniel Ioni about ongoing MyZubster development and collaboration with Nicola. Proposed future milestones are distinguished from completed tests. Individual knowledge-transfer claims and shared results remain subject to participant review.
Top comments (0)