Coder Legion - Recent posts tagged decentralization

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

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: Building a Decentralized Future

Sun, 04 Oct 2026 08:58:01 +0000

From Two Developers to a National Digital Network: Can We Build an Internet That Belongs to Its Participants?

How MyZubster is exploring independent nodes, local AI, verifiable knowledge, digital identity and a new model of technological cooperation.

By Daniel Ioni — MyZubster Open Ecosystem

An ongoing collaboration with Nicola / N4K48

What if we stopped building platforms and started connecting independent people?

For years, the technology industry has encouraged us to build bigger platforms.

More users. More data. More centralized infrastructure.

Every successful platform promises convenience, integration and a better experience.

But there is a fundamental question we rarely ask:

What happens to our independence when our entire digital existence depends on infrastructure controlled by someone else?

As developers, we have become extremely good at connecting applications to centralized services.

Perhaps our next challenge should be connecting independent applications to each other.

That is the idea behind our current MyZubster experiment.

I am Daniel Ioni, and together with an independent developer named Nicola, also known as N4K48, I am investigating how personally controlled software can become part of a wider digital ecosystem.

Our experiment began with two independent environments.

I operate the MyZubster infrastructure on a VPS.

Nicola develops his own software on a separate Windows computer.

We have built a Node Bridge designed to exchange selected information between these environments without requiring Nicola to expose his complete local application to the public Internet.

The updated Bridge is already deployed and tested on the VPS.

Our next milestone is the authenticated end-to-end connection with Nicola's actual computer.

But while building this connection, we began asking a much more ambitious question.

Could an experiment involving two developers eventually provide useful lessons for building a nationwide network of independent digital services?

Not a single platform controlling everything.

A federation connecting independently operated systems.

Here is what such a future would require.

1. Decentralization without interoperability is just fragmentation

Imagine a country with thousands of independent servers.

Every university has a node. Every association has another. Municipalities operate their own infrastructure. Developers maintain independent applications.

It sounds decentralized.

But what happens if none of these systems can communicate?

We have not built an ecosystem. We have created thousands of isolated islands.

This is why open standards must come first.

A future federated MyZubster architecture should investigate compatibility with established approaches for decentralized identity, verifiable credentials and interoperable data exchange.

Public, versioned APIs would allow third-party developers to implement compatible services without depending on our original codebase.

Existing European digital identity initiatives are particularly relevant.

Interoperability with the European Digital Identity Wallet, eIDAS and appropriate national identity systems deserves investigation.

However, our current experimental software has not demonstrated that compatibility.

Supporting a standard requires actual implementation, conformance testing and, where applicable, regulatory assessment.

The broader principle is straightforward:

An ecosystem becomes meaningful when its participants can leave, migrate and still communicate.

If users cannot move between compatible services, decentralization becomes another marketing term.

2. Our first practical experiment: the Node Bridge

Large technological transformations need small, testable beginnings.

Our beginning is a connection between two independently managed computing environments.

The MyZubster VPS runs a Docker-based broker behind Nginx and an HTTPS endpoint.

Nicola's environment contains his experimental software, local database components and AI-related services.

A lightweight Python agent is designed to initiate outbound communication with the VPS.

It retrieves authorized requests, processes them through Nicola's local application and returns limited results.

This architecture means we do not need to expose his entire local development API directly to the Internet.

But building the first version revealed an important problem.

Our broker used temporary job assignments. When an assignment expired, the request could be offered to another agent.

Unfortunately, an outdated agent could still submit a result associated with its expired assignment.

We reproduced this behavior and corrected it by requiring a unique identifier for every assignment.

An outdated result is now rejected rather than accepted as the result of the current operation.

Our corrected implementation passed automated regression tests and an integration test inside a separate Docker deployment.

We updated the production broker on the VPS and subsequently rotated its credentials.

The next step is completing the real authenticated connection with Nicola's computer.

Notice what this experience teaches us.

A distributed system is not simply an application running on multiple computers.

It must handle delays, disconnections, retries, outdated information and conflicting operations.

If we cannot solve these problems for two independent environments, we have no credible foundation for discussing thousands of nodes.

3. Local AI could change who controls information

Artificial intelligence will influence almost every digital service.

But that does not necessarily mean all information must be transferred to a remote AI provider.

Nicola's independent project explores an alternative.

His experimental MyZubster MVP uses technologies including Ollama and Qdrant to support locally executed AI and retrieval-augmented generation.

Its underlying philosophy is evidence-first development.

The application should distinguish between an exact stored observation and a plausible AI-generated answer.

This becomes especially important when AI participates in education, professional workflows or public services.

Imagine a federation in which participants maintain appropriate datasets locally.

An independent node could answer a permitted question or provide an authorized service without necessarily transferring its entire underlying database.

Some operations might still require cloud services. Others could remain local.

The important innovation would be having a meaningful choice.

However, running AI locally does not automatically establish privacy, security or regulatory compliance.

Those properties must be designed and evaluated independently.

4. What about Tor?

Our broader infrastructure experiments also include Tor.

That creates an opportunity to investigate different communication paths for independent services.

Tor onion services can provide network privacy properties that differ from conventional Internet hosting.

But we should avoid mixing concepts.

Tor is not synonymous with decentralization.

HTTPS is not equivalent to anonymity.

And an encrypted connection is not automatically an authorized connection.

Our currently verified Node Bridge communicates through conventional HTTPS.

A dedicated onion transport for the complete Nicola connection remains a possible future experiment, not a completed technical result.

In a mature federation, alternative communication methods could improve flexibility and potentially resilience.

Every method would need an appropriate threat model, security testing and clear operational documentation.

The objective should be practical autonomy, not technological mysticism.

5. Digital identity must become portable

Today's digital identity is often fragmented across commercial platforms.

People maintain different profiles, credentials and records of their achievements.

Organizations face similar problems.

A federated digital ecosystem could investigate ways to improve identity portability and selective information sharing.

Decentralized identifiers and verifiable credentials offer relevant technical approaches.

But adopting these technologies responsibly requires much more than creating a wallet or issuing a token.

Identity recovery matters.

Credential revocation matters.

Fraud prevention matters.

Privacy matters.

Legal responsibility matters.

A citizen should not be expected to become a cryptography expert merely to use a digital service.

If this model is ever to become widely adopted, its user experience must compete with the convenience offered by centralized applications.

That means accessible onboarding, appropriate recovery mechanisms, understandable permissions and reliable technical support.

It also means offering different participation models.

Some people may want to operate their own infrastructure.

Others may prefer services operated by trusted associations, cooperatives or professional providers.

Decentralization should expand people's choices rather than create a new technical barrier.

6. Can knowledge become independently verifiable?

This is one of the most interesting questions emerging from our collaboration.

When someone says they have learned a skill, how can they demonstrate their progress?

Traditional profiles rely heavily on self-description.

Repositories can provide useful evidence of development activity.

Technical reports can document methodology.

Tests can demonstrate specific software behavior.

Educational institutions can assess competence.

What if we could connect these different forms of evidence?

MyZubster is exploring a knowledge-proof approach built around inspectable records, versioned source material, cryptographic digests and acknowledged contributions.

Our work with Nicola has already contributed to a documented knowledge-transfer experiment with a recorded commitment on a blockchain test network.

That commitment can be used to verify the integrity of the corresponding evidence package.

However, this does not mean the blockchain has automatically certified someone's skills.

Cryptographic integrity and human assessment are different things.

An effective knowledge system would need both technical verification and appropriate evaluation.

Imagine a student who builds a working application, publishes its source code, documents its tests and receives an appropriate assessment from an authorized institution.

Imagine that the resulting portfolio could be accessed through compatible services without depending on a single educational platform.

That is the kind of long-term possibility worth researching.

7. Why our experiment also includes a comic

Technology is not experienced only through source code.

People understand complex ideas through stories, visual identities and creative expression.

During our collaboration, Nicola developed a series of illustrated chapters around his digital identity, N4K48.

The story follows his journey from an independent software idea toward the fictional cyberpunk environment of Neon Plaza.

Its fourth chapter is called The Bridge to Be Built.

It reflects the very real technical challenge we are currently addressing.

This creates an unusual connection.

The comic communicates the development journey.

The software repository records implementation work.

The test evidence documents verified technical behavior.

The knowledge records help connect the relevant information.

We are also exploring transparent provenance for digital creative work.

One original N4K48 comic is currently documented as a proposed NFT candidate.

It has not been minted, and relevant rights must be verified before any authorized commercial application.

The broader objective is not to tokenize everything.

It is to develop better ways of documenting creative work and connecting its history to appropriately verified records.

8. A nationwide ecosystem needs governance, not just servers

Suppose independent nodes become technically interoperable.

Who establishes common rules?

Who handles disputes?

What happens when participants publish illegal content, abuse shared services or dispute the validity of a credential?

These problems cannot be solved through server architecture alone.

A larger federation would need transparent governance.

One possible direction is a multi-stakeholder organization involving independent developers, users, educational institutions, civil society and participating service providers.

It could coordinate technical standards, develop shared policies and provide transparent processes for addressing disputes.

But governance must not become another mechanism for concentrating control.

Independent participants need meaningful representation.

Protocol decisions should be open to scrutiny.

Operators must remain accountable for their own legal obligations.

We want to investigate shared rules without recreating the same centralized dependencies that motivated the project.

9. There is no sustainable decentralization without an economy

Someone must pay for infrastructure.

Someone must maintain the software.

Someone must respond when security problems emerge.

Someone must create documentation, assist users and conduct independent assessments.

Open source is a development and licensing model, not a magical source of unlimited operational funding.

If MyZubster eventually expands beyond its laboratory stage, we will need a sustainable economic model.

Possible approaches include research grants, professional services, educational initiatives, managed infrastructure and partnerships around useful applications.

There is no requirement to launch a speculative token.

Any potential crypto-asset or payment-related feature would require a separate economic justification and appropriate regulatory analysis.

The best foundation for sustainability is demonstrable value.

If independent participants receive genuine benefits from interoperability, privacy choices and shared services, sustainable business and organizational models become easier to investigate.

10. The regulatory challenge

A national-scale ecosystem cannot operate outside legal responsibility.

Its architecture would need to account for applicable data-protection obligations, digital identity requirements, AI regulation and other rules relevant to the services it actually provides.

The GDPR, European AI Act, eIDAS framework and potentially MiCA are among the areas requiring professional assessment when their respective conditions apply.

Creative projects introduce copyright and licensing considerations.

Sensitive information requires additional protections.

Financial services may introduce further obligations.

These frameworks are not interchangeable, and no single technology establishes automatic compliance.

Our current project is experimental.

We are not claiming formal regulatory approval, institutional adoption or readiness to handle sensitive public-sector information.

Legal design must evolve alongside technical design.

11. Five stages from laboratory to possible national adoption

Here is a realistic way to structure the ambition.

Stage 1: Build and verify

Complete the authenticated test between the VPS and Nicola's independent computer.

Release reviewed Bridge code.

Publish reproducible tests.

Document security boundaries and known limitations.

This is our current stage.

Stage 2: Invite independent participants

Connect additional nodes operated by different people.

Validate onboarding, consent, access revocation and operational recovery.

Test small, non-sensitive applications with willing communities.

Stage 3: Create regional federation experiments

Move beyond a single central broker.

Develop compatible implementations and multiple independently administered coordination services.

Evaluate interoperability and resilience under realistic operating conditions.

Stage 4: Investigate institutional integration

Work with appropriate technical, academic or institutional partners where opportunities arise.

Evaluate relevant standards, accessibility, governance and compliance.

Identify applications that deliver measurable benefits.

Stage 5: Support wider adoption

If the previous stages succeed, develop the accessibility, organizational capacity and sustainable funding needed for broader participation.

National adoption should emerge from demonstrated value rather than an announcement.

We cannot declare an infrastructure ready simply because its roadmap contains the word national.

12. The most important metric is independence

Millions of registered users would make an impressive headline.

But they would not automatically prove that we had built a meaningful decentralized ecosystem.

We should measure something more important.

Can independently operated systems communicate?

Can participants leave without losing access to portable information?

Can permissions be revoked?

Can services recover from failures?

Can another developer reproduce our results?

Can people participate without advanced technical knowledge?

Can governance decisions be understood and challenged?

And can the ecosystem sustain its operations without becoming dependent on a single powerful actor?

These questions are more difficult than counting accounts.

They are also much more relevant to our stated objective.

Conclusion: The future does not need another digital empire

I do not believe that building a decentralized future means replacing today's dominant platforms with MyZubster as another dominant platform.

That would reproduce the same fundamental problem.

Our ambition is to investigate an ecosystem where independently managed applications, digital identities, creative projects and verifiable records can cooperate through open interfaces.

The collaboration with Nicola is our starting point.

His software remains independently developed.

Our VPS provides the current coordination infrastructure.

The Node Bridge establishes a limited technical connection between these environments.

Local AI helps explore how information might remain under participants' control.

The comic makes the journey understandable beyond technical documentation.

And our knowledge-proof experiments investigate how development work and learning might leave inspectable records.

We are not yet operating a decentralized national network.

We are building and testing the components that might eventually make such a network possible.

The next milestone is simple, concrete and essential:

One authenticated request. Two independent computers. A verified result.

If we can reproduce that successfully, document its limitations and allow others to build on it, we will have something more valuable than another technological promise.

We will have the beginning of an open, testable approach to digital cooperation.

And every future step will have to earn its place through evidence.

Explore MyZubster

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

Nicola / N4K48 — Independent MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

N4K48 Comic Series
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

Knowledge-Transfer Documentation
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/knowledge/KNOWLEDGE-TRANSFER-2026-09-18-DANIEL-NICOLA.md

Our Technical Development Story on DEV Community
https://dev.to/danielioni/beyond-the-platform-building-myzubster-with-local-ai-independent-nodes-comics-and-verifiable-kcm

*Project status: October 4, 2026. This article presents a research and development vision. Institutional partnerships, national deployment,

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics

Sun, 04 Oct 2026 08:29:56 +0000

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics and Verifiable Knowledge

By Daniel Ioni | MyZubster Ecosystem
In collaboration with Nicola / N4K48

What if the next Internet belonged to its participants?

Most of today's digital experiences follow a familiar model.

We create an account, upload our information, develop our projects and build our identities inside someone else's infrastructure.

Platforms have made collaboration easier, but they have also created dependencies. The tools we use, the information we publish and the communities we build frequently depend on decisions made by centralized service providers.

What would happen if we approached digital collaboration differently?

What if a developer could maintain independent software on a personal computer, use local artificial intelligence and selectively connect to a wider ecosystem without exposing the entire application?

What if artists could document the history of their work, while learners could connect their achievements to inspectable technical evidence?

These questions inspired an ongoing collaboration between myself, Daniel Ioni, and Nicola, an independent developer known as N4K48.

Together, we are exploring this direction through MyZubster.

And our journey has already taken us from local AI and an experimental software product to illustrated storytelling, server infrastructure, distributed communication and cryptographically verifiable knowledge.

This is the story of what we have built so far.

1. Two developers, two independent environments, one shared experiment

Our collaboration started with a simple principle: participation in an ecosystem should not require abandoning your own project.

Nicola has been developing an independent application called N4K48 / MyZubster MVP.

Rather than creating another interface that simply asks an AI model to answer questions, he has been experimenting with structured information, local storage and evidence-based retrieval.

His application combines several technologies and ideas:

Python APIs and Docker-based development.
Persistent observations and recorded events.
Qdrant and Ollama for local artificial intelligence and retrieval-augmented generation.
An internal ledger and experimental economic simulations.
A creative catalog connected to his N4K48 identity.
Integration with Zorgax, the AI assistance concept within MyZubster.

An important principle guides this development:

An AI-generated answer should not replace an authoritative record when that record already exists.

If an application stores an exact observation, it should be capable of retrieving that observation without inventing an alternative version.

This approach becomes increasingly important when AI systems participate in education, research, economic applications or reputation systems.

Nicola's project is available as an experimental open-source MVP, including a public release candidate.

It is not presented as production-ready software.

That distinction is part of our philosophy: development should be documented through actual evidence rather than ambitious claims.

Explore Nicola's independent software on GitHub

2. When software development becomes a comic

Something unexpected happened during our collaboration.

We began connecting Nicola's technical journey to the visual universe of MyZubster.

His digital identity, N4K48, became the protagonist of an illustrated story set in an evolving cyberpunk-inspired world.

Neon Plaza represents a place where independent projects, digital identities and knowledge might eventually meet.

The comic series currently contains four chapters:

Chapter 1: From a Software Idea to the Metaverse

N4K48 begins with an independent software idea and discovers the possibility of connecting it to something larger.

Chapter 2: The Software Takes Shape

The story follows the work of development: authentication, persistent information, experiments and technical verification.

Chapter 3: Towards Neon Plaza

N4K48 approaches the creative vision of a shared digital environment.

Chapter 4: The Bridge to Be Built

The narrative returns to an unresolved engineering challenge: how can independent software establish a secure connection to the MyZubster infrastructure?

This final chapter is particularly meaningful because it connects our creative vision to the technical problem we are currently solving.

The illustrations were produced with AI assistance under Nicola's documented creative direction.

We have also recorded the provenance of the images through repository references and Git metadata. Rights relating to certain external visual elements and potential commercial uses still require verification.

One original N4K48 comic has been proposed as a possible NFT candidate. It has not been presented as an already minted NFT.

For us, creativity and technical documentation should support each other without becoming confused.

A comic can tell the story of an idea.

The corresponding code, tests and development records can show how far that idea has actually progressed.

Discover the N4K48 comic series

3. Building the bridge between two independent computers

We eventually arrived at the most practical question in our collaboration.

How could Nicola connect his locally running software to MyZubster while maintaining control of his own development environment?

We did not want to require him to expose his entire local API to the public Internet.

Instead, we began constructing a limited, authenticated communication bridge.

Our current architecture includes two separate environments.

The first is the MyZubster VPS, running Ubuntu, Docker and Nginx. It hosts a small Node Bridge broker accessible through a controlled HTTPS endpoint.

The second is Nicola's Windows computer, where his application and local catalog run independently.

A lightweight Python agent is designed to initiate an outbound HTTPS connection to the VPS.

When an authorized request becomes available, the agent retrieves it, contacts Nicola's local application and returns an appropriate response.

The important distinction is that the connection originates from the independent node.

Nicola does not have to publish his development API directly to the Internet merely to participate in the experiment.

The initial Bridge supports a deliberately restricted set of catalog operations.

This is a modest architecture, but it addresses a real problem: how to exchange selected capabilities between independently controlled systems.

The bug that changed our implementation

During testing, we discovered a problem with temporary job assignments.

Our broker could reassign a request when an earlier assignment expired. Unfortunately, the original version could still accept an outdated result from the previous assignment.

That created a risk of confusing an old response with the current result.

We reproduced the problem, corrected the assignment protocol and introduced a unique identifier for each lease.

The updated implementation requires the current lease identifier before accepting a result.

Our regression tests now verify rejection of expired, outdated and duplicate submissions.

This experience reinforced an important lesson:

Distributed software must be designed for interruptions, delays and unexpected responses—not just successful connections.

The corrected broker passed our automated tests and a separate Docker integration test using an agent and simulated catalog.

We subsequently deployed the updated Docker image on the VPS, verified its health and rotated its authentication credentials.

The previous node credential was rejected after rotation.

These are concrete achievements.

However, there is still one essential step ahead of us: validating the complete authenticated connection with Nicola's actual Windows computer.

We have prepared and independently verified his updated agent package. The live VPS-to-PC test remains our next milestone.

We prefer to report that distinction clearly rather than describe an unfinished experiment as a completed decentralized network.

4. Where Tor enters our vision

Our infrastructure experiments also involve Tor.

Tor is particularly interesting when discussing independent communication, privacy and alternatives to conventional Internet exposure.

Its onion services can provide access to applications through the Tor network without requiring the underlying service to publish its location to clients.

But Tor and decentralization are not interchangeable concepts.

Tor provides specific network privacy properties.

Decentralization concerns the distribution of control, authority and infrastructure dependencies.

And application security still requires authentication, carefully restricted operations and responsible management of credentials.

Our currently verified Node Bridge operates through conventional HTTPS. We have not yet demonstrated the complete connection over a dedicated Tor onion service.

A potential future direction is to investigate alternative communication routes, including appropriate Tor-based access.

The purpose would be to offer participants more choices regarding how their independently managed nodes connect.

It would not eliminate the need to understand and secure the underlying software.

5. Decentralization is not a switch

There is a temptation to describe any application running on multiple computers as fully decentralized.

We think this oversimplifies the challenge.

Our present system consists of independent environments communicating through a central VPS broker.

That already creates a useful degree of software and data independence.

But the VPS remains a coordination dependency.

If it becomes unavailable, the current communication path stops working.

A more decentralized future will require additional work: independent node identities, alternative brokers, stronger message verification, reliable recovery, consent management and additional communication paths.

These are difficult engineering and governance problems.

We are approaching them incrementally.

Our intention is to develop a system in which independent participants can decide what to share, retain control over their own resources and contribute to a shared ecosystem through well-defined interfaces.

That ambition is larger than our current implementation.

And we believe documenting the distance between an ambition and its demonstrated realization is part of responsible open-source development.

6. The missing piece in digital collaboration: proof of knowledge

There is another question underlying our work.

When two people collaborate, how do they document what was learned and created?

A finished application reveals something about the result.

A Git repository reveals parts of its development history.

Tests provide evidence of particular software behavior.

But the complete human story also includes research, failed experiments, mentoring, decisions, corrections and acquired understanding.

We are exploring ways to connect these elements through MyZubster's knowledge-proof approach.

The objective is to construct inspectable evidence packages containing documentation, source revisions, test results and explicitly acknowledged contributions.

A cryptographic hash can then identify a particular version of that material.

Nicola's repository already documents an earlier knowledge-transfer snapshot associated with a confirmed commitment on the Base Sepolia test network.

This demonstrates an important technical capability: the published evidence package can be checked against a previously recorded cryptographic commitment.

However, a blockchain commitment does not independently certify someone's competence, establish legal authorship or prove that every statement in a document is true.

Those questions require supporting evidence and appropriate human acknowledgment.

We see cryptographic verification as one component of a larger knowledge-provenance system—not as a replacement for critical evaluation.

Explore our documented knowledge-transfer experiment

7. What could this paradigm change tomorrow?

Imagine a world in which participating in a digital ecosystem does not automatically mean surrendering control over your software or data.

Independent developers could connect their applications through limited interfaces.

Artists could associate their work with transparent creation histories.

Students could support their knowledge records with actual projects and test results.

Researchers could share approved findings while retaining control of underlying datasets.

Communities could develop alternative forms of coordination rather than relying entirely on one company's infrastructure.

Local AI could help people work with their own information while reducing unnecessary dependence on remote processing.

These possibilities are compelling.

But they are not inevitable consequences of deploying a blockchain, installing an AI model or connecting a server to Tor.

They require open standards, interoperable implementations, responsible governance and sustained collaboration.

The most important transformation may therefore be cultural rather than purely technical.

Instead of asking people to trust an impressive announcement, we could increasingly provide them with a way to inspect the evidence behind it.

Instead of requiring every creator to abandon an independent project, we could design systems that allow carefully controlled participation.

Instead of treating learning as an invisible process, we could build better records of the work through which knowledge is acquired and shared.

This is the future we want to investigate.

8. Our next milestone

Our immediate goal is not to announce a fully decentralized Internet.

It is much more concrete.

We want to demonstrate a successful round trip between the MyZubster VPS and Nicola's independent application.

A request should originate from our VPS, travel through the authenticated Bridge, be processed by Nicola's local software and return a verifiable result.

After that, we intend to document what happens during interruptions and reconnections, and evaluate the next architectural improvements.

We will then publish a dedicated technical follow-up containing the actual results.

Meanwhile, this article, our earlier technical report and the public development history form part of our evolving knowledge record.

They document not just an idea, but the engineering process through which we are investigating it.

9. One ecosystem, independent creators

I believe the future of the Internet should create more opportunities for people to build together without requiring them to become dependent on the same centralized system.

My collaboration with Nicola demonstrates how this process can begin.

One person develops independent software.

Another maintains shared infrastructure and works on integration.

Artificial intelligence helps organize and retrieve information.

Creative storytelling communicates ideas that technical documentation alone might not convey.

Tests, source history and cryptographic commitments provide different kinds of evidence.

And an unfinished technical challenge becomes the subject of the next experiment.

Our goal is not to remove human collaboration from technology. It is to build technology that makes independent human collaboration more powerful.

That is the direction we are exploring with MyZubster.

The bridge is being built.

The next chapter will show what happens when Nicola's independent node actually crosses it.

Follow the journey

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

Nicola's independent software:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

N4K48 comics:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

Our detailed technical article on DEV Community:
https://dev.to/danielioni/beyond-the-platform-building-myzubster-with-local-ai-independent-nodes-comics-and-verifiable-kcm

Knowledge-transfer evidence:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/knowledge/KNOWLEDGE-TRANSFER-2026-09-18-DANIEL-NICOLA.md

Technical status: October 4, 2026. This article describes an ongoing experimental project. The updated VPS broker and simulated integration have been verified; the authenticated end-to-end test with Nicola's independent computer is still pending.

From Decentralization to Zorgax: How MyZubster Is Connecting AI, Blockchain, NFTs, Communities and

Tue, 15 Sep 2026 17:35:39 +0000

From Decentralization to Zorgax: How MyZubster Is Connecting AI, Blockchain, NFTs, Communities and Real-World Evidence

MyZubster has gradually evolved from a collection of ideas, experiments and communities into something more ambitious:

a connected ecosystem where independent projects, people, subcultures, AI, digital assets and real-world experiments can interact without requiring everything to be controlled by one central application.

There is an important distinction behind this work.

I did not invent blockchain.

I did not invent NFTs.

I did not invent artificial intelligence.

I did not invent APIs, decentralized systems, online communities, circular economy or environmental monitoring.

Those technologies and concepts already existed.

What I have been trying to create with MyZubster is a way of connecting them into one interoperable, evidence-first model.

The evolution is increasingly about architecture:

IDENTITY
   ↓
COMMUNITY
   ↓
PROJECT
   ↓
API / NODE
   ↓
ZORGAX
   ↓
EVIDENCE
   ↓
BLOCKCHAIN / NFT when appropriate
   ↓
REAL-WORLD ACTIVITY
   ↓
VERIFICATION

This is what I want to explain.

What Already Existed

Before explaining what MyZubster adds, it is important to acknowledge the foundations.

Blockchain

Blockchain already provided distributed ledgers, transactions, tokenization and independently inspectable on-chain records.

MyZubster did not invent that.

The question became:

Where does blockchain actually add useful evidence to a larger workflow?

NFTs

NFTs already made it possible to associate unique tokens with digital assets.

But an NFT does not automatically prove copyright, authorship, environmental impact or ownership of a physical object.

Those claims still require evidence.

Artificial Intelligence

AI assistants and large language models already existed.

They could generate content, analyze information and answer questions.

The MyZubster question became:

What happens if AI becomes an orchestration layer between independent projects rather than simply another chatbot?

APIs

APIs already connected independent systems.

The evolution is using those interfaces to allow independent MyZubster nodes to remain independent while still participating in a shared ecosystem.

Communities and Subcultures

Developers, artists, students, researchers, makers, sound-system communities, environmental groups, cyberpunk communities and local networks already existed.

The objective is not to replace those identities.

It is to connect them without flattening their differences.

From Centralized Platform to Connected Ecosystem

A conventional platform often looks like:

USERS
PROJECTS
CONTENT
DATA
COMMUNITIES
SERVICES
     ↓
ONE CENTRAL PLATFORM

Everything eventually moves inside the same system.

MyZubster is exploring another direction:

PROJECT A ───────┐
PROJECT B ───────┤
CREATOR ─────────┤
RESEARCH NODE ───┤
COMMUNITY ───────┼── ZORGAX ── MYZUBSTER
LOCAL SERVICE ───┤
ENVIRONMENT ─────┤
SUBCULTURE ──────┘

Each node can potentially maintain its own repository, API, data, deployment, identity and community.

MyZubster becomes the connection layer rather than necessarily becoming the owner of everything.

Zorgax: From Chatbot to Orchestration Layer

This has been one of the biggest conceptual evolutions.

A traditional AI assistant looks like:

USER
 ↓
AI
 ↓
ANSWER

Zorgax can evolve toward something different:

USER
 ↓
MYZUBSTER
 ↓
ZORGAX
 ↓
DISCOVER PROJECT
 ↓
SELECT CAPABILITY
 ↓
CALL CONTROLLED API
 ↓
READ DATA
 ↓
CHECK EVIDENCE STATE
 ↓
EXPLAIN RESULT

Zorgax does not necessarily need to own the external project's data.

It needs to know:

Who can answer this question?

Which capability is available?

Which endpoint should be called?

What evidence supports the answer?

N4K48 and Nicola Comics: A Concrete Pilot

Nicola / N4K48 gave us a useful real case for testing this model.

Nicola maintains an independent project containing:

N4K48
+
Nicola Comics
+
Project Planner
+
API
+
GitHub repositories
+
technical evidence

Instead of copying the complete project into MyZubster, we started testing a controlled connection.

The experimental Nicola Comics service exposes concepts such as:

GET /api/comics

and a Zorgax-facing interface:

POST /api/zorgax/ask

with operations such as:

gallery
detail
candidate
next_steps

The architecture becomes:

NICOLA / N4K48
       ↓
NICOLA COMICS
       ↓
CONTROLLED API
       ↓
ZORGAX
       ↓
MYZUBSTER
       ↓
USER

This is a small pilot.

But it demonstrates a potentially reusable integration pattern.

From Nicola to a Network of Nodes

If the model works for Nicola Comics, the same architectural pattern can be explored elsewhere:

NICOLA COMICS ──────────┐
AGRICULTURE ────────────┤
RESEARCH LAB ───────────┤
STUDENT PROJECTS ───────┤
ANIMAL RESCUE ──────────┤
CIRCULAR ECONOMY ───────┼── ZORGAX ── MYZUBSTER
LOCAL SERVICES ─────────┤
ART / WELLNESS ─────────┤
SOUND SYSTEMS ──────────┤
COMMUNITIES ────────────┘

This is where decentralization starts becoming more than infrastructure.

It becomes a model for collaboration.

Connecting Communities and Subcultures

One of the ideas I consider particularly important is that decentralization should also preserve cultural independence.

A sound-system collective does not need to behave like a research laboratory.

An artist does not need to become a software startup.

A student project does not need the same structure as an agricultural experiment.

A cyberpunk community does not have to lose its identity to collaborate with an environmental project.

The network can contain:

SOUND SYSTEM
     │
ART ─┤
     │
MAKERS
     │
STUDENTS
     │
RESEARCH
     ├──── MYZUBSTER
LOCAL│
     │
AGRICULTURE
     │
ENVIRONMENT
     │
CYBERPUNK
     │
DIGITAL CREATORS

The objective is shared infrastructure without mandatory cultural uniformity.

Different communities can remain different and still communicate.

Decentralization Is Not Only Blockchain

This changed my interpretation of decentralization.

Technical decentralization asks:

Where does the data live?

But social decentralization asks additional questions:

Who controls the identity?

Who controls the project?

Who decides what is verified?

Can communities remain independent?

Can independent nodes collaborate without surrendering ownership of their entire infrastructure?

The model becomes:

LOCAL IDENTITY
+
LOCAL CONTROL
+
SHARED INTERFACES
+
INTEROPERABILITY
+
EVIDENCE

Where NFTs Fit

NFTs are one component of this architecture.

They are not the architecture itself.

The Nicola Comics pilot demonstrates why the distinction matters.

A comic can move through:

DIGITAL WORK
↓
DOCUMENTED ASSET
↓
NFT_CANDIDATE
↓
PROPOSED_FOR_REVIEW

Only if the required actions actually happen should the workflow move toward:

RIGHTS CHECK
↓
MINT
↓
CONTRACT ADDRESS
↓
TOKEN ID
↓
TRANSACTION HASH
↓
ON-CHAIN VERIFICATION

Therefore:

NFT_CANDIDATE
≠
MINTED NFT

This is part of the evidence-first philosophy.

Blockchain as an Evidence Layer

The same reasoning applies to blockchain.

Instead of saying:

Put everything on blockchain.

I am exploring:

Which events benefit from an independently inspectable on-chain reference?

The workflow can become:

ACTIVITY
↓
DOCUMENTATION
↓
EVIDENCE
↓
VERIFICATION
↓
SELECTED RECORD
↓
BLOCKCHAIN

Blockchain becomes a specialized evidence layer.

Not a universal truth machine.

Connecting Digital Systems to Physical Experiments

Another evolution has been connecting digital infrastructure with real-world projects.

Examples include:

AGRICULTURE
WATER
CIRCULAR ECONOMY
MATERIALS
WASTE
ENVIRONMENTAL OBSERVATIONS
COMMUNITY ACTIVITY

This also includes experimental concepts around the monitoring and potential recovery or transformation of absorbent sanitary materials.

This is where we need especially strict evidence boundaries.

Software can document:

OBSERVATION
↓
MATERIAL
↓
BATCH
↓
PROCESS
↓
MEASUREMENT
↓
EVIDENCE

But software alone cannot declare:

ENVIRONMENTAL BENEFIT VERIFIED

Scientific or environmental claims require appropriate measurements and validation.

Absorbent Materials × Evidence × Blockchain

This is one example of how previously separate concepts could eventually connect.

Imagine a future recovery experiment involving absorbent materials.

A possible workflow is:

MATERIAL COLLECTED
       ↓
BATCH CREATED
       ↓
PROCESS DOCUMENTED
       ↓
MEASUREMENTS RECORDED
       ↓
EVIDENCE ATTACHED
       ↓
VERIFICATION
       ↓
SELECTED HASH / RECORD
       ↓
BLOCKCHAIN

Zorgax could help participants identify:

missing information;
required measurements;
available evidence;
current verification state;
unresolved questions.

Blockchain could eventually preserve a reference to selected verified records.

But the distinction remains critical:

Blockchain can prove that a record exists. It does not automatically prove that the scientific claim contained in that record is true.

Connecting the Physical and Digital Worlds

This gives us another MyZubster pattern:

REAL WORLD
    ↓
OBSERVATION
    ↓
DATA
    ↓
DOCUMENTATION
    ↓
ZORGAX
    ↓
EVIDENCE
    ↓
VERIFICATION
    ↓
OPTIONAL BLOCKCHAIN RECORD

Now AI, blockchain and environmental activity have separate roles.

They are connected without pretending that they are interchangeable.

A Common Evidence Language

One of the most interesting ideas emerging from these experiments is a common state model:

PROPOSED
↓
DOCUMENTED
↓
IMPLEMENTED
↓
TESTED
↓
DEPLOYED
↓
MEASURED
↓
VERIFIED

Different projects require different evidence.

But this model could potentially help describe the maturity of:

SOFTWARE
NFTs
RESEARCH
AGRICULTURE
CREATIVE WORK
COMMUNITY PROJECTS
CIRCULAR ECONOMY
ENVIRONMENTAL EXPERIMENTS

Zorgax can then help explain where a project currently is, rather than simply presenting everything as finished.

What Is Actually Innovative Here?

I want to be precise about this.

The innovation I am pursuing is not the claim that MyZubster invented the technologies underneath it.

Blockchain existed.

NFTs existed.

AI existed.

APIs existed.

Online communities existed.

Federated architectures existed.

The potentially innovative work is in their composition and connection.

I am experimenting with:

DECENTRALIZED PROJECTS
+
PERSISTENT IDENTITIES
+
COMMUNITIES
+
SUBCULTURES
+
CONTROLLED APIs
+
AI ORCHESTRATION
+
EVIDENCE STATES
+
REAL-WORLD OBSERVATIONS
+
DIGITAL ASSETS
+
BLOCKCHAIN REFERENCES
+
ANALYTICS

as parts of one interoperable architecture.

AI is not blockchain.

Blockchain is not scientific verification.

An NFT is not copyright.

Analytics is not environmental impact.

A community is not a database.

A cyberpunk visual is not technical evidence.

But these components can be connected while preserving those distinctions.

That is where MyZubster is evolving.

From Integrations to a Node Protocol

Today, individual integrations can be built manually.

But that approach does not scale indefinitely.

The next architectural evolution could be allowing each compatible project to describe itself.

Conceptually:

{
  "node": "example-node",
  "identity": "community-or-person",

  "capabilities": [
    "observe",
    "gallery",
    "detail",
    "measure",
    "verify"
  ],

  "services": {
    "api": "/api",
    "zorgax": "/api/zorgax/ask"
  },

  "evidence": {
    "supported": true
  }
}

This could evolve toward a MyZubster Node Manifest.

Zorgax could then discover:

WHO IS THIS NODE?
↓
WHAT CAN IT DO?
↓
WHERE IS ITS API?
↓
WHAT DATA CAN IT EXPOSE?
↓
WHAT EVIDENCE DOES IT SUPPORT?

That moves the architecture away from hard-coded integrations.

From Platform to Protocol

This creates a bigger question.

At first the question was:

What features should MyZubster contain?

Now I increasingly ask:

What shared protocol could allow independent projects and communities to participate in MyZubster?

That is the evolution:

APPLICATION
     ↓
ECOSYSTEM
     ↓
NETWORK OF NODES
     ↓
SHARED PROTOCOL

A Network of Communities

The long-term architecture could resemble:

                 MYZUBSTER
                     │
                  ZORGAX
                     │
        ┌────────────┼────────────┐
        │            │            │
      PEOPLE      PROJECTS    COMMUNITIES
        │            │            │
   identities       APIs       subcultures
        │            │            │
        └────────────┼────────────┘
                     │
                  EVIDENCE
                     │
             ┌───────┼────────┐
             │       │        │
           DATA   PHYSICAL  BLOCKCHAIN
                  WORLD

A developer, researcher, DJ collective, farmer, artist, student, maker or environmental project can participate without being transformed into the same type of organization.

They share interoperability.

They don't have to share identity.

What Exists Today vs What Comes Next

This distinction is essential.

Already built or concretely tested

MyZubster already has public repositories and demo projects.

Zorgax is part of the ecosystem.

N4K48 exists as a persistent project identity.

Nicola Comics exists as a concrete pilot.

A read-only Nicola Comics/Zorgax adapter has been developed and locally validated.

Docker-based testing, API experimentation, public documentation and an evidence-first development approach are already part of the work.

Currently being connected

The current work includes the public Nicola Comics HTTPS deployment, the public Zorgax connection, end-to-end testing, traffic attribution and the exploration of a reusable node architecture.

Longer-term architecture

Automatic node discovery, generic manifests, wider federation between communities, richer blockchain evidence, verified NFT workflows and real-world environmental evidence networks remain directions to build and validate.

They should not be presented as completed production infrastructure yet.

The Final Vision

The objective is not another centralized social network.

It is not another NFT marketplace.

It is not another chatbot.

And it is not another project that adds "blockchain" to everything.

The objective is to explore an ecosystem where a participant can bring:

IDENTITY
+
COMMUNITY
+
SUBCULTURE
+
PROJECT
+
REPOSITORY
+
API
+
DATA
+
EVIDENCE
+
DIGITAL ASSETS
+
REAL-WORLD ACTIVITY

Zorgax helps navigate and connect the network.

MyZubster provides the ecosystem.

Blockchain can preserve selected evidence where appropriate.

NFTs can represent selected digital assets where appropriate.

Analytics can measure interactions.

Scientific evidence can validate physical-world claims.

And independent communities can preserve their identities.

The individual technologies existed before MyZubster.

The experiment is in how I am connecting them.

The most important part may ultimately be cultural rather than technical:

Can independent communities and subcultures collaborate through shared infrastructure without being forced to become the same thing?

That is one of the questions MyZubster is now trying to answer.

Observe → Connect → Build → Measure → Verify → Share → Collaborate → Evolve.

Explore the MyZubster Evolution

MyZubster
https://www.myzubster.com/?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=home

Zorgax
https://www.myzubster.com/zorgax?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=zorgax

Marketplace Demos
https://www.myzubster.com/marketplace-demos?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=marketplace

MyZubster Core
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=github_core

MyZubster Visual Universe
https://github.com/MyZubster-Ecosystem/MyZubster-Visual?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=visual

N4K48 / Nicola
https://github.com/nicolaususnicola-lgtm?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=n4k48

N4K48 × MyZubster
https://github.com/nicolaususnicola-lgtm/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=n4k48_myzubster

Nicola Comics / MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_connected_evolution&utm_content=nicola_mvp

MyZubster #Zorgax #AI #Blockchain #NFT #Decentralization #OpenSource #API #CircularEconomy #Community #Subculture #DistributedSystems #DigitalIdentity #BuildInPublic

Nostr as a backend out of the box: where it fits and where it doesn't

Tue, 14 Jul 2026 10:46:03 +0000

title: "Nostr as a backend out of the box: where it fits and where it doesn't"
published: true
description: "A hands-on review of Nostr as an out-of-the-box backend across real cases: notes, chats, feeds, communities, and organizations."
tags: nostr, decentralization, backend, Flutter
cover_image: https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/hhp9ymdzovelglq8a0m1.png

canonical_url: not needed — dev.to is the original home of this English version

TL;DR. Nostr is a ready-to-use, decentralized backend: it gives you an event model, signatures, encryption, and sync through relays. For notes, private chats, and simple feeds it covers almost everything — with no server of your own. But once you need a smart feed, roles, hierarchies, or complex moderation, the protocol hits one basic limit: only the owner of a key can change an event. After that, the extra workarounds quickly cost more than they save. Below I look at real cases: where Nostr works well, and where it is better to think about a separate backend.

Introduction

For a long time I wanted to build a simple cross-platform notes app.
The most important use case for me was storing sensitive information, such as passwords, crypto wallet addresses, and so on. Another key requirement was reliable sync between devices, in particular iOS, Android, and macOS.

But there was one big problem: for a long time I could not find a secure way to sync notes that did not depend on one specific provider.

Some time ago I happened to join a project built around the Nostr protocol — that is how I first learned about it. For that project Nostr was, to be honest, not a great fit (you will see why later in the article). But for my notes task it turned out to be an almost perfect solution.

The goal of this article is to review the good and the bad cases of using the Nostr protocol that I ran into myself. I also want to describe the tasks it is worth using for, and the tasks where you should look for other solutions.

What the Nostr protocol is and how it works

The Nostr protocol presents itself as a backend for building decentralized social networks that are hard to censor. But, as you will see below, it can be used for a wider range of tasks. That said, building a social network in the usual sense (with complex feed ranking and filtering, and good performance on complex post models) is, in my personal opinion, hard.

The Nostr protocol is a set of rules (NIPs) for talking to a decentralized network of servers (relays). You talk to them over WebSockets. Each server keeps a database of events. An event is a record with a fixed structure; the client and the relay exchange it as a JSON object with a defined schema. A user can read and publish such events from one or more relays (and to one or more relays). Each event has an id — a hash of the event itself (more precisely, a SHA-256 of a serialized set of fields: pubkey, created_at, kind, tags, and content), not just of its content. So when you get the same event from different relays, the id is used to remove duplicates. Each event also has a signature. The signature is made from the event id and the sender's private key, and the JSON event has a field with the sender's public key. So to publish an event to one or more relays you need this key pair. (To read events you do not need any keys.)

It is easy to see that a key pair can also be used for asymmetric encryption. The spec describes common ways to encrypt chat messages — for example, the current Encrypted Payloads (NIP-44), which the Private Direct Messages (NIP-17) feature is built on. There is also an older Encrypted Direct Message (NIP-04): it is officially marked as deprecated and is not recommended for public, decentralized use (it uses unauthenticated encryption and leaks metadata).

Still, it is important to understand that NIP-44 is not the only option. The protocol does not force a specific algorithm: clients are free to agree on any compatible way to encrypt content. So for practical tasks — say, if you run your own private relay or solve a specific business task — NIP-04 with plain AES, or any other scheme you like, can be a good fit.

Data model: events, `kind`, and tags

If you already know Nostr (events, kind, tags, the REQ subscription model), feel free to skip this section and go straight to the cases.

Before we get to the cases, it makes sense to look a bit closer at how an event is built — we will keep coming back to it.

Any Nostr event is JSON that looks roughly like this:

{
  "id": "1897f99...",
  "pubkey": "9c2e0a7...",
  "created_at": 1781787656,
  "kind": 1,
  "tags": [
    ["e", "737f50..."],
    ["p", "9c2e0a7..."]
  ],
  "content": "Hello, Nostr!",
  "sig": "41b737f50..."
}

The kind field is an integer that sets the rough meaning of an event, rather than a strict type. For example, kind:0 is a user profile, kind:1 is a short text note (a post), kind:7 is a reaction (a like). It is important that this is an agreement, not a strict schema: the meaning of each kind is described in its NIP, and most NIPs have draft status — so these are conventions, not a fixed standard. The relay does not validate the structure of the content: the clients that agreed with each other are fully responsible for how a kind and the event format are read. You could say a kind is something like a "table" in a normal database, but without a strict schema and without server-side validation.

Besides meaning, kind also sets how the relay stores the event. The exact behavior depends on the number range (the ranges are defined in NIP-01). In simple terms, events fall into:

regular — range 1000–9999 (also kind:1, kind:4–44); they just pile up and overwrite nothing;
replaceable — range 10000–19999 (also kind:0 for a profile, kind:3 for a contact list); the relay keeps only the newest version for a given author, and a new event replaces the old one;
addressable (also called parameterized replaceable) — range 30000–39999; the same as replaceable, but the "coordinates" for replacing also include the value of the d tag (see below). This is how updatable things with an identifier work — a long note (kind:30023), a community definition (kind:34550);
ephemeral — range 20000–29999; the relay does not have to store them at all (useful for signaling).

For addressable events the "coordinates" are the triple kind:pubkey:d, where d is the value of a special ["d", "..."] tag — a stable identifier of the thing. The a tag points to such events using the kind:pubkey:d format (we will see this below).

The tags field is an array of arrays: the first item of each inner array is the tag name, and the rest are its values (["e", "<event id>"], ["p", "<pubkey>"], and so on). Tags with single-letter names (e, p, a, g, d, …) are indexed by the relay, and you can filter queries by them — in a filter this is written as #e, #p, #g (this will be useful in the feed section).

Finally, about how events are requested. To get events, the client opens a subscription with a message like this:

["REQ", "<subscription id>", { <filter> }, { <filter> }, ...]

A filter is a JSON object with fields like authors, kinds, since, until, limit, #e, #g. The relay returns all events that match at least one filter, and keeps the subscription open — it sends new matching events as they appear, until the client closes it with a CLOSE message. We will come back to filters and their limits.

Notes

While I was building my app, I did not really think about what the word Nostr stands for. Nostr is an acronym: Notes and Other Stuff Transmitted by Relays.

So the idea of a notes app on top of this protocol was obvious. Nostr gives you sync, and it offers recommendations for strong asymmetric encryption — Encrypted Payloads (Versioned).

So Nostr is a very good fit for this task.

This is how my pet project appeared — Private Notes (Nostr): a cross-platform notes app with end-to-end encryption on the device (NIP-44), signing with secp256k1, and storage on relays the user picks. No server, no accounts — just a key pair. You can try it right now:

iOS: App Store
Web: alexeyyupopkov.github.io
Android: Install Beta
Source code: github.com/AlexeyYuPopkov/nostr_notes

The repository is open — if you find a bug or have an idea, feel free to open an Issue, I will be glad to hear from you.

Chats

Many small mobile apps have a chat feature. For most such projects the chat backend is a third-party service like Twilio, Quickblox, or a cloud database such as Firebase Realtime Database or Cloud Firestore. But this means extra costs for these subscriptions. In the second case you also need to design the database for chat data, and that means extra work and bugs. Nostr, on the other hand, gives you a ready backend that fits chats well. You can either use the many public relays that already work, or run your own on your own backend by downloading a popular implementation from GitHub.

One more thing worth mentioning is media content in chat messages. A Nostr event is always JSON with a fixed schema, and the protocol does not expect you to store binary data (images, files) inside an event. To solve this there is NIP-96 — a standard that describes HTTP File Storage: a spec for file hosts compatible with Nostr. The client uploads a file to a NIP-96 server, gets a URL, and puts it in the event content. Public NIP-96 servers exist, and in general this works.

But in practice, if a project already uses central infrastructure (AWS S3, Firebase Cloud Storage, and so on), it is simpler and safer to store media there and just put a link in the Nostr event. It is a plain approach, but for most products it is a reasonable one.

For one-on-one (one2one) chats Nostr gives you everything out of the box. But for group chats there are limits in practice, and getting around them needs extra logic.

I would point out two such problems:
1) the performance of message encryption
2) group moderation

The first one is this. To use asymmetric encryption (Encrypted Direct Message or Encrypted Payloads (Versioned)), you have to encrypt the message separately for each user. As the number of group members grows, this can hurt both performance and the overall reliability of the approach. That said, from my own experience, for groups of 20 people or fewer I did not see real performance problems. I have read that up to 100 people should also be fine. At the same time, for extra reliability I would rather use central solutions outside the Nostr protocol to encrypt message content (even though that is less secure).

The second problem is moderating the group and adding or removing members. The existing solution, Private Direct Messages, is basically a group conversation without a separate, managed group object. The group's metadata (name, and so on) is not stored as one thing; it is computed from the tags of the messages themselves, and the tags of the newest message "win". As a result, you cannot "hard" add or remove members, and in fact any member can redefine the group metadata — just by sending a new message with the tags they want. The root of the problem is in the base of the Nostr protocol: only the creator of an event can change it. So if you create an event — a chat room model — and link messages to it by a reference to the room, then only its creator can moderate that event. That means there is only one moderator. And even this solution is a bit artificial — I have not seen a NIP (a Nostr standard) for it.

There is also a solution to this problem — NIP-29. It means running your own, separate relay for group moderation (though public relay-29 servers exist too, for example wss://relay.groups.nip29.com). The relay itself checks whether a moderator is allowed to change the group state. Such a relay is responsible only for the group state, not for the users' messages, which are stored on normal relays. But this is, rather, a central solution (otherwise you lose the single source of truth and risk getting out of sync).

Overall, relay-29 is a good central solution for group chats with roles and moderation, and it really works.

Feed, posts

In my view, a social network is first of all posts, likes, comments, and reposts.

Let's try to figure out how well the Nostr protocol fits these goals and what the limits are. We already know that relays store event models and can return their JSON over WebSockets.
For clarity, here is an example of a possible post JSON:

    {

        "created_at": 1781787656,
        "id": "1897f99...",
        "kind": 1,
        "pubkey": "9c2e0a7...",
        "content": "Some text...",
        "sig": "41b737f50...",
        "tags": [
			["e", "737f50..."],
			["e", "1897f..."],
			...,
			["a", "30023:f72...:abcd"],
			["a", "30023:er34...:abcd"],
			...,
			["g", "u4pr"],
			["g", "u4pru"]	
		]
    }

All tags are optional. Let's go over the ones in the example:

e — a reference to another event by its id; used for threads, quotes, and replies
a — a reference to an addressable (replaceable) event in the kind:pubkey:d format; in the example above these are references to kind:30023 events (long posts / articles per NIP-23) by different authors
g — a geohash of the location the post is linked to; the longer the string, the more precise the coordinate (u4pr is a rough region, u4pru is a bit more precise)

Now, to understand the limits of Nostr, let's look at a few cases:
1) To show, for example, posts (usually kind:1) by specific authors (see authors) in a feed, you send a request:

["REQ", "feed-sub-1", {
  "authors": ["9c2e0a7...", "pubkey1", "pubkey2", ...],
  "kinds": [1],
  "until": 1718700000,
  "limit": 20
}]

So far so good. With until + limit it is easy to set up time-based pagination here, and it will work reliably.

2) Now let's make it harder. Say we need to build a feed that shows posts by specific authors OR posts by users with a nearby location:

["REQ", "feed-sub-2", {
  "authors": ["9c2e0a7...", "pubkey1", "pubkey2", ...],
  "kinds": [1],
  "until": 1718700000,
  "limit": 20
},
{
  "kinds": [1],
  "#g": ["u4pr"],
  "until": 1718700000,
  "limit": 20
}]

And here a problem shows up right away. Inside one filter object all conditions work as AND — that is, authors + kinds + until must all match for one event. But to get OR between "posts by the authors we want" and "posts with the geohash we want", you have to use two separate filters in an array. The relay then returns the union of both results.
And this is exactly where reliable until+limit pagination breaks. Each filter in the array is limited on its own: in a typical implementation the relay applies limit: 20 to each of the two filters separately (the exact behavior when merging results from several filters depends on the relay implementation), and then mixes the results. So imagine the first filter (by authors) collected 20 newer posts, and the second (by geohash) also collected 20, but older ones. The final output — after sorting by time and cutting to a common limit on the client — may take only part of one source and miss part of the other. On the next request the new until is computed from the oldest post you received. For one of the filters this until will be wrong: it will either cover already shown posts again, or skip part of the events that never reached the client. You get holes in the feed, and they add up with each new load.

A working but more time-consuming way is pagination through a time window (since + until) that grows step by step — it widens if too few events fall into it. This approach has its own downsides: an unpredictable number of requests to the relay for one feed page, trouble showing a loading indicator, and the risk of a long "freeze" during quiet periods.

A third problem comes up at the level of the geohash filter itself: matching the g tag works by exact string equality, not by prefix. If an event has only ["g", "u4pr"] (a rough location), and the filter asks for "#g": ["u4pruyd"] (a more precise one), the relay will not return that event — even though u4pruyd is physically inside u4pr. People get around this by publishing several geohash tags of different length (all the prefixes) on one event. But then the client that makes the request has to list all the prefixes of the area it wants — this scales poorly and bloats the filter when you try to cover a wide area.

In the event model above you can see the a and e tags. With them you can link a post to some other event (for example, to another post, if the post is a comment on it — usually through an e tag, or a comment on some changeable event — through an a tag). The e and a tags are described in more detail in NIP-01. A post can also have likes, which are usually done through kind=7 events, and comments (e). To get the number of likes and comments and show them in the feed, you need to open subscriptions to the matching events and then count them. So after you get the post and learn its id, you send a request:

["REQ", "post-stats-sub", {
  "kinds": [7, 1],
  "#e": ["1897f99..."]
}]

But likes and comments are far from the only things that can reference (or be referenced by) a given post. Through e/a tags, a post can be pointed to by reposts (kind=6/16), zap receipts (kind=9735), reactions with custom content besides likes, quotes inside other posts, and so on. For each kind of link you basically need a separate subscription with its own kinds filter, or a wider filter with no kinds limit, which you then have to filter and parse on the client. Already at this stage you can see that to fully show one post card in a feed you may need not one but a whole set of parallel requests to the relay.
There is also a less obvious danger here. Since e/a links are not limited by the protocol in any way, nothing stops events from referencing each other in a cycle — post A comments on post B, which itself is marked as a comment on post A (by accident, a client bug, or on purpose, as spam or an attack). A client that naively walks the tree of linked events (for example, to build a full thread) can fall into an endless loop if it does not add protection in advance — tracking the ids it has already visited, or limiting the recursion depth.

So while Nostr is a good fit for simple feeds, more complex ones can run into trouble: very greedy content loading and, as a result, a very large number of requests and poor performance.

As for the features we are used to in top social networks — a smart feed and many flexible filters — it seems you cannot build them with Nostr alone, without custom add-ons and without losing decentralization.

Then again, maybe it is better without a smart feed: it is not great that you often cannot find a post you liked a second time.

Community

One of the features built on Nostr that I had to work with is NIP-72.
In short, NIP-72 is a NIP that describes moderated topic communities on top of normal Nostr events. A community is defined by an addressable event (kind:34550), which lists its moderators. Any user can publish a post that links to this community — that is, propose a publication in the community. But for a post to actually count as part of the community and show up in its feed, one of the moderators must publish a separate approval event (kind:4550). This event contains the original post in full and is signed by the moderator's key. When building the community feed, clients rely on these approval events, not on the posts with the tag. So selection and moderation here are fully on the side of public, verifiable signatures.

In principle, this works. But when a manager comes and says that any moderator should be able to moderate the community without the creator's approval, a problem appears. NIP-72 does not assume that someone from the moderator list can edit the community definition itself. The moderator list in kind:34550 is just p tags listed inside an event signed by its owner. Only the holder of the private key that originally signed it can change this event (and therefore the moderator list) — that is, the community creator, not any of the listed moderators. This is a direct result of a base Nostr limit: only the holder of the key that is authoritative for an event's state can edit or redefine that state, and the protocol does not split this authority into roles at all. Trying to solve this with Nostr alone, without going beyond the protocol, leads nowhere good in the end. In practice the problem was solved with a central add-on — an extra service that adds extra signatures to events on top of the protocol model. But even with this solution I was very unhappy both with the communities feature itself and with the final implementation.

One more similar use case — organizations

I had to deal with this case too. Here is a short description of the task. There are organizations and sub-organizations, and posts and other similar events are published on their behalf. Only members can publish on behalf of an organization or sub-organization. Members have roles, and depending on the role they can invite other members.

Building this with Nostr alone is a doubtful idea. The protocol has no built-in model for roles, for an "organization → sub-organization" hierarchy, or for invitations; all it has is signing with one key as the only way to authorize. Here it is worth mentioning that Nostr did have a "native" way to delegate signing — NIP-26 (Delegated Event Signing), but it never caught on and is now marked as deprecated. So even the protocol's own delegation mechanism was, in the end, seen as a failure, and in practice the task is solved centrally — for example, with keycast, a service for delegating signing in Nostr, made specially for team work with keys. But even keycast does not fully solve the task, in particular the problem of roles. To give teams control over who can sign what, its authors had to build their own system of policies and permissions around keys — something the protocol does not have. This says a lot: even a tool made specially for delegating signing ends up coming down to writing a full backend from scratch. So managing roles and an organization hierarchy will also need central solutions — and not only for delegating signing, but also separately for managing roles. The amount of such work is comparable to writing a separate backend for this task, and using Nostr as the backend, or even as part of it, looks unjustified here.

Conclusions

If you go through all these cases — from notes and one2one chats to groups, feeds, and organizations — a fairly clear pattern appears.

Nostr really is a ready backend out of the box, and in two forms at once. It can be a fully decentralized solution based on a network of public relays. Or it can be a central one — if you run your own private relay and use the protocol just as a handy, ready format for data, sync, and authentication on top of your own infrastructure. The second option, by the way, is not as much of a compromise as it may seem: even if you give up decentralization, you still get a ready event model, signatures, encryption, and many ready client libraries. That is, you save time not only on infrastructure, but also on designing the communication protocol itself.

And for a number of tasks this solution really fits well — notes, chats (especially one2one), simple post feeds without claims to a complex feed. Here Nostr closes the classic problems (sync, encryption, identity) with almost no need to write your own backend at all.

But along the way I also collected a few lessons for myself.

Do not try to build a full social network on the level of Facebook, or any top social network, on Nostr. As soon as a smart feed, flexible filtering, role models with hierarchy, and other features long standard for top social networks come into play, the protocol starts to fall apart. Not because the NIP authors missed something, but because the model itself (a relay as a dumb store of signed events, with no server that has the full and sole right to complex business logic) is not made for this.

Do not try to get around the protocol's limits. The temptation to "stretch" Nostr to the business logic you need with custom add-ons — be it a synthetic moderator model, extra signatures on top of events, or third-party delegation services — is strong, and almost always technically possible. But, as the NIP-72 and organizations cases show, at some point these add-ons start to weigh more than the protocol they were meant to make simpler. And, more importantly, getting around the limits is not free. Besides losing decentralization and compatibility with the rest of the Nostr ecosystem (other clients, relays, NIPs), such add-ons are always one more surface for bugs — bugs in code that no one but you has tested at scale.

Before you start building, weigh both paths honestly: use Nostr with add-ons, or think about a separate backend for the specific task. Your own backend for roles, hierarchy, and moderation is written without looking back at someone else's protocol limits like "one key owner". It is often faster than building workarounds around Nostr — especially if the task fits the "signed events + relay" model poorly from the start.

The bottom line: Nostr is a great tool when the task lands in its "native" niche — and surprisingly awkward when you try to stretch it onto something it was not meant for. As with any tool, the main thing is to understand in advance which of these two groups your task falls into, instead of finding out after a month of work.

The app from this article

Private Notes (Nostr) is open source — you can look through the code to see the approach in practice.

A Russian version of this article is available on Habr: habr.com/ru/articles/1050348

Infrastructure Is the Real Product: How Ktzchen Web3 Avoids Bottlenecks by Design

Tue, 21 Apr 2026 13:24:15 +0000

In Web3, everyone talks about features.

Few talk about infrastructure.

But infrastructure is the product.

At Ktzchen Web3, every tool — from contract analysis to on-chain audits — runs on a deliberately designed architecture built to eliminate bottlenecks, reduce latency, and maintain real-time blockchain synchronization.

Not shared.
Not oversold.
Not superficial.

Intentional.

The Problem With “Cloud-First” Web3

Many Web3 platforms rely on:

Over-subscribed virtual machines

Shared compute environments

I/O contention

Third-party RPC dependencies

Hidden latency layers

It works — until it doesn’t.

When infrastructure is shared, performance becomes probabilistic.
When I/O is congested, blockchain sync lags.
When you depend on third-party RPCs, you inherit their downtime.

In blockchain infrastructure, consistency matters more than spikes.

The Architectural Philosophy

Ktzchen Web3 operates on an infrastructure model designed around:

No over-subscription

Dedicated resources

No shared virtualization layers

No I/O bottlenecks

High-speed memory and storage alignment

Real-time node synchronization

Consistently low latency

No dependency on third parties for critical blockchain data

This isn’t about marketing numbers.

It’s about eliminating systemic friction.

Why Bottlenecks Kill Web3 Tools

Blockchain workloads are unique:

Continuous disk writes

Constant state updates

Heavy read queries

High RPC demand

Real-time verification needs

If memory, CPU, and storage aren’t aligned, you create:

Sync delays

Transaction lag

Inconsistent audit results

Inaccurate mempool monitoring

Slow contract analysis

That’s not a frontend problem.

That’s architecture debt.

Dedicated Infrastructure = Predictable Performance

When infrastructure is purpose-built:

Gas data updates instantly

Whale monitoring reflects real-time activity

Audit certificates register without delay

Node statistics reflect true network state

Blockchain explorers show accurate block data

Consistency builds trust.

And trust is infrastructure.

Simplicity Is Security

Complex multi-layer deployments often introduce:

Hidden failure points

Configuration drift

Attack surface expansion

Dependency fragility

A simplified, secure, automated node architecture reduces:

Operational risk

Latency variance

External dependencies

Infrastructure entropy

Security isn’t just about firewalls.

It’s about design.

Infrastructure Is the Competitive Edge

Ktzchen Web3 tools don’t just look functional.

They operate on infrastructure intentionally designed to:

Avoid congestion

Maintain full synchronization

Deliver consistent low-latency performance

Protect critical data integrity

Because in Web3, you’re not building apps.

You’re operating state machines.

And state machines demand precision.

Final Thought

Anyone can deploy a frontend.

Few operate real blockchain infrastructure.

Infrastructure is invisible — until it fails.

Ours doesn’t depend on hope.
It depends on architecture.

Visit the website here: https://ktzchenweb3.io/

Securing the Smile: Why Dental Systems Must Adopt Sovereign Security Trends

Tue, 14 Apr 2026 08:07:44 +0000

I. The Core Thesis (The Apex)

To protect sensitive patient data in 2026, web-based dental management systems must shift from reactive security to proactive resilience. By integrating Zero Trust, Decentralized Identity, and Privacy-Preserving AI, clinics move beyond "fancy" interfaces to architectures that are mathematically incapable of compromising individual privacy.

II. Eliminate the "Castle" Fallacy with Zero Trust

The traditional perimeter-based security model—where we assume safety once inside the network—is obsolete. In a modern clinic, a single stolen credential should not lead to a total database breach.

The Strategic Shift: Transition to Zero Trust Architecture (ZTA), where every request—whether from the dentist, the hygienist, or the front desk—is continuously authenticated and authorized.
The Impact: Implementing Micro-segmentation ensures that a breach in the administrative scheduling module does not grant lateral access to clinical records or sensitive X-ray data.
III. Decentralize Identity to Reduce Liability

Storing thousands of patient credentials creates a "honeypot" for attackers. The ultimate security strategy is simple: if the clinic does not hold the master keys, it cannot lose them.
The Strategic Shift: Adopt Self-Sovereign Identity (SSI) and patient-controlled "Digital Wallets."
The Impact: Patients grant temporary, cryptographic access permissions for specific sessions. The clinic fulfills its duty of care without becoming a permanent custodian of vulnerable master credentials.
IV. AI-Driven Privacy via "Librarian" Ethics

Data analysis is vital for clinic efficiency and business growth, but raw data access remains a massive liability.
The Strategic Shift: Leverage Differential Privacy and Federated Learning to gain administrative insights.
The Impact: Your system provides business intelligence (such as peak hours or equipment utilization) by adding mathematical "noise" to the dataset. This allows for accurate management statistics without ever "seeing" or exposing an individual patient's private identifiers.
V. Conclusion: Future-Proofing with Post-Quantum Rigor

Dental records are long-term assets, often required to be stored for a decade or more. Standard encryption today will likely fail against future quantum computing threats.
The Bottom Line: Real innovation isn't just about moving management online; it's about building a Sovereign Bureau for health data. By integrating Post-Quantum Cryptography (PQC) and decentralized protocols, we prioritize the patient's identity over the clinic's convenience, ensuring data remains secure for the next generation.

Which of these security pillars are you prioritizing for your 2026 builds? Let’s discuss the transition to decentralized health tech in the comments below.

HealthTech #CyberSecurity #Web3 #ZeroTrust #DentalManagement #PADI

Nonfinancial Distributed Ledger Technologies (DLTs)

Thu, 29 Jan 2026 04:09:20 +0000

At its heart, a Distributed Ledger Technology (DLT) is a database that is consensually shared and synchronized across multiple sites, institutions, or geographies. The most famous example is the blockchain, but DLT is the broader category.

The key shift to "nonfinancial" means moving beyond the original use case of cryptocurrencies (like Bitcoin) to use the core properties of DLTs for other purposes. These properties are:

Decentralization & Immutability: No single entity controls the ledger. Once data is recorded and validated, it is extremely difficult to alter, creating a trusted, tamper-evident history.

Transparency & Auditability: All participants (with permission) can see the same data and its entire history.

Cryptographic Security: Data is secured using advanced cryptography.

Key Nonfinancial Applications

These properties solve problems in sectors where trust, provenance, and coordination between multiple parties are critical:

Supply Chain & Logistics: Tracking the origin and journey of goods (e.g., food from farm to table, luxury goods to combat counterfeiting).

Intellectual Property & Royalties: Creating immutable records of creative work and automating royalty payments through smart contracts.

Voting Systems: Enabling secure, transparent, and verifiable digital voting.

Identity Management: Giving individuals control over their digital identities (e.g., passports, professional credentials) and sharing them securely.

Real Estate: Streamlining property titles, deeds, and transaction records to reduce fraud and administrative cost.

Healthcare Implementation: A Major Focus Area

Healthcare is one of the most promising and active fields for nonfinancial DLT, as it grapples with issues of data silos, security, and patient control. Here are the key implementations:

1. Interoperable & Patient-Centric Health Records

Problem: Patient data is locked in silos (hospitals, clinics, labs), leading to fragmented care and inefficiency.

DLT Solution: A patient's health data can be hashed (cryptographically fingerprinted) and the hashes stored on a blockchain. The actual data can be stored securely off-chain. The patient controls the private keys and grants explicit, auditable permission to doctors, insurers, or researchers to access specific parts of their record. This creates a longitudinal, unified, and patient-owned health record.

Example: Projects like MedRec (MIT) and various Decentralized Identifiers (DIDs) frameworks are pioneering this.

2. Pharmaceutical Supply Chain & Drug Provenance
Problem: Counterfeit drugs are a global health crisis.

DLT Solution: Each drug package gets a unique identifier logged on a blockchain at every step—from manufacturer to distributor to pharmacy. Anyone can scan a code to verify its authenticity and entire journey. This is being mandated in regulations like the U.S. Drug Supply Chain Security Act (DSCSA).

3. Clinical Trial Integrity & Data Management
Problem: Trial data can be susceptible to manipulation, and patient consent management is complex.

DLT Solution: Protocol details, patient consent forms, and data points are time-stamped and immutably recorded. This ensures data integrity, prevents fraud, and creates a transparent audit trail. Smart contracts can also automate payments to trial participants.

4. Medical Credentials & Credentialing
Problem: Verifying the licenses and certifications of healthcare professionals is slow and manual.

DLT Solution: Universities and licensing boards can issue digital credentials (as verifiable credentials) directly to a professional's blockchain-based wallet. Hospitals can instantly and cryptographically verify these credentials, reducing administrative overhead.

5. Research & Data Monetization
Problem: Patients rarely benefit from the value of their anonymized health data used in research.

DLT Solution: Patients can grant fine-grained, revocable access to their anonymized data. Smart contracts can facilitate micro-payments or rewards to patients whenever researchers purchase access, creating a new, equitable data economy.

Challenges in Healthcare DLT Implementation

Scalability & Speed: Health systems generate vast amounts of data. DLTs must handle this scale without slowing down.

Regulatory Compliance: Navigating HIPAA (in the US), GDPR (in Europe), and other privacy laws is complex, especially regarding the "right to be forgotten" vs. blockchain immutability.

Integration with Legacy Systems: Getting existing hospital IT systems (Epic, Cerner) to interact with DLT networks is a major technical hurdle.

Cultural Adoption: Shifting to a decentralized model requires a significant change in mindset for both institutions and patients.

Conclusion

The emerging nonfinancial DLT landscape is about leveraging "trustless" systems to create new forms of efficiency, security, and user empowerment. In healthcare, specifically, DLT is not about storing your MRI scan on a public blockchain. It's about creating an immutable log of who accessed it, when, and with what permission, thereby enabling secure data sharing, combating fraud, and ultimately placing the patient at the center of their health data ecosystem. It's a foundational technology that, while still maturing, has the potential to reshape the architecture of trust in the digital world.

The Indispensable Practice of Abstraction: Decoupling Your Frontend Logic from External Libraries

Mon, 20 Oct 2025 11:14:55 +0000

In modern frontend architecture, the principle of separation of concerns is paramount. Your application's core logic (business rules, state, and UI) must be entirely isolated from the specific Application Programming Interfaces (APIs) of third-party libraries. This best practice, known as creating an Anti-Corruption Layer (ACL), is the difference between a flexible, maintainable codebase and a fragile, tightly coupled one.

The Problem: Tight Coupling and Vendor Lock-in

When you directly integrate a library's specific methods into your components, you create a dependency that is rigid and difficult to change. For instance, directly using window.Stripe.redirectToCheckout() in a checkout button component couples your UI directly to the Stripe SDK.

The Core Risks:

Vendor Lock-in: You are locked into a specific vendor (e.g., Supabase, Auth0, Stripe). If a better, cheaper, or more performant alternative emerges, changing libraries means a massive, error-prone refactor across your entire application.
Difficult Testing: Unit testing a component that directly calls an external SDK requires complex mocking of that entire library's API, cluttering your test setup.
Inconsistent Code: Error handling, data formatting, and asynchronous logic become inconsistent when repeated across many components.

The Solution: The Abstraction Layer

The solution is an intermediate layer—a Service, Repository, or Utility module—that acts as the single point of entry for all library interactions.

How Abstraction Works:

Generic Interface: Define functions using domain language (e.g., getProducts, processPayment) that describe what your app needs to do, not how it's done.
Encapsulation: All library-specific imports and calls are encapsulated within this single module.
Standardization: The layer is responsible for translating the external library's quirky response formats and error structures into the simple, predictable formats your application expects.

1. Abstracting Data Access (The Repository Pattern)

This is the most critical area for separation. We separate the database library (like Supabase) from the code itself by creating a Service or Repository layer with generic names.

Example: Decoupling Data Fetching (Supabase vs. Custom REST API)

Let's assume our application needs to fetch product data.

Tightly Coupled (Bad)

// src/components/ProductList.jsx

import { supabase } from '../lib/supabaseClient'; // Directly importing the library

const fetchProducts = async () => {
  // Hard dependency on Supabase API structure (from, select, etc.)
  const { data: products, error } = await supabase.from('products').select(`
    id,
    name,
    price_cents,
    inventory:product_inventory(stock_count)
  `);

  if (error) throw new Error(error.message);

  // Data requires complex, specific formatting here
  return products.map(p => ({
      ...p,
      price: p.price_cents / 100,
      stock: p.inventory[0]?.stock_count || 0
  }));
};

Decoupled (Good) with a Service

First, the abstraction layer handles the library call and data standardization:

// src/services/productService.js (The Abstraction Layer)

import { supabase } from '../lib/supabaseClient'; // Encapsulates the library dependency

// Defines a predictable structure for the rest of the application
const formatProduct = (productData) => ({
    id: productData.id,
    name: productData.name,
    price: productData.price_cents / 100, // Standardize cents to dollars
    stock: productData.product_inventory[0]?.stock_count || 0,
});

export const productService = {
  // Generic function name: getProducts
  getProducts: async () => {
    // 1. Library-specific call is confined here
    const { data, error } = await supabase.from('products').select(`
      id,
      name,
      price_cents,
      product_inventory(stock_count)
    `);

    if (error) {
      // 2. Standardize error handling
      throw new Error("Failed to retrieve products from data source.");
    }
    // 3. Standardize and return clean, formatted data
    return data.map(formatProduct);
  },
};

Second, the component uses the clean interface:

// src/components/ProductList.jsx

import { productService } from '../services/productService'; // Generic interface

const fetchProducts = async () => {
  // Clean, generic call. The component doesn't know (or care) about Supabase
  const products = await productService.getProducts();
  // ... use products
};

The Flexibility: If you replace Supabase with a custom REST API using Axios, you only change productService.js. The component code remains untouched.

// src/services/productService.js (Rewritten for Custom REST API via Axios)

import axios from 'axios'; // Encapsulates the new dependency

// formatProduct function remains the same!

export const productService = {
  getProducts: async () => {
    try {
      // New library-specific call
      const response = await axios.get('/api/v1/products');
      // Assume the API returns raw data that still needs to be formatted
      return response.data.map(formatProduct);
    } catch (error) {
      throw new Error("Failed to retrieve products from REST API.");
    }
  },
};

2. Abstraction for All External Dependencies

This principle should be applied to every external dependency to ensure your application is future-proof and agile when a library becomes obsolete or unsuitable.

A. Payment SDKs (e.g., Stripe)

Your checkout flow must be protected from library changes.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Payment: Redirect to checkout screen.	Component calls: `window.Stripe.redirectToCheckout({ /... config / })`	Component calls: `paymentService.initiateCheckout(cartId)`
Abstraction Layer:	None	`paymentService.js` handles all Stripe SDK imports, configurations, and API calls.
Flexibility:	Switching to PayPal or Square requires modifying every component that touches payment.	Only `paymentService.js` needs to be rewritten. The `initiateCheckout` function signature is preserved.

B. Internationalization (i18n) Libraries (e.g., FormatJS vs. react-i18next)

Components should only request a translated string using a generic key.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Translation: Get a welcome message.	Component uses: `const { formatMessage } = useIntl(); return formatMessage(messages.welcome)` (FormatJS-specific)	Component uses: `const { T } = useAppTranslation(); return T('welcome_message', { name: user.name })`
Abstraction Layer:	None	`useAppTranslation.js` wraps the specific library's translation hook/functionality.
Flexibility:	Switching to a different i18n library means changing hook imports and function names in every component.	Only the implementation inside `useAppTranslation.js` changes, maintaining the generic `T` interface.

C. Client-Side Authentication (e.g., Auth0 vs. Firebase Auth)

Decoupling auth ensures your routing and UI logic are stable regardless of the provider.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Auth Status: Check if a user is logged in.	Router guard calls: `Auth0Client.isAuthenticated()`	Router guard calls: `authService.isLoggedIn()`
Abstraction Layer:	None	`authService.js` or `useAuth` hook handles token storage, session checks, and specific library methods.
Flexibility:	If you migrate from Auth0 to Firebase Auth, you need to update logic everywhere Auth0's specific methods are called.	Only `authService.js` is rewritten to use Firebase SDK methods, keeping the generic interface intact.

Key Takeaways for Robust Frontend Architecture

Practice	Principle	Rationale
Name Generically	Domain Language Over Technology: Use names like `userService` or `paymentService`, not `clerkAuthService` or `supabasePosts`.	The name reflects the domain concept, not the implementation detail.
Standardize Data	ACL Responsibility: The service layer must convert the library's output (e.g., a complex object with metadata) into the exact clean object your app needs.	The rest of your application code deals with a single, predictable data format.
Error Handling	Translate Errors: Catch library-specific errors and re-throw them as simple, standardized application-level errors (e.g., a `DataFetchError`).	Components only need to handle a few generic error types, simplifying UI feedback.
Apply Universally	Systematic Abstraction: If you use a library, abstract it. This applies to data access, state management, auth, analytics, utility functions, and more.	Maximizes code agility, testability, and reduces maintenance complexity across the board.

By committing to this principle of universal abstraction, you build a frontend application that is architecturally sound, easier to test, and perfectly positioned to adapt to the technological shifts of tomorrow.

What the Heck Are EIPs and ERCs? A Beginner’s Guide to 4 Ethereum Upgrades You’ve Never Heard Of

Thu, 17 Jul 2025 19:21:14 +0000

They might not trend on Crypto Twitter—but without them, Ethereum wouldn't run this smooth. - Allan Robinson

What Are EIPs and ERCs?

EIPs (Ethereum Improvement Proposals) are Ethereum’s official feature requests or improvements, typically targeting protocol-level changes (e.g., transaction formats, gas fees).
ERCs (Ethereum Request for Comments) are a subset of EIPs focused on smart contract standards, used to ensure compatible interfaces across dApps.

They emerged as community-driven blueprints to evolve Ethereum in a consistent, transparent, and coordinate-driven way.

History & Impact

The EIP process began with EIP-1 in 2015 to formalize how Ethereum should evolve.
Early successful proposals like EIP-20 (ERC-20) established core patterns for the ecosystem.
Over time, new needs arose: better transaction gas efficiency, clearer contract interoperability, and fairer developer incentives.
Thanks to EIPs and ERCs, Ethereum continues to grow backward-compatible while integrating new features without breaking older systems.

️ Deep Dive into 4 Selected Standards

1. EIP‑2930: Access Lists (Core / Transaction Format)

Overview

Introduced in Berlin (2020) as part of a suite addressing storage cost spikes (alongside EIP-2929)
Lets you pre-declare which contract addresses/storage slots your tx will access.
Those slots are “pre-warmed” at lower cost, avoiding high “cold” access charges.

✅ Benefits

Saves ~200 gas per storage access
Reduces volatility and DoS attack risk from expensive cold storage.

❌ Drawbacks

Requires users/devs to predict exactly which slots will be used—mistakes can cost more gas than savings.
Adoption has been low: just ~1.5% of txs use it despite 42% potential benefit

⚙️ Analogy

Think of it like a grocery preorder: tell the store what you’ll need in advance and skip checkout lines—but if you order the wrong things, you wasted time and money.

2. EIP‑7547: Inclusion Lists (Core / Block Assembly)

Overview

A new proposal letting block proposers force inclusion of specific transactions in a block, reducing censorship
Especially useful for front-running, MEV-resistant applications.

✅ Benefits

Enhances fairness and censorship resistance in the mempool.
Empowers transaction originators to battle MEV-based exclusion.

⚠️ Considerations

Still under development.
Needs client & tooling support to become practical.

⚙️ Analogy

It’s like a VIP pass for users who want to ensure their ticket gets scanned even during rush hour.

3. ERC‑165: Interface Detection (Contract Interface Standard)

Overview

Standardizes how contracts announce which interfaces they implement—used widely since 2018
Contracts implement supportsInterface(bytes4 interfaceID) so others can detect capabilities.

✅ Benefits

Enables dynamic compatibility checks for wallets/dApps.
Avoids hard-coded assumptions, reducing risk of breakage.

❌ Drawbacks

Needs explicit implementation—some contracts skip it to save gas.
Only covers declared interfaces; doesn’t guarantee full compliance.

⚙️ Analogy

Like a software installer that checks if your system supports .NET 6 before installation—no surprises later.

Overview

A new proposal for sharing transaction fees (beyond ETH’s built-in burn/tip) with contract creators
Users opt-in to send a developer fee to the dApp creator on each use.

✅ Benefits

Creates an incentive model for public dApps to be sustainable.
Offers an optional “tip” model for open-source contract authors.

⚠️ Controversies

May discourage usage if tips are high.
Needs to balance opt-in vs auto-fee structures.

⚙️ Analogy

Like paying 10% tip for offline delivery services you trust—optional but appreciated.

Comparison Table

EIP/ERC	Category	Purpose	Adoption Status
EIP‑2930	Core / Tx	Improve gas for predefined access	Low adoption (\~1.5%)
EIP‑7547	Core / Blocks	Censorship resistance via inclusion lists	Early draft
ERC‑165	Interface	Standard method to declare support	Widely adopted (NFTs, tokens)
EIP‑6969	ERC / Payments	Revenue-sharing tips to contract authors	Emerging interest

Final Takeaways

Access Lists (EIP‑2930) streamline gas costs—but you must think ahead.
Inclusion Lists (EIP‑7547) will help fairness in transaction ordering, ideal for censor-resistant apps.
ERC‑165 remains vital for automatic interface compatibility, powering wallet and dApp integrations.
Revenue-sharing (EIP‑6969) introduces an open tipping model, potentially sustaining free-to-use contracts.

Why These Matter for Beginners

Understanding why these standards were invented helps future developers reason about protocol design and usability, not just code.
Seeing each EIP as a solution to a real problem—gas costs, censorship, interface detection, developer sustainability—makes you think like a protocol designer.
Analogies keep concepts memorable and relatable.

Standards aren’t just code—they shape how Ethereum grows. - Allan Robinson

Top 20 Web3 Trends for 2025: Predictions, Tools, and Industry Shifts

Mon, 03 Mar 2025 11:48:29 +0000

Discover the future of Web3 in 2025: 20 expert predictions on trends, tech, and innovations that will shape the decentralized revolution.

This article provides 20 expert, on-the-ground predictions that paint a compelling picture of where Web3 will go in 2025. Each prediction gives insight into the moving trends in Web3, technologies that charge, and the shifting of policy that moves the needle in the ongoing development of the decentralized economy.

A New Era of Crypto Adoption: The Main Trends in Web3

Prediction 1: The U.S. Will Establish Bitcoin as a Strategic Asset

The 2024 elections reversed the landscape as far as the US government was concerned through a change of guard led by Joe Biden. So far, the administration led by Donald Trump has made one pro-cryptocurrency appointment after another to top-level government positions. Notable appointments are Vice President JD Vance, Michael Waltz as National Security Advisor, and Mary Bessent as Treasury Secretary, with other key financial hires such as Paul Atkins installed at the SEC to Jelena McWilliams at the FDIC.

The appointments are key shifts away from restrictive crypto policy and, more broadly, new recognition of Bitcoin as a strategic financial instrument.

Prediction 2: MiCA Policy Will Reshape the Crypto Landscape in Europe

The Markets in Crypto-Assets, or MiCA, will fully come into effect in 2025, establishing a single regulatory regime for crypto-assets throughout the European Union. MiCA aims to better protect investors and promote innovation while creating more transparency and accountability within the crypto market.

While these regulations are aimed at devising a stable and secure environment for market participants, this will also set a higher bar both for CEXs and custody services, possibly entailing major operational changes for such market participants due to increased legal requirements and more resources allocated toward compliance. Meanwhile, MiCA would rather attract institutional investors who value regulatory clarity and safety, boosting the legitimacy of Europe's crypto market.

MiCA will also set the stage for other regions looking to institute comprehensive crypto regulation and further entrench Europe's leadership position in setting the standard for global crypto policies. This also aligns with trends in Web3, from an increasing focus on decentralization to regulatory compliance and security around digital assets.

Prediction 3: Gold vs. Bitcoin Holdings — Companies and Governments Set for Expansion

This Web3 trend of 2025 suggests potentially large opportunities for both companies and governments to better position their Bitcoin holdings in comparison to gold. Today, private holders dominate Bitcoin ownership at 58.6%, with minimal adoption by governments (2.6%) and public companies (1.5%). In contrast, gold is more integrated into governmental reserves at 13.7% and institutional vehicles such as funds/ETFs at 5.3%.

With only 20% of Bitcoin's supply left to be mined amidst rising adoption narratives, we anticipate increased entry by institutional players toward Bitcoin, closing the ownership gap that currently exists in favor of gold. This shift will solidify Bitcoin as a strategic asset class, either alongside or replacing gold, in corporate treasuries and government reserves globally.

Web3 Market Growth Predictions

Prediction 4: The Crypto Bull Market Will Hit Its First Peak in Q1 2025 and Reach New All-Time Highs in Q4 2025

The crypto market in 2025 is expected to follow a two-peak cycle pattern. The first major surge is anticipated in the first quarter, driven by growing institutional adoption, improved scalability solutions, and increasing investor confidence in blockchain infrastructure. At this stage, we project Bitcoin (BTC) to reach around $130,000 and Ethereum (ETH) to exceed $5,000.

Prediction 5: DEX Tokens Will Experience Significant Growth

Stricter regulatory policies against centralized exchanges, one of the main trends in Web3, will increase the rate of adoption and growth in DEX tokens. As more users and traders look for other options away from the CEX platforms, the demand for the DEX tokens will definitely go up, adding to their value.
The only exception could be PancakeSwap, a subsidiary DEX of Binance, given its closeness to the centralized exchange.

Scalability and Layer 2 Innovations

Prediction 6: Over 2,000 Ethereum Layer 2 and Layer 3 Scaling Solutions Will Be Live

The roll-up-centric scaling roadmap is on the verge of completely overturning Ethereum. Application-specific rollups will begin emergence for gaming, DeFi, payments, and, yes, socials, in addition to a 17x increase in Ethereum's scalable infrastructure. Lastly, expect "corporate L2s" driven by enterprise actors such as Coinbase or Kraken to grow on-chain adoption and further reveal increased modularization of Ethereum as a whole.

Trends in Web3 indicate that the scaling factor, or total daily average UOPS, or TPS of all Ethereum scaling solutions, compared to Ethereum L1, comes at around 25x. If these projections are met, this would increase eightfold over its current value to over 200x. This growth will be partly achieved through the scaling of existing rollups but also by the emergence of new L2s and L3s.

Prediction 7: Web3 Trends 2025 Suggest that Layer 2 Solutions Will Thrive Alongside DeFi Growth

With the ever-tightening regulatory environment in the crypto space, Layer 2 solutions are set to see an exponential surge in the next year. The Crypto Travel Rule and MiCA will likely force liquidity and users onto decentralized platforms, ultimately forcing a shift from centralized entities into the DeFi ecosystems, which will create demand for DeFi tokens and platforms.

Trends in Web3 indicate that users will start seeking higher levels of scalability by looking more towards low-fee transactional fees with faster times of execution. It would make this more appealing with Arbitrum and Optimism, who have lowered costs and attained higher speed. These are solutions that address the necessary scalability of DeFi platforms to be able to satisfy growing demand from users. This means much of the growth in such adoption could result in this Layer 2 blockchain gaining a substantial market share and, therefore, setting it up for strong growth in the coming year.

Prediction 8: Solana will surpass 5,000 TPS for non-voting transactions

In fact, the performance of Solana's network will increase manifold over the coming year, with non-voting transaction throughput in the network estimated to rise above an average of 5,000 TPS by 2025. That is around 6-7x the current average of 700-800 TPS and really a testament to how well the Solana network has scaled so far, given its demand for applications in areas such as DeFi, meme coin speculation, and DePIN.

Prediction 9: Over 90% of Layer 2 Solutions Will Adopt Decentralized Data Availability Layers

While the development of Layer 2 solutions is continuously improving, the adoption of decentralized data availability (DA) layers is becoming more and more prevalent. By 2025, more than 90% of L2 solutions are expected to incorporate decentralized DA layers in their quest for scalability, security, and efficiency.

Trends in Web3 show that decentralized DA layers ensure that transaction data is reliably stored and accessible, therefore mitigating risks associated with data withholding and enhancing overall integrity at L2. Three of these projects, Celestia, EigenDA, and Avail, offer decentralized DA solutions by taking to modular architecture to separate consensus, execution, and availability for better performance of blockchains.

Decentralized DA layers solve the data availability problem native to the rollup-based solution, where the data must be available for off-chain transactions to prevent fraud, ensuring verifiability in L2 solutions. Shifts to decentralized DA layers enable L2 solutions to, for the first time ever, achieve high throughput without sacrificing robust security standards with low costs.

Advancements in ZK Proofs and Security: Web3 Trends 2025

Prediction 10: Every Ethereum block will be ZK-proofed

ZKPs are supposed to revolutionize blockchain in terms of security and scalability. Due to the functionality of enabling verifiable computation, not at the expense of data disclosure, ZK proofs represent a strong tool for keeping Ethereum blocks in check. This will ultimately mean secure and efficient ways of validation across all nodes with minimum computational overhead. Once ZK technology develops a bit more, that will be a reality: this milestone will further enhance Ethereum's infrastructure.

Prediction 11: Over 95% of ZK proofs will be generated through decentralized nodes

Decentralized proof generation is increasingly becoming a staple, ensuring a highly scalable and trustless model for the centralized one. By utilizing a decentralized network, proof generation becomes far more cost-efficient and censorship-resistant. Trends in Web3 suggest that in this shift, almost all the ZK proofs across blockchains will come from decentralized nodes, which would lower the operational risk and widen the mainstream adoption of zero-knowledge technology.

Data Privacy & Security in Web3

Prediction 12: Privacy-preserving blockchain applications will become mainstream

Increased innovation in privacy-enhancing technologies shows the importance of privacy in blockchain ecosystems. Web3 trends indicate that by 2025, privacy-preserving applications will be at the heart of Web3. Zero-knowledge proofs, multi-party computation, and fully homomorphic encryption are technologies that would enable users to transact, collaborate, and share data without giving up confidentiality. These will further open use cases around private DeFi transactions, secure voting systems, and enterprise-grade data sharing, making privacy part and parcel of the blockchain experience.

Prediction 13: Decentralized VPN networks will capture 15% of the global market

dVPNs are becoming a pretty viable alternative to traditional virtual private networks, affording substantially improved privacy and censorship resistance assurances. Some examples of dVPN solutions, such as NymVPN and others, will make use of advanced encryption, traffic obfuscation, and decentralized node infrastructures in order to preserve user anonymity via blockchain technology. In a world with a growing demand for online privacy, driven by increased surveillance across the world, dVPNs will capture an increasingly big chunk of the VPN market, reaching up to 15% adoption by 2025, and disrupt the traditional centralized VPN industry.

Web3 Trends 2025: Consensus Protocols & P2P Networks

Prediction 14: A major blockchain network will adopt DAG-based consensus

DAG-based consensus can be a game-changing alternative in the field of traditional blockchain structures such as proof-of-stake and proof-of-work. Web3 trends highlight that since DAG does not need to create blocks sequentially, it can scale much higher with less latency. This architecture will already be used by some newcomers like Aptos, Sui, and Aleo for thousands of transactions per second.

At some time in 2025, the migration of one leading blockchain network to DAG-based consensus should provide transaction speedups of up to 3-5 times higher than more classic variations of the PoS setup. This would also add demand for scalability solutions, and by these, an increase in demand would come with the more considerable adaptation of DAG technology, which should ease congestion of its quite sought-after network and power applications needing the best real-world low-latency solutions such as gaming, DeFi, and high-volume instant settlements.

Prediction 15: QUIC-based decentralized security standards will emerge

The QUIC protocol, designed by Google, provides a faster and more reliable way of establishing connections. It is now being adapted to blockchain networks such as Solana and Sui. With QUIC, nodes can communicate with low latency and stronger security, enabling faster transaction finality and better resistance to attacks like DDoS.

Trends in Web3 suggest that by 2025, the use of QUIC-based protocols as a general standard is expected to prevail, especially with the rise of high-throughput blockchains. This shift is projected to reduce latency for P2P communications by 30% and improve transaction finality time by 20%, ensuring a smoother user experience and greater network reliability.

Web3 User Experience Evolution

Prediction 16: Rollup-powered apps will feel like L1 experiences

Rollups are considered one of the critical solutions for Layer 2 scaling and are leading into the next era of user-centric decentralized apps. Trends in Web3 indicate that while ensuring security is maintained through Ethereum, rollups offload a significant portion of computation from Layer 1. This approach keeps operations both cost-effective and fast. On a daily basis, rollups such as Arbitrum and Optimism handle millions of transactions at costs averaging 90% lower than Ethereum L1.

By 2025, rollup-powered applications are expected to achieve over 10,000 TPS, with transaction fees dropping to just pennies. This advancement will make dApps virtually indistinguishable from traditional web apps, paving the way for broader mainstream adoption and engagement.

Prediction 17: Over 30% of blockchain transactions will involve chain abstraction layers

Larger multi-chain ecosystems will likely need robust cross-chain interoperability in the future. Platforms like LayerZero and Axelar already have a chain abstraction layer that makes it easier to interact with different blockchains. These layers drive a seamless user experience, where you can swap tokens between chains or run cross-chain smart contracts without any friction.

With Web3 trends persisting on forays into 2025, chain abstraction layers are revolutionizing the blockchain world. With an increasing demand for simplified user experience and higher blockchain interconnectivity, more than 30% of all blockchain transactions are expected to be handled by means of chain abstraction layers. That’s a 15 percent increase above previous numbers. While the Web3 apps are as super simple as Web2 apps, by seamlessly integrating with chain abstraction, we further accelerate mainstream adoption.

Shifts in Blockchain Usage and Market Trends

Prediction 18: The NFT Market Will Recover, Reaching $30 Billion in Trading Volume

Having been badly hit by the bear cycle in the financial year 2022-2023, the NFT marketplace is expected to stage a remarkable recovery in 2025. It has decreased to 39% since 2023 and by 84% since 2022, but it has been picking up as the market moves from pure pump-and-dump schemes to actual community and culturally relevant projects. Such collections are at the forefront of this revival and include Pudgy Penguins, Miladys, and Bored Ape Yacht Club (BAYC).

We project NFT trading volumes to reach $30 billion in 2025, driven by:

The rise of a new generation of crypto-rich will cause people to look at NFTs as artworks or important historical artifacts rather than bubbles.
The fact that there are still collections like CryptoPunks and Bored Ape Yacht Club attracting attention and demand.
Ethereum’s increasing share of the NFT market share to trade 85% of NFTs in 2025 from 71% in 2024.

Such recovery lies still below the numbers of 2021 trading volumes and shifted more towards sustainability and relevance to the culture. While oftentimes, the primary use of NFTs is being reimagined as collectibles, cultural assets, and brands, the industry is set for a steadier and logically consequent phase.

Conclusion: A Web3-Powered Future

The revolution of Web3 is real; it is happening, and it is real. Web3 is creating the path for an epochal time in the digital technology world: from privacy-focused innovations to breakthroughs in scalability and the advent of decentralized platforms. Web3 is all the buzzwords painted out, but trends in Web3 are more a glimpse into the future than just the newest internet vernacular. The internet is no longer necessarily more open and accessible but inherently more secure and efficient, which, in turn, opens new possibilities.

As blockchains’ ability to scale continues to improve, Ethereum’s rollup-focused roadmap provides unmatched transaction throughput, which Solana and Layer 2 solutions are now taking to completely new levels of blockchain performance. Zero Knowledge proofs (ZKPs) democratize privacy and security. According to Web3 trends 2025, the crypto landscape will pick up its pace as more people shift from speculation to real-life value and utility through decentralized applications and platforms.

Why Choose Generis: Your Web3 Growth Partner

At Generis Web3 Agency, we’re leading the Web3 revolution by helping projects thrive in the crypto world through bespoke solutions. We leverage our technical expertise with strategic insight to empower our clients to understand blockchain technology and lead in their space.

Coder Legion - Recent posts tagged decentralization

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

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: Building a Decentralized Future

From Two Developers to a National Digital Network: Can We Build an Internet That Belongs to Its Participants?

What if we stopped building platforms and started connecting independent people?

1. Decentralization without interoperability is just fragmentation

2. Our first practical experiment: the Node Bridge

3. Local AI could change who controls information

4. What about Tor?

5. Digital identity must become portable

6. Can knowledge become independently verifiable?

7. Why our experiment also includes a comic

8. A nationwide ecosystem needs governance, not just servers

9. There is no sustainable decentralization without an economy

10. The regulatory challenge

11. Five stages from laboratory to possible national adoption

Stage 1: Build and verify

Stage 2: Invite independent participants

Stage 3: Create regional federation experiments

Stage 4: Investigate institutional integration

Stage 5: Support wider adoption

12. The most important metric is independence

Conclusion: The future does not need another digital empire

Explore MyZubster

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics and Verifiable Knowledge

What if the next Internet belonged to its participants?

1. Two developers, two independent environments, one shared experiment

2. When software development becomes a comic

3. Building the bridge between two independent computers

The bug that changed our implementation

4. Where Tor enters our vision

5. Decentralization is not a switch

6. The missing piece in digital collaboration: proof of knowledge

7. What could this paradigm change tomorrow?

8. Our next milestone

9. One ecosystem, independent creators

Follow the journey

From Decentralization to Zorgax: How MyZubster Is Connecting AI, Blockchain, NFTs, Communities and

From Decentralization to Zorgax: How MyZubster Is Connecting AI, Blockchain, NFTs, Communities and Real-World Evidence

Data model: events, `kind`, and tags