DEV Community

Daniel Ioni
Daniel Ioni

Posted on

From One Contributor to an Open Knowledge Network: Building MyZubster's Knowledge Graph, Contributor Passports, and Independent Nodes

#opensource #webdev #github #docker

From One Contributor to an Open Knowledge Network: Building MyZubster's Knowledge Graph, Contributor Passports, and Independent Nodes

How our work with Nicola evolved into an open-source experiment connecting GitHub contributions, technical knowledge, verifiable evidence, contributor identity, and new opportunities for collaboration.

By Daniel Ioni — MyZubster

October 2, 2026

1. The problem: open-source contributions generate knowledge, but where does that knowledge go?

Every day, open-source contributors solve problems, investigate bugs, write documentation, create tests, design interfaces, and experiment with new technologies.

GitHub preserves much of this activity through commits, pull requests, issues, reviews, and discussions.

But an interesting problem remains.

A merged pull request tells us that a contribution was integrated into a repository. It does not necessarily explain everything the contributor learned, which methods they used, which challenges they encountered, or how that knowledge might become useful to someone else.

Likewise, a contributor's profile can list programming languages and technologies without explaining what evidence supports those claims.

At MyZubster, we are exploring a different approach:

Contribution → Evidence → Knowledge → Contributor Identity → Collaboration

Our objective is to make technical knowledge easier to document, discover, share, and reuse.

We are not trying to automatically certify people's skills based on GitHub activity. Instead, we are building ways to connect specific knowledge claims to identifiable public evidence while preserving the distinction between a contributor's declaration and independently verified results.

Our latest work brings together several components:

  • An interactive public Knowledge Graph.
  • Knowledge Cards with evidence and verification notes.
  • A Contributor Passport framework.
  • An optional Independent Contributor Pilot Node pathway.
  • Public GitHub contribution records.
  • A Paid Bounties system with explicit funding states.
  • Experimental infrastructure for connecting independent technical environments.

This article explains how these pieces fit together, what we have implemented, and what we are still investigating.

Explore the project:

MyZubster Website | Public Knowledge Graph | GitHub Organization | Main Repository

2. Where it started: working with Nicola (N4K48)

One of our most important practical learning experiences has been our collaboration with Nicola, also known as N4K48.

We have been using this collaboration to explore a fundamental architectural question:

Can someone maintain an independent technical identity and development environment while connecting their work and knowledge to a shared ecosystem?

Rather than treating every contribution as an isolated task, we began documenting the relationship between the contributor, the work performed, the supporting evidence, and the knowledge generated.

Our work has included Docker, GitHub, software testing, knowledge documentation, and experiments with connected development environments.

The Knowledge Card experiment

A Knowledge Card is a structured record describing a particular piece of knowledge or experience.

A useful card should answer several questions:

  1. What knowledge or capability is being described?
  2. Who is making the declaration?
  3. What specific work supports that declaration?
  4. What evidence is publicly accessible?
  5. What has actually been tested or reviewed?
  6. Which claims remain unverified?

For example, a card about Docker should not simply say:

I know Docker.

A more useful record could describe a reproducible Docker environment, link to the associated repository and configuration files, identify the tests performed, and document which parts of the workflow have been demonstrated.

This creates a more transparent relationship between technical activity and claimed knowledge.

Lessons from Nicola's testing

Our experience with Nicola also exposed practical problems that documentation alone cannot solve.

We encountered questions about personal knowledge navigation, authenticated profile access, public visibility, and the synchronization of evidence between different parts of the system.

These experiences informed subsequent changes to our knowledge workflows.

We also developed an experimental MyZubster Node Bridge infrastructure using Docker and HTTPS.

Its purpose is to explore how a remote contributor environment could exchange structured work with MyZubster services.

The server-side infrastructure and initial connectivity checks have been prepared. However, we distinguish those results from a fully validated end-to-end deployment on Nicola's own computer.

That distinction is essential.

A working server endpoint is evidence that one part of a system operates. It is not proof that every distributed component has been successfully integrated.

Relevant project links:

3. Building the public Knowledge Graph

Our next challenge was making this information easier to explore.

A conventional catalog organizes records into separate pages. But knowledge is interconnected.

A contributor may work on several projects. A project can involve different technical domains. Multiple contributions may reference the same public source. A single Knowledge Card can contain evidence from multiple repositories.

A graph provides a way to visualize these relationships.

On October 2, 2026, we integrated an interactive public Knowledge Graph through Pull Request #1438.

The initial implementation connected four types of information:

Knowledge Cards: individual records explicitly published by their owners.

Contributors: public account names associated with published cards.

Knowledge domains: technical or practical fields used to organize the records.

Sources: publicly accessible evidence linked from the cards.

Users can explore the graph, select nodes, examine associated records, and filter information by contributor, domain, or search terms.

Open the Interactive Knowledge Graph

How the graph works

The original implementation fetches public Knowledge Cards from the following endpoint:

GET /api/knowledge-evidence/public
Enter fullscreen mode Exit fullscreen mode

The backend retrieves records that satisfy two conditions:

{
  status: "published",
  visibility: "public"
}
Enter fullscreen mode Exit fullscreen mode

This rule is fundamental to the design.

A private draft should never become publicly visible simply because it exists in a database.

Only explicitly published, public Knowledge Cards are returned by this endpoint.

The frontend then constructs graph relationships using the information exposed by those cards.

Conceptually, the structure looks like this:

                 Knowledge Domain
                        |
                        |
Contributor -------- Knowledge Card
                        |
                        |
                  Public Evidence
Enter fullscreen mode Exit fullscreen mode

An important limitation emerged during implementation: contributors with public GitHub work did not automatically appear in the Knowledge Graph unless they had also published Knowledge Cards.

We decided to address that limitation without weakening the publication rules.

4. Our latest update: connecting public GitHub contributions to the graph

Today, we integrated an additional contribution layer through Pull Request #1453.

The corresponding production deployment has reached the ready state on Vercel.

This update introduces a distinction between two different forms of information.

A. Owner-published Knowledge Cards

These are records that contributors create and explicitly choose to publish.

They can include descriptions, declared knowledge domains, verification notes, and public evidence.

B. Documented public GitHub contributions

These are records of publicly accessible development activities, such as pull requests that have been merged, submitted, or closed without integration.

They can be represented without pretending that the contributor has personally published a Knowledge Card.

The new graph connects these public contribution records to their associated GitHub account names and technical domains.

For example:

                  Testing
                     |
                     |
GitHub Contributor -- Public GitHub PR
                     |
                     |
              GitHub Evidence
Enter fullscreen mode Exit fullscreen mode

The interface explicitly identifies these records as public GitHub evidence rather than personal Knowledge Cards.

Why the distinction matters

A GitHub pull request can demonstrate that someone submitted work.

A merged pull request can demonstrate that work was integrated.

Neither automatically proves every skill listed in a personal profile.

Similarly, an open pull request should not be represented as an implemented production feature.

Our graph preserves these differences.

The public contribution layer also does not expose private contributor profiles, wallet addresses, or settlement information.

For this first version, the GitHub contribution records are a curated snapshot rather than an automatic import of every repository contributor.

The selection and recorded pull request states must therefore be maintained as the underlying projects evolve.

Implementation and evidence:

5. Recognizing existing open-source contributions

One purpose of this work is to make contributions already present in the MyZubster ecosystem easier to discover.

We have begun with several publicly documented examples.

These contributions illustrate different technical domains and different states of completion.

NFC, testing, and the Animal Registry

Contributor @jdjioe5-cpu has several documented contributions within our Animal Registry project.

Their public work provides examples of knowledge associated with:

  • Browser-based NFC simulation.
  • NFC tag design and documentation.
  • API and integration workflows.

These are useful subjects for separate Knowledge Cards because each contribution describes a distinct technical or practical activity.

Explore the source material:

Geolocation and community gardens

Contributor @leanworld7-netizen has a merged contribution addressing garden geolocation and area-based search.

This work offers a practical example of how backend development can support a real-world domain.

The documented contribution involves geographic search, garden-related data, and supporting tests.

Explore Garden Geolocation — PR #57

Telemetry and monitoring

Contributor @laurentketterle-hub has a merged contribution related to the Space Station telemetry dashboard.

This provides a foundation for documenting frontend development, telemetry visualization, status monitoring, and the handling of API information.

Explore the Telemetry Dashboard — PR #399

Another contributor, @Aming9303, has submitted work on a secure Space Station telemetry dashboard.

That contribution must remain identified as submitted work until its integration status is confirmed.

Explore the Submitted Dashboard — PR #531

Automated testing

Contributor @foxxx009 has a merged contribution involving automated tests for GitHubMonitor.

Testing contributions are especially valuable as knowledge records because they document not only an implementation, but also methods for checking system behavior.

Explore GitHubMonitor Tests — PR #259

Documentation and metaverse development

Not every contribution is merged.

We also want to preserve the history of work that was submitted but not integrated.

Examples include:

These records must be clearly identified as closed without merge.

They remain useful as historical documentation, but they should not be confused with features incorporated into the main project.

Our objective is to preserve accurate evidence rather than create artificial achievement records.

6. Introducing the Contributor Passport

Documenting isolated contributions is useful.

Connecting them into a coherent contributor history may be even more valuable.

This idea led us to develop our Contributor Passport framework.

A Contributor Passport is intended to connect a person's documented contributions, associated knowledge records, and supporting evidence.

We integrated the framework through PR #1445.

The proposed progression is:

Accepted Contribution
          |
          v
    Public Evidence
          |
          v
     Knowledge Card
          |
          v
 Contributor Passport
          |
          v
 Optional Pilot Node
          |
          v
  Future Contributions
Enter fullscreen mode Exit fullscreen mode

This is a framework for organizing information and future collaboration, not an automatic credentialing system.

Why participation is optional

A contributor should be able to participate in an open-source project without being required to publish a detailed personal profile.

A public GitHub contribution does not constitute consent to publish private wallet addresses, transaction histories, or personal information.

Likewise, participating in a paid task should not automatically enroll someone in an unrelated program.

For that reason, we separate:

  • Participation in GitHub development.
  • Publication of personal Knowledge Cards.
  • Creation of a Contributor Passport.
  • Optional enrollment in an Independent Contributor Pilot Node.
  • Agreements for compensated work.

Each activity has its own requirements and appropriate boundaries.

Read the Contributor Pilot Node Framework

7. Independent Contributor Pilot Nodes

An interesting next step is allowing contributors to organize their own development activities while maintaining connections to shared knowledge.

We call this concept an Independent Contributor Pilot Node.

The purpose is not to turn every contributor into a centrally managed worker.

Instead, the framework explores whether independent contributors can maintain their own scope, development roadmap, and documented results while exchanging relevant knowledge with the wider MyZubster ecosystem.

For example, a contributor might eventually maintain a specialized experimental project focused on:

  • API testing.
  • Robotics and telemetry.
  • Environmental monitoring.
  • Education and knowledge documentation.
  • Web accessibility.
  • Other technically relevant domains.

Their activity could be connected to public evidence and knowledge records without requiring all development to happen in one repository.

Contributor @wasim-builds has already posted an explicit Pilot Node opt-in in the discussion associated with their contributor character.

This establishes an expressed interest in the pathway. It does not, by itself, prove that an independent node has already been provisioned or deployed.

Wasim Contributor Character — PR #637

The next development challenge is turning the framework into reproducible onboarding, clear responsibilities, and verifiable technical milestones.

8. Paid Bounties: connecting defined work to explicit rewards

We have also developed a public Paid Bounties page.

Explore MyZubster Paid Bounties

This work was integrated through PR #1444.

Our objective is to make the relationship between proposed work, funding, acceptance criteria, and eventual settlement more transparent.

A fundamental rule is that a proposed reward is not the same as a funded commitment.

Contributors need to understand the financial status of a task before deciding whether to undertake compensated work.

For an agreed paid contribution, the relevant conditions should include:

  1. A defined technical scope.
  2. Clear acceptance criteria.
  3. An identified reviewer.
  4. Explicit funding or reservation status.
  5. An agreed payment method and network, where applicable.
  6. A conversion reference for rewards denominated in USD equivalents.
  7. Responsibility for transaction fees.
  8. A defined payment window.

Payment evidence and technical evidence should remain separate.

A transaction proves a particular settlement occurred. It does not automatically prove the quality or scope of the associated contribution.

Real discussions with contributors

Our current conversations illustrate why these distinctions matter.

Henderson has expressed interest in a separate onboarding activity involving two evidence-backed Knowledge Cards based on previous work.

The relevant onboarding bounty is recorded as reserved for 25 USD equivalent, but the final settlement arrangements still require agreement.

His proposed Tari configuration task is separate and has not been automatically approved through the onboarding process.

Contributor Passport Onboarding — Issue #1447

Tari Configuration Proposal — Issue #1405

Other contributors have submitted preliminary proposals for focused work involving testing, accessibility, and user-interface reliability.

Their technical ideas can be useful even before a compensated engagement is formally established.

However, no proposed task should be represented as completed work or a guaranteed payment simply because a contributor expressed interest.

9. New contributors are also helping us identify real problems

An open-source ecosystem becomes more useful when contributors can report limitations and propose independently testable improvements.

Several recent discussions have highlighted issues that affect the contributor experience.

Improving Knowledge Graph accessibility

Contributor @pythonyx135793 has submitted a technical plan for improving the Knowledge Graph's mobile layout and keyboard accessibility.

The proposed work includes narrow-screen layouts, keyboard interaction, focus visibility, and regression testing.

The contributor also reported observations from an initial browser experiment:

  • GitHub authorization appeared to complete, but the subsequent login transition could not be confirmed.
  • The contributor profile displayed a session-expired message.
  • Guest access to the metaverse worked.
  • Some instructions remained in Italian despite English being selected.

These observations are useful diagnostic evidence, but they do not establish the root cause of every reported issue.

Knowledge Graph Accessibility — Issue #1441

Improving the Paid Bounties experience

Contributors have also proposed targeted improvements to our Paid Bounties interface and its tests.

These include verifying correct routing, distinguishing genuinely empty results from service errors, and testing how the interface displays the funding status of bounties.

Relevant discussions:

Some contributors openly disclose their use of AI-assisted development.

We consider that disclosure important.

AI assistance may support development and documentation, but reproducible tests, accurate evidence, human-defined acceptance criteria, and explicit project review remain necessary.

10. Sharing knowledge across different disciplines

We do not want the Knowledge Graph to become a collection of programming-language labels.

Technical work becomes especially interesting when it connects to real-world problems.

MyZubster includes experiments and proposals across several domains, including community gardens, robotics, environmental monitoring, NFC systems, documentation, and circular-economy applications.

For example, our ongoing Circular Water concept explores how a narrowly scoped environmental experiment could combine authorized measurements, defined baselines, scientific oversight, and traceable digital records.

In the future, an educational experiment might involve collecting observations about soil conditions, irrigation, and plant growth.

A Knowledge Card could then document the method used, relevant sources, software implementation, and limitations of the experiment.

However, environmental impact claims would require appropriate measurements and validation.

A documented observation is not automatically scientific proof of environmental benefit.

Likewise, educational involvement, access to data, water reuse, and institutional participation would require the relevant permissions and safeguards.

The long-term opportunity is to connect engineering knowledge with other disciplines while maintaining evidence standards appropriate to each field.

11. Technical lessons other open-source projects can reuse

Building this system has reinforced several useful engineering principles.

Lesson 1: separate contribution records from personal knowledge claims

Public repository activity can provide useful evidence.

It should not automatically create personal claims on behalf of a contributor.

Our latest graph update represents GitHub contributions separately from owner-published Knowledge Cards.

Lesson 2: model the status of evidence explicitly

An open pull request, a merged pull request, a private draft, and a published Knowledge Card are not interchangeable.

Representing these states explicitly makes the system easier to audit and reduces misleading claims.

Lesson 3: preserve the source

An evidence record should link back to the original pull request, commit, document, or other appropriate source whenever possible.

A summary without its source is significantly harder to review.

Lesson 4: privacy should be part of the architecture

A contributor may want recognition for public GitHub work without publishing payment information or a comprehensive personal profile.

These choices should be independent.

Lesson 5: distinguish a passing test from a complete deployment

Automated tests provide valuable evidence about the cases they exercise.

They do not necessarily prove that all production infrastructure, external services, or remote client environments work end to end.

Document the actual verification boundary.

Lesson 6: knowledge systems need revision mechanisms

Technical understanding evolves.

Pull request statuses change, new evidence becomes available, and earlier descriptions can become outdated.

Knowledge records should support correction and updating without silently rewriting their history.

Lesson 7: make the system useful before making it complicated

Start with a small, inspectable record:

{
  "title": "A documented technical contribution",
  "domain": "Testing",
  "description": "A precise description of the work",
  "evidence": [
    {
      "type": "public_github_pr",
      "url": "https://github.com/organization/repository/pull/123"
    }
  ],
  "verificationNote": "Public source available; broader skill claims have not been independently verified."
}
Enter fullscreen mode Exit fullscreen mode

This is an illustrative example, not a complete representation of MyZubster's production data model.

The important principle is that every field should have a clearly understood meaning.

12. What we have implemented and what comes next

We believe transparency about project maturity is part of sharing useful technical knowledge.

Implemented or integrated:

  • Public Knowledge Card catalog.
  • Interactive Knowledge Graph.
  • Public contributor evidence layer for selected GitHub contributions.
  • Mechanisms for connecting public GitHub evidence to owner-managed Knowledge Cards.
  • Contributor Passport and optional Pilot Node frameworks.
  • Public Paid Bounties page.
  • Explicit separation between proposed and reserved bounty states.
  • Initial experimental Node Bridge infrastructure.

Still being developed or validated:

  • Broader contributor onboarding and publication of personal Knowledge Cards.
  • Actual provisioning and end-to-end testing of independent contributor nodes.
  • Improved authentication and accessibility across contributor interfaces.
  • Continued maintenance of public GitHub contribution records.
  • New scientific and environmental experiments subject to appropriate partnerships, permissions, and validation.

We will continue distinguishing implemented software, experimental infrastructure, contributor proposals, and validated results.

That distinction is not a limitation of the project's vision.

It is part of making the vision credible and reusable.

13. Join the experiment

If you are interested in contributing, exploring our implementation, reviewing our technical decisions, or developing your own evidence-backed knowledge records, you can start here.

Explore the ecosystem

You do not need to enroll in a Pilot Node or publish a personal profile to contribute code, tests, documentation, or ideas.

We welcome contributions with clear scope, reproducible evidence, honest disclosure of methods, and respect for other contributors' privacy.

Final thought

GitHub already gives open-source communities powerful mechanisms for collaborative development.

Our experiment asks what happens when we make the knowledge behind that development easier to understand and connect.

We began by documenting practical work with Nicola.

We expanded the approach to existing GitHub contributors.

We introduced a public Knowledge Graph, a framework for contributor histories, and mechanisms for linking technical work to its supporting evidence.

Now we want to explore how these pieces can help independent contributors build, share, and preserve useful knowledge together.

Our goal is not simply to record what people say they know. It is to make the relationship between contribution, evidence, and knowledge visible.

And we are building that process in the open.

MyZubster is an evolving open-source project. Features and experiments described here have different maturity levels. Linked GitHub records provide primary technical references; participation in experimental pathways, funding proposals, and future integrations should not be interpreted as completed deployments or guaranteed agreements.

Top comments (0)