Coder Legion - Recent posts tagged tor

MyZubster: From GitHub Contributions to a Decentralized Marketplace of Skills, Projects and nodes

Sun, 18 Oct 2026 04:06:19 +0000

MyZubster: From GitHub Contributions to a Decentralized Marketplace of Skills, Projects and Independent Nodes

An open-source ecosystem connecting developers, AI, verifiable contributions, real-world services and independently operated infrastructure.

What if your GitHub work could become part of something bigger?

Developers create incredible things every day.

We publish repositories, fix bugs, build APIs, improve documentation, experiment with AI and contribute to projects around the world.

But there is a problem.

Our skills, contributions, projects and opportunities are often scattered across disconnected platforms.

A developer might have a strong GitHub profile but no simple way to present their services.

A freelancer might have valuable skills but little visibility within open-source communities.

An independent project might have working software but no straightforward way to collaborate with other projects.

MyZubster is an open-source experiment designed to connect these worlds.

We're building an ecosystem where people can contribute code, document their skills, offer services, connect independent projects and explore decentralized infrastructure.

And we're inviting developers and creators to help build it.

Explore the project:

Website: https://www.myzubster.com/
GitHub: https://github.com/MyZubster-Ecosystem/myzubster
Marketplace: https://www.myzubster.com/community-marketplace.html

1. MyZubster Is More Than a Marketplace

Our vision connects several components.

Marketplace — A place where people can offer services, creative work, technical expertise and other legitimate listings.

GitHub — The development environment where contributors collaborate, review code and document their work.

Zorgax — An AI component intended to help users navigate information, document projects and explore opportunities.

Contributor Passport — An evolving approach to linking skills and contributions with supporting evidence.

Knowledge Graph — A way to describe relationships between people, projects, software, knowledge and documented work.

Independent Nodes — Experiments with Docker, Tor Onion services and contributor-operated infrastructure.

LIFE Projects — Real-world initiatives involving communities, creative work, resource sharing and local activities.

DAO-Inspired Governance — An exploration of how contributors could share decisions, responsibilities and maintenance.

These components are at different stages of development. MyZubster is an evolving MVP, not a fully completed decentralized network.

The challenge is to make them useful together.

2. Developers: Turn Your Skills Into Real Opportunities

Imagine you are a Python developer.

You contribute to a repository, fix a bug or create an API integration.

That work can help demonstrate your technical abilities.

But what happens next?

You might want to offer API development, automation, testing or technical consulting.

The MyZubster Marketplace is designed to help connect skills with services.

What could you list?

Python, JavaScript or Node.js development
Website and application development
AI integrations and automation
Docker and Linux support
API design and integrations
UI/UX design
Open-source documentation
Creative services and digital art
Technical tutoring and consulting
Local services or equipment rental

You don't need to be a professional developer to explore the Marketplace.

Artists, designers, makers, freelancers and local community members can also participate.

The idea is simple: your skills should be useful beyond your profile page.

Creating a listing does not guarantee sales, and the platform is still being tested and improved.

Explore the Marketplace:

https://www.myzubster.com/community-marketplace.html

3. Connect Your GitHub Contributions to Your Skills

GitHub is one of the most important entry points into MyZubster.

We want to explore a model where a contributor's public work can support a more meaningful representation of their abilities.

Consider this example:

A developer creates a Docker integration.

The integration is submitted through a pull request.

The code receives review, automated tests and documentation.

That contribution can then become part of a documented history of work.

Our proposed Contributor Passport model follows a structure like:

Identity → Contribution → Evidence → Skills → Recognition

A contribution record might include a repository link, pull request, test results and review status.

This is not automatic certification.

It is a way to make specific work more transparent and easier to discover.

We also want contributors to retain control over what information they choose to make public.

4. How to Contribute to MyZubster on GitHub

You don't need to understand the entire ecosystem before making your first contribution.

Start small.

Step 1 — Explore the repository

Visit:

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

Read the README and explore the project structure.

Step 2 — Choose your area

You can contribute to:

Frontend and Marketplace UX
Backend and API development
Automated testing
AI and Zorgax integrations
Docker and infrastructure
Tor Onion experiments
Documentation and onboarding
Knowledge Graph interfaces
Accessibility and translations

Step 3 — Find an existing issue

Look for a task that matches your experience.

Read the discussion to check whether someone is already working on it.

Introduce yourself and explain what you would like to contribute.

Step 4 — Fork, build and test

Create your own development branch.

Make a focused change.

Document what you changed and how it can be tested.

Step 5 — Open a pull request

Submit the change for review.

Include reproducible test evidence whenever possible.

The goal is not simply to produce more code.

It's to produce useful, maintainable and verifiable contributions.

Choose a contribution path:

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

Participation is voluntary. Contributions do not automatically qualify for payment, governance membership or infrastructure access.

5. Zorgax: Making the Ecosystem Easier to Navigate

Open-source ecosystems can become complicated.

Repositories, documentation, APIs, discussions and contribution histories are not always easy to understand.

Zorgax is the AI component of MyZubster.

Our direction is to use AI to help people understand information and participate more effectively.

Potential applications include:

Explaining technical documentation
Helping newcomers identify suitable tasks
Organizing project knowledge
Drafting descriptions of skills and services
Supporting technical learning
Assisting with contributor onboarding

AI should help people interpret evidence, not invent credentials or exaggerate experience.

We want useful assistance grounded in real work.

Explore Zorgax:

https://www.myzubster.com/zorgax

6. Knowledge Graph: Connecting Contributions to Real Projects

A repository tells us where code lives.

A Knowledge Graph can help us understand relationships.

Imagine these connections:

A developer builds an API.

The API supports an independent project.

That project generates documented results.

Another contributor uses those results to create a service.

A marketplace listing offers that service to a community.

The graph could connect the relevant contributors, repositories, projects and evidence.

This is especially interesting for open-source communities where knowledge is distributed across many independent participants.

The objective is to improve discoverability and traceability, not to claim that every linked piece of information has been independently verified.

7. Decentralization: What Happens When Contributors Run Their Own Nodes?

This is one of the most interesting technical directions in MyZubster.

We are exploring how independently operated services could interoperate without requiring every contributor to place their project on one central server.

The technologies involved include:

Docker and Docker Compose
Tor v3 Onion services
HAProxy
Independent service environments
API integrations
Reproducible testing
Service resilience and recovery

The main Docker Compose stack includes a Tor Onion service that can generate and persist an Onion identity.

This provides a foundation for contributor-operated experiments.

Why does this matter?

Imagine two developers operating different environments.

One maintains a creative catalog.

Another maintains an integration service.

They want to exchange selected information while keeping control of their own systems.

Instead of moving everything into one repository or one VPS, they can explore documented interfaces between independent services.

What has been tested?

MyZubster contributors have documented local interoperability tests and an isolated static Tor Onion pilot.

Work involving Nicola's N4K48 project and Wasim's testing efforts is helping investigate how these connections can operate.

But there are important limits.

A local test does not prove production readiness.

A Tor Onion address does not automatically prove that a service is available.

A connection through a central broker is not yet a fully independent peer-to-peer federation.

We're working toward stronger evidence through independent verification, recovery testing and documented network boundaries.

Technical discussion:

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

Independent node registry:

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

8. Independent Projects: Bring What You've Already Built

You don't need to abandon your own project to join MyZubster.

In fact, independent ownership is part of the vision.

If you already maintain software, a creative initiative, a local community project or a technical experiment, you can propose a connection.

For example:

A developer: Maintains an open-source application and explores an API integration.

An artist: Documents creative work and offers related services through the Marketplace.

A community organizer: Connects a local initiative with shared resources and public documentation.

A researcher or maker: Links project evidence, experiments and technical knowledge.

A Docker enthusiast: Tests a contributor-operated service in an isolated environment.

Not every integration is available today.

The first step is to discuss a small, realistic pilot with clear expectations.

A decentralized ecosystem cannot depend forever on one person making every decision, paying every infrastructure bill and reviewing every contribution.

We are exploring a governance model where participants can voluntarily take responsibility for specific areas.

For example:

Maintaining a component
Reviewing technical contributions
Operating a node
Documenting a pilot
Coordinating a community activity
Proposing improvements
Helping verify technical evidence

We want responsibility to be distributed alongside knowledge.

This governance model is still being developed.

Joining the GitHub repository does not automatically make someone a DAO member, require financial contributions or guarantee a governance role.

Our immediate priority is simpler: help people take ownership of manageable, clearly defined tasks.

10. Payments, Monero and Sustainability

Open-source development also raises economic questions.

How can contributors be supported?

How can independent infrastructure remain sustainable?

How can services generate value for the people offering them?

MyZubster is exploring conventional payment methods alongside privacy-conscious cryptocurrency options, including Monero.

We are also discussing internal MYZ accounting and potential contributor reward mechanisms.

However, proposed rewards are not guaranteed payments.

Funding, settlement conditions and responsibilities must be confirmed explicitly.

The long-term goal is to explore an ecosystem where useful services can generate economic activity that helps sustain maintenance and infrastructure.

This is an economic hypothesis we still need to validate through real usage and verified transactions.

11. Real-World Use Cases: Beyond Software

MyZubster also explores how digital infrastructure could support real-world communities.

Our LIFE-oriented pilot directions include:

Community resource exchange

Sharing resources, such as kefir cultures, and documenting practical knowledge.

Urban gardening

Recording gardening activities, practical experience and potentially environmental sensor data.

Creative communities

Supporting artists, music groups and independent cultural projects.

Open knowledge

Connecting documentation, software contributions and evidence from community-led experiments.

These initiatives illustrate potential applications. Their technical and organizational maturity varies.

The point is to test whether open-source tools can solve practical problems for people outside the software industry.

12. Five Ways to Join MyZubster

You can participate without running a server or making a financial commitment.

1. Create a Marketplace listing

Offer a skill, service or creative product.

https://www.myzubster.com/community-marketplace.html

2. Contribute on GitHub

Explore issues, improve documentation, fix bugs or submit code.

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

3. Connect your independent project

Introduce your repository, application or community initiative and discuss a small interoperability pilot.

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

4. Help test independent infrastructure

If you know Docker, Linux, Tor or networking, help improve our experimental node architecture.

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

5. Share knowledge and feedback

Help make the ecosystem easier to understand, use and maintain.

You don't need to be a senior engineer to make a useful contribution.

13. What We Want to Prove Next

Our next challenges are practical.

Can new users publish useful Marketplace listings?

Can developers complete meaningful contributions without constant assistance from the original maintainers?

Can two independently operated services exchange information reliably?

Can knowledge and contribution records remain useful across projects?

Can the ecosystem eventually cover its operating costs through real economic activity?

These questions will not be answered by architecture diagrams alone.

They require users, contributors, testing and evidence.

That's why we're inviting people to join now.

Let's Build a More Connected Open-Source Ecosystem

MyZubster is still growing.

We're not claiming to have completed a decentralized internet, a production DAO or a self-sustaining digital economy.

We're building and testing the components that might make a more collaborative, interoperable ecosystem possible.

If you are a developer, designer, creator, freelancer, researcher or independent project owner, we'd like to hear from you.

Bring your skills. Bring your GitHub. Bring your project. Start small.

Join MyZubster

🌐 Website: https://www.myzubster.com/

🛒 Marketplace: https://www.myzubster.com/community-marketplace.html

🤖 Zorgax: https://www.myzubster.com/zorgax

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

🤝 Contributor opportunities: https://github.com/MyZubster-Ecosystem/myzubster/issues/1622

🧅 Independent node experiments: https://github.com/MyZubster-Ecosystem/myzubster/issues/1623

Question for the CoderLegion community:

If you could connect your GitHub work, technical skills and independent projects to an open-source marketplace, what would you build or offer first?

Share your ideas in the comments.

#OpenSource #GitHub #Developers #Docker #AI #Decentralization #Marketplace

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

Sat, 17 Oct 2026 07:22:23 +0000

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

From an open-source marketplace to a network of independent services. One step at a time.

Hey Coder Legion community! 👋

We've reached a new technical milestone with MyZubster, our open-source ecosystem focused on connecting people, projects, knowledge, and independent infrastructure.

We recently deployed our first experimental Tor v3 Onion Service using Docker and HAProxy.

🚀 What works so far?

✅ Tor successfully bootstrapped to 100%
✅ A dedicated Onion v3 identity was generated
✅ An isolated HAProxy service serves our experimental page
✅ Docker networks separate the pilot from production services
✅ The test proxy returns HTTP 404 for /api and /admin
✅ The experimental page was displayed during testing

Our architecture:

Tor Browser
     ↓
Tor v3 Onion Service
     ↓
Isolated HAProxy
     ↓
MyZubster Pilot Page

Important: This is an experimental proof of concept, not a production-ready or independently audited service. Marketplace, Zorgax, wallets, and payment systems are not part of this pilot.

🌍 Why are we building this?

We want MyZubster to evolve into an ecosystem where contributors can:

Connect independent open-source projects.
Host services on their own infrastructure.
Share verifiable technical knowledge.
Build interoperable tools.
Participate in community-driven governance.
Explore privacy-conscious access through Tor.

We believe decentralization should be demonstrated through working infrastructure, not just promises.

👨💻 What's next?

We're collaborating with our contributor community, including @wasim-builds, on the next proposed development phase:

🔹 Reproducible Docker Compose deployment
🔹 Tor and HAProxy resilience testing
🔹 Network isolation and security documentation
🔹 Independent code reviews
🔹 Better monitoring and recovery procedures

🤝 Developers wanted!

Are you interested in Docker, Tor, cybersecurity, privacy, distributed systems, or open-source collaboration?

You can contribute through documentation, testing, code review, or pull requests.

No VPS or DAO membership is required to get started.

Explore the project:

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

🧅 Tor Pilot Discussion: https://github.com/MyZubster-Ecosystem/myzubster/issues/1584

🌐 Website: https://www.myzubster.com/

Let's build independent infrastructure together, one verified component at a time.

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

Thu, 15 Oct 2026 05:27:32 +0000

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

What happens when an open-source marketplace starts evolving into a network of independently operated nodes?

That's what we're exploring at MyZubster.

We're working toward an ecosystem where developers, creators, researchers, and independent communities can connect their projects, share verifiable knowledge, demonstrate their skills, and eventually operate their own infrastructure.

Our long-term goal is to reduce dependence on a single server, administrator, or infrastructure provider.

Two contributors are helping us explore this transition: Nicola (N4K48) and Wasim (@wasim-builds).

Their work approaches decentralization from two complementary directions.

1. Nicola N4K48 — Independent Node Experiments

Nicola is experimenting with an independently managed Docker-based node connected to the wider MyZubster ecosystem.

His work involves:

Docker-based services and local agents
Independent digital catalogs
Interoperability between contributor projects
Verifiable technical evidence
Creative content and NFT provenance experiments
Authenticated connectivity testing

A previous authenticated checkpoint between the MyZubster VPS and the N4K48 node was reported as successful.

Following credential rotation, the agent has remained offline pending authorization for any further authenticated tests.

The objective is to demonstrate that contributors can maintain control of their projects while connecting to shared services.

Nicola's work on GitHub

2. Wasim — Tor, Docker, Security and Interoperability

While Nicola is experimenting with an independent node, Wasim is designing and reviewing components that could make independently operated infrastructure more secure and reproducible.

Tor Onion + HAProxy + Docker

Wasim has prepared a technical design for a Docker-based architecture involving Tor Onion connectivity and HAProxy.

The proposal covers:

Network architecture and trust boundaries
Threat modeling
Isolated Docker environments
Reproducible tests
Rollback procedures
Security evidence
Infrastructure resilience

His reported tests were performed locally without exposing host ports, using production credentials, or requiring additional VPS resources.

The design is still under review. It has not been deployed as a production service.

GitHub:

Pastebin → GitHub → Zorgax

Wasim is also working on a proposed evidence-ingestion architecture.

The idea is to connect external technical information to MyZubster's knowledge system while preserving provenance and security.

The design includes HTTPS restrictions, redirect blocking, protection against internal-network requests, deterministic rejection tests, and mandatory human review.

The proposed evidence schema is:

myzubster.knowledge.evidence.v1

GitHub:

CI Reliability and Hardhat 3

Wasim has also participated in troubleshooting GitHub Actions workflows and reviewing the migration to Hardhat 3.

This includes work involving security audits, automated tests, dependency compatibility, and evidence checks.

Wasim also reviewed privacy protections for the Contributor Passport:

Contributor Passport Privacy Gate — PR #1599

3. The Architecture We're Exploring

                 MyZubster Ecosystem
                         |
             Shared Interoperability
                         |
          +--------------+--------------+
          |              |              |
     N4K48 Node     Future Node    Future Node
          |              |              |
     Docker/Agent    Tor/HAProxy     Independent
     Local Catalog   Docker          Application
          |              |              |
          +--------------+--------------+
                         |
                    Zorgax APIs
                         |
                Knowledge Evidence
                         |
                Contributor Passport
                         |
                    Marketplace
                         |
                  DAO Governance

This is a conceptual architecture, not an operational production federation. Wasim's infrastructure remains a design proposal.

We want independent contributors to be able to connect services without giving up ownership or control of their infrastructure.

The challenge is not simply connecting containers.

It's designing a system where interoperability, security, evidence, identity, and governance work together.

4. Why Decentralization Matters to Us

Today, many open-source projects depend heavily on a single maintainer.

That person may be responsible for:

Hosting costs
Infrastructure maintenance
Security
Deployment
Community coordination
Funding
Contributor management

This creates a technical and organizational single point of failure.

Our objective is to explore a different approach.

Independent contributors could eventually operate their own services, maintain their own environments, and communicate through documented interfaces.

This could reduce centralized infrastructure dependencies and distribute operational responsibility.

However, we have not yet demonstrated a stable production federation or fully decentralized governance.

We're building toward those goals through smaller, reproducible experiments.

5. From Technical Collaboration to a Contributor DAO

We're also exploring how a DAO-inspired governance structure could help distribute responsibilities, costs, decisions, and rewards.

The goal is not to introduce tokens without a purpose.

We want contributors to have transparent ways to demonstrate their work, participate in decisions, and potentially benefit economically from the value they create.

This requires careful work on governance, funding, accountability, and dispute resolution.

Relevant discussions:

These are ongoing proposals, not claims that a fully functioning DAO already exists.

6. What's Working, and What's Next?

Documented so far:

Local Docker and agent tests
An authenticated N4K48 node checkpoint
GitHub contributions and code reviews
Hardhat 3 migration review
Contributor Passport privacy review
Isolated Tor/HAProxy design experiments

Still under development:

Independent reproducibility reviews
Secure interoperability between multiple nodes
Production-grade resilience and failover
Shared governance procedures
Sustainable contributor funding
A fully operational federated network

Our approach is simple:

Propose → Implement → Test → Verify → Document → Improve.

We believe open-source infrastructure should be built around reproducible evidence rather than promises.

7. Developers: Want to Contribute?

We're looking for developers interested in:

Docker and container infrastructure
Tor and network resilience
Node.js and APIs
Security and CI/CD
Decentralized architectures
Knowledge graphs
Privacy and identity
Open-source governance
Reproducible technical experiments

You don't need to rent a VPS or pay for infrastructure to start contributing.

A code review, reproducible local test, documentation improvement, or security assessment can be valuable.

Explore the project

MyZubster

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

https://myzubster.com

Nicola N4K48

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

Wasim

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

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

Decentralization roadmap

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

Final Thoughts

Nicola is helping us explore how an independent contributor project can operate as a node.

Wasim is helping us design the infrastructure and verification processes that could make such nodes more secure, reproducible, and resilient.

Together, these efforts are moving MyZubster toward a model where independent developers can collaborate without depending entirely on centralized infrastructure.

We still have important technical and organizational challenges to solve.

But the work is happening openly, through GitHub issues, pull requests, reviews, and documented experiments.

We're not just trying to connect servers. We're trying to connect independent people, projects, skills, and verifiable knowledge.

If you're interested in contributing, reviewing the architecture, or experimenting with an independent node, join the discussion on GitHub.

Daniel Ioni (h4x0r)
Creator & Administrator — MyZubster Ecosystem

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source

Sat, 10 Oct 2026 04:14:28 +0000

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source Contributors

Docker • Tor • Node.js • React • Nginx • Privacy • Open Source

We're taking an exciting new step in the development of MyZubster: working toward making our ecosystem accessible through the Tor network using a .onion address.

Alongside our traditional website, we want to provide an alternative access path designed with privacy, infrastructure isolation, and reliability in mind.

And we're building it with the help of independent open-source contributors.

👨💻 Recognizing Our Contributors

A special thank you to Wasim (@wasim-builds) and Nicola (N4K48) for their contributions to MyZubster's evolving infrastructure.

Wasim is developing and refining changes involving our Docker setup, backend services, frontend infrastructure, and Tor integration.

🔗 Wasim's contribution — PR #1582:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🔗 Wasim's GitHub:
https://github.com/wasim-builds

Nicola's earlier N4K48 contribution forms an important foundation for the work now being reviewed and tested.

🔗 Nicola / N4K48 — Original PR #1457:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

This is what makes open source valuable: contributors bringing independent ideas, improving each other's work, and helping transform experiments into reliable infrastructure.

🌐 What Are We Building?

We're developing a Docker-based Tor Onion Service that would allow users to access the MyZubster frontend through Tor Browser.

The intended architecture is:

        User with Tor Browser
                 |
             Tor Network
                 |
          .onion Address
                 |
         Tor Onion Service
                 |
       Internal Docker Network
                 |
          Nginx + React
                 |
          Node.js Backend
                 |
              MongoDB

The idea is to provide an alternative entry point without directly exposing backend or database services.

Our goal is not simply to generate an Onion address. We want the entire access path to be reliable, maintainable, and carefully reviewed.

✅ What We've Already Tested

We've been validating PR #1582 on an isolated VPS using dedicated Docker containers and internal networking.

Here are some of the results:

Backend and APIs

✅ Node.js backend successfully built and started after a local middleware import correction.

✅ MongoDB connectivity verified.

✅ Health, Ledger, and Economics API tests passed.

✅ Seven targeted authentication and authorization tests passed.

Frontend and Nginx

✅ React production build completed successfully.

✅ Frontend Docker image built.

✅ Nginx configuration validated.

✅ Homepage returned HTTP 200.

✅ React SPA fallback worked.

✅ Nginx successfully proxied Ledger API requests to the backend.

Tor and Onion Infrastructure

✅ Tor Docker image built successfully.

✅ Tor 0.4.9.11 installed and verified.

✅ Dedicated non-root Tor user and filesystem permissions tested.

✅ Frontend reachable from the isolated Onion test container with HTTP 200.

✅ A candidate fix for Tor's Docker hostname configuration issue passed static validation.

These are actual results from our isolated test environment, not claims of a completed public launch.

🔍 An Interesting Challenge We Discovered

The original Onion configuration used the Docker service hostname directly:

HiddenServicePort 80 frontend:80

During testing, Tor rejected the configuration:

Unparseable address in hidden service port configuration.

We reproduced the issue and tested a candidate solution using Docker DNS resolution.

The frontend hostname was resolved to its internal container IP before generating the Tor configuration.

The modified configuration passed validation.

But there's an important challenge:

Docker container IP addresses can change when services are recreated.

If Tor uses an address resolved only once at startup, it may later point to the wrong destination.

This is one of the areas where feedback from experienced infrastructure developers would be especially valuable.

🛠️ What We Still Need to Complete

Before a public Onion deployment, several tasks remain:

Integrate the tested backend middleware import fix into PR #1582.
Make Tor destination resolution resilient to Docker container restarts and IP changes.
Improve service readiness and Tor health checks.
Remove frontend build instructions that can conceal compilation failures.
Test real connectivity over the Tor network in a controlled environment.
Verify browser behavior, privacy boundaries, and end-to-end integration.
Complete security review before any production deployment.

Our Onion Service is not publicly launched or fully validated yet.

We're documenting what works, what doesn't, and what we're learning along the way.

🤝 Calling Developers Who Want to Contribute

We're particularly interested in connecting with developers experienced in:

Tor Onion Services, Docker Compose, Linux infrastructure, Node.js, React, Nginx, service discovery, and application security.

Here's a question for the community:

How would you design a reliable Tor Onion Service behind Docker when the frontend container's IP address may change?

Would you use a local reverse proxy, a service-discovery mechanism, automatic configuration reloads, or a different architecture?

We'd love to hear about approaches you've implemented or tested.

🚀 Join the MyZubster Open-Source Journey

We're building an ecosystem where contributors can experiment, review each other's ideas, and improve real infrastructure together.

Explore the project:

🌐 Website: https://www.myzubster.com/

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

🔧 Active contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🧩 Original N4K48 contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

Thank you again to Wasim and Nicola for their work and willingness to contribute to the ecosystem.

We're not announcing a finished Onion deployment.

We're inviting the developer community to help us build one properly.

Because open source grows through collaboration, evidence, and shared progress.

MyZubster — Building together, testing together, growing together.

OpenSource #Tor #Docker #Privacy #NodeJS #React #Linux #WebDevelopment

TTP 0.4.8 - transparent Tor proxy for Linux, and the leak tests that were passing for the wrong reas

Fri, 11 Sep 2026 17:08:48 +0000

I maintain TTP, a Linux CLI that routes system TCP and DNS through Tor using nftables. That part isn't novel - kalitorify, nipe and others do it.

What I want feedback on is the verification, because I found my own test suite was lying to me.

assert len(leaks) == 0 is also true when the sniffer never started, when the interface name was wrong, or when the traffic never left the process. It passes whether or not the firewall works. So every containment test now runs its stimulus twice: once with the ruleset flushed, where the packet MUST be captured, and then with the ruleset loaded, where it must not. A harness that cannot see a leak now fails instead of passing.

Ten tests, each in an ephemeral network namespace: DNS over UDP and TCP, plain TCP, DoT on 853, QUIC DoH on UDP/443 (the path NAT redirection can't touch), ICMP, arbitrary UDP, IPv6 - plus the reverse assertion that a bypassed UID still reaches the LAN, so a firewall that blocked everything couldn't pass either.

Doing this broke things, which is the point. Tightening the probes turned three passes into failures: nftables reject returns EPERM to the local socket, so a refused send was the firewall working correctly and I had been reading it as a broken test.

Caveat up front: this is not Whonix and not Tails. Transparent proxying routes connections; it does nothing about browser fingerprints, TLS client hellos, or any application-layer identifier. If your threat model is a state adversary, use Tails.

Code: https://github.com/onyks-os/TransparentTorProxy
Docs: https://onyks-os.github.io/ttp/

Tell me what else in there could pass without being true.

Coder Legion - Recent posts tagged tor

MyZubster: From GitHub Contributions to a Decentralized Marketplace of Skills, Projects and nodes

MyZubster: From GitHub Contributions to a Decentralized Marketplace of Skills, Projects and Independent Nodes

What if your GitHub work could become part of something bigger?

1. MyZubster Is More Than a Marketplace

2. Developers: Turn Your Skills Into Real Opportunities

What could you list?

3. Connect Your GitHub Contributions to Your Skills

4. How to Contribute to MyZubster on GitHub

Step 1 — Explore the repository

Step 2 — Choose your area

Step 3 — Find an existing issue

Step 4 — Fork, build and test

Step 5 — Open a pull request

5. Zorgax: Making the Ecosystem Easier to Navigate

6. Knowledge Graph: Connecting Contributions to Real Projects

7. Decentralization: What Happens When Contributors Run Their Own Nodes?

Why does this matter?

What has been tested?

8. Independent Projects: Bring What You've Already Built

9. DAO-Inspired Governance: Sharing the Work

10. Payments, Monero and Sustainability

11. Real-World Use Cases: Beyond Software

12. Five Ways to Join MyZubster

13. What We Want to Prove Next

Let's Build a More Connected Open-Source Ecosystem

Join MyZubster

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

🚀 What works so far?

🌍 Why are we building this?

👨💻 What's next?

🤝 Developers wanted!

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

1. Nicola N4K48 — Independent Node Experiments

Nicola's work on GitHub

2. Wasim — Tor, Docker, Security and Interoperability

Tor Onion + HAProxy + Docker

Pastebin → GitHub → Zorgax

CI Reliability and Hardhat 3

3. The Architecture We're Exploring

4. Why Decentralization Matters to Us

5. From Technical Collaboration to a Contributor DAO

6. What's Working, and What's Next?

7. Developers: Want to Contribute?

Explore the project

Final Thoughts

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source Contributors

👨💻 Recognizing Our Contributors

🌐 What Are We Building?

✅ What We've Already Tested

🔍 An Interesting Challenge We Discovered

🛠️ What We Still Need to Complete

🤝 Calling Developers Who Want to Contribute

🚀 Join the MyZubster Open-Source Journey

OpenSource #Tor #Docker #Privacy #NodeJS #React #Linux #WebDevelopment

TTP 0.4.8 - transparent Tor proxy for Linux, and the leak tests that were passing for the wrong reas