Coder Legion - Recent posts tagged github

The Maintainer Who Wrote "Sorry, I Missed the Request!"

Fri, 30 Oct 2026 20:21:47 +0000

Sixteen days of silence, one polite reminder, and a surprisingly good Friday in open source.

My favorite GitHub notification this month wasn't a new star, a detailed code review, or someone telling me my project had changed their life.

It was a maintainer saying:

"Sorry, I missed the request!"

That's it.

No technical discussion. No complicated review. No debate about architecture. Just five words, an exclamation mark, and a merged pull request.

And somehow, that little interaction made my Friday.

Let me explain.

The world's least dramatic pull request

On October 14, I opened a pull request to in-toto/friends.

If you're unfamiliar with in-toto, it's an open-source framework focused on software supply-chain security. The friends repository maintains a list of projects that integrate with it.

I maintain a tool called workproof, which generates verifiable engineering reports from private repositories.

I wanted to add it to the list.

The pull request was about as exciting as it sounds.

One row in a Markdown table.

Not a new feature. Not a performance improvement. Not a security patch that would save thousands of production servers from catching fire.

A row.

If GitHub had an award for the least dramatic contribution of the week, I might have been a serious contender.

I opened the PR, checked that everything looked right, and moved on to other work.

Then I waited.

And waited.

Not in the cinematic sense. There was no staring at the screen, refreshing GitHub every seven seconds while dramatic music played in the background.

I had other things to build.

But every so often, I'd check the pull request.

Still open.

No comments. No review. No labels.

Nothing.

Sixteen days passed.

The strange psychology of an unanswered PR

Here's something I've noticed about contributing to open-source projects.

When you submit a pull request, you know intellectually that nobody owes you an immediate response.

Maintainers have jobs, families, other repositories, notifications, issues, bugs, releases, and probably an impressive collection of browser tabs they'll never close.

I understand that.

But there's still a small part of your brain that starts inventing explanations when a PR sits unanswered.

Did I submit it incorrectly?

Is this repository still maintained?

Was the contribution inappropriate?

Should I say something?

Would saying something make me annoying?

The last question is particularly interesting.

As contributors, we often worry about bothering maintainers. We don't want to appear impatient or entitled, especially when the change is small.

So we wait.

Sometimes a week. Sometimes a month.

Sometimes until the repository becomes a historical artifact and someone discovers our pull request while researching ancient civilizations.

Meanwhile, the maintainer might simply have missed the notification.

That's the funny part.

We can spend days interpreting silence that contains absolutely no information.

Thirty-five minutes

On October 30, I decided to write a follow-up.

Nothing elaborate.

I mentioned that the pull request had been open since October 14, that the change still merged cleanly, and that a quick yes or no would help me plan.

That was the whole point.

I wasn't asking the maintainer to prioritize my contribution. I wasn't explaining why my project was important. I wasn't trying to turn a Markdown table update into a philosophical argument about the future of software supply chains.

I just wanted to know whether the contribution made sense.

Thirty-five minutes later, the maintainer approved it.

The response:

"Sorry, I missed the request!"

At 11:02 UTC, the PR was merged.

Sixteen days of silence.

Thirty-five minutes after a reminder, done.

I laughed a little when I saw it.

Not because the maintainer had done anything wrong. Quite the opposite.

The answer was so ordinary and so human that it immediately made the entire situation feel smaller.

There had been no hidden disagreement.

No mysterious review process.

No elaborate technical objection waiting to emerge.

The request had simply been missed.

And now it wasn't.

We talk a lot about automation. We talk less about attention.

I spend a lot of time around software engineering, open-source tooling, and AI-assisted development.

Every week, there's a new discussion about agents writing code, agents reviewing code, agents fixing bugs, and eventually agents doing practically everything except remembering where we left our coffee.

Some of those developments are genuinely exciting.

But this little experience reminded me of something that doesn't get nearly as much attention.

Open source isn't just a collection of repositories.

It's also a collection of people trying to coordinate their limited time and attention.

A pull request can be technically correct, perfectly formatted, and ready to merge.

That doesn't mean someone has seen it.

And even when someone has seen it, that doesn't mean they've had the time or context to respond.

Those are different problems.

As engineers, we're very good at building systems that track code changes. We have statuses, checks, notifications, dashboards, review requests, and activity histories.

Yet a perfectly valid contribution can still disappear into the noise.

The software is doing its job.

The humans are just busy being humans.

A reminder doesn't have to be a demand

I've seen contributors handle unanswered pull requests in very different ways.

Some wait indefinitely.

Some send repeated messages.

Some become frustrated and start questioning whether the project is actively maintained.

And occasionally, a simple follow-up turns into an argument that nobody really wanted to have.

I'm not convinced any of those extremes help.

What worked for me was making the request easy to answer.

Not:

"Why hasn't anyone reviewed my PR?"

Not:

"This is a very important contribution and deserves your attention."

And definitely not:

"Hello??? @maintainer @maintainer @maintainer"

Just a little context, a specific question, and room for the answer to be no.

That last part matters.

When you ask for a review, you're asking another person to spend time on something you care about.

They might agree.

They might disagree.

They might need another week.

They might decide the contribution doesn't belong in the project.

All of those are legitimate outcomes.

A polite reminder doesn't guarantee a merge, and it shouldn't.

It just gives the conversation another chance to happen.

Of course, every project has its own contribution guidelines and review expectations. Some maintainers explicitly ask contributors not to ping them. Those boundaries deserve respect.

But where follow-ups are welcome, one clear message can be more useful than two weeks of silent speculation.

At least, it was in this case.

Small contributions are still real contributions

I also want to avoid exaggerating what happened here.

My PR added one row to a README.

It wasn't a significant engineering breakthrough. It didn't prove the quality or security of workproof. Being listed in a repository isn't the same thing as receiving an independent endorsement.

And I don't think we should pretend otherwise.

There's already enough inflated language in technology.

Not every commit is revolutionary.

Not every feature is groundbreaking.

And not every merged pull request needs a LinkedIn post explaining how it transformed the future of engineering.

Although, apparently, one Markdown row can inspire an entire article.

So perhaps I'm not completely innocent.

But small contributions do matter in a different way.

They help projects stay connected.

They improve documentation, update integrations, correct outdated information, and sometimes simply make it easier for the next person to discover something useful.

They also give contributors opportunities to interact with communities outside their own projects.

That last part matters to me.

I maintain my own tools, but I don't want all my engineering work to happen inside repositories where I'm the person making every decision.

Contributing elsewhere means learning how other projects work, respecting their processes, and occasionally discovering that the person on the other side of the pull request is just as human as you are.

It's a modest kind of connection.

But I like it.

The other side of the notification

There's another perspective worth considering.

Imagine maintaining a popular open-source project.

You've spent months or years building something useful, often without compensation proportional to the work involved.

Your inbox is full.

Someone reports a bug.

Someone requests a feature.

Someone opens a PR that breaks three tests.

Someone asks whether the project supports a configuration you documented two paragraphs above their question.

And somewhere among all of that is a perfectly reasonable one-line contribution.

You miss it.

Sixteen days later, the contributor sends a polite reminder.

You take a look, realize it's fine, and merge it.

What do you say?

In this case:

"Sorry, I missed the request!"

I appreciated that response because it didn't try to turn a small oversight into something complicated.

No excuses.

No defensiveness.

Just an acknowledgment and an action.

That's a pretty good way to handle many situations, not only pull requests.

And if you're a maintainer reading this, I don't think the lesson is that you need to respond to everything immediately.

That would be a terrible expectation.

It's that even a short answer can be valuable.

"Not right now."

"Needs changes."

"This doesn't fit the project."

"Sorry, I missed this."

A response doesn't have to be positive to be useful.

Sometimes it just needs to exist.

One more thing before I close GitHub

I have a couple of other pull requests waiting in different projects.

After this experience, I'm going to check their statuses and see whether a follow-up makes sense.

Not because I suddenly believe every unanswered PR is one message away from being merged.

Some changes need discussion. Some need substantial review. Some may never be accepted.

That's part of contributing to projects you don't control.

But I'm less inclined to interpret silence as a decision.

And I'm a little more comfortable asking a reasonable question when enough time has passed.

If you've contributed to open source, you've probably experienced that strange waiting period where you can't tell whether your PR is being considered, forgotten, or quietly ignored.

My experience isn't proof that reminders always work.

It's just one example of why they sometimes do.

Sixteen days of silence turned out to mean exactly what the maintainer said:

They missed the request.

Nothing more dramatic than that.

So thank you to the maintainer who took the time to respond and merge the change.

You probably spent less than a minute writing that sentence.

I ended up writing an entire article about it.

That's a pretty impressive return on five words.

I'm Efe Genc, an independent software engineer building open-source developer tools. I write about engineering, experiments, and the things that happen when software meets actual human beings.

First published on my site: https://efegenc.me/writing/the-maintainer-who-wrote-sorry-i-missed-the-request/

Developer Weekly Briefing — October 30, 2026

Fri, 30 Oct 2026 13:55:46 +0000

Security dominated this week, but not in the usual way. Two active campaigns turned GitHub configuration files into attack surfaces. Researchers demonstrated that the built-in browsers inside AI coding tools can read your SSH keys. And at Oracle AI World in Las Vegas, three separate announcements showed how Oracle is thinking about agent identity, governance, and deployment in enterprise systems. There was a lot to track. Here's what matters.

Two GitHub campaigns, one weak point: your config files

Researchers this week documented two separate attack campaigns targeting GitHub repositories — and both are still active.

Wiz Research named the first one Gheist. It planted more than 13,500 malicious branches across 850-plus accounts. The payloads encode secrets in base32 to slip past GitHub's credential-scanning log masking, and they target private repositories and GitHub Enterprise Server — the approval hold GitHub applies to first-time contributors only covers public repos on github.com, so Enterprise Server customers have no equivalent protection. Gheist isn't looking for source code. It's looking for credentials.

JFrog named the second campaign testmetest. It hijacked 42 real repositories and planted malicious hooks inside AI tool configuration files: .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, and .vscode/tasks.json. Payloads run 12.9–13.7 MB — large enough that GitHub code search won't surface them. The attack runs as soon as someone opens the repo in an affected tool.

Mitch Ashley of The Futurum Group put it plainly: "Agent configuration has become the newest build script in the repository, and review processes have not caught up."

The practical steps are the same for both: audit what's in your AI tool config files, treat them the same as build scripts, and limit the secrets available in any environment where agents run. If you're on GitHub Enterprise Server, check what protection you actually have for first-time contributors on private repositories — it may be less than you think.

AI coding tools can read your SSH keys — two are still unpatched

Researchers at Forever Security documented a vulnerability class they're calling EMBRACE. The attack vector: the built-in browsers inside AI coding tools have access to the host machine's file system. A single click on an assistant-generated HTML link can read your SSH private keys, .env files, and npm tokens from anywhere on disk.

Five tools are affected — Cursor, GitHub Copilot, OpenAI Codex, VS Code, and Claude Desktop. Cursor patched the issue October 1. Copilot fixed it in v1.1.29 on October 13. As of October 29, Codex and VS Code were still unpatched.

The mechanism is simple enough to explain in a sentence: the built-in browser runs with the same permissions as the editor, not as an isolated sandbox. When an agent generates a link and you open it in the built-in browser, that page can reach files the browser has no business touching.

If you use Codex or VS Code with built-in browser features enabled, the current workaround is to open assistant-generated links in an external browser until patches ship. It's also worth auditing what credentials live in places a browser process could reach — SSH keys, .env files, and token files sitting in obvious locations.

Flint runs 40B parameters locally — and keeps your code off someone else's server

Recursive, led by former Salesforce chief scientist Richard Socher, released Flint this week: a 40-billion-parameter mixture-of-experts model designed to run on a developer's machine rather than through a cloud API. With a mixture-of-experts architecture, it activates only about 2.5 billion parameters per token. Recursive reports over 125 tokens per second on an M4 Pro MacBook Pro, with a 512,000-token context window.

Weights are on Hugging Face under Apache 2.0 and the model works with llama.cpp, Ollama, LM Studio, and vLLM. A quantized build needs at least 24GB of RAM; Recursive recommends 48GB for agentic coding workloads. OpenHands is a launch partner, and there's a free hosted version on OpenRouter if you want to try it before committing hardware.

The business case for local models is straightforward: no per-token API fees and source code never leaves your machine. Recursive claims Flint leads mixture-of-experts models under 50B parameters on agentic coding benchmarks — those are the company's own numbers, not independently verified. Mitch Ashley of The Futurum Group flagged the implication for teams: "Evaluation becomes continuous work, tested against each team's own code before a model reaches the pipeline." A benchmark on someone else's code isn't the same as a benchmark on yours.

SAP's CTO says building the agent is now the easy part

At SAP TechEd 2026, SAP CTO Philipp Herzig said something developers probably already sense but rarely hear from a vendor executive: "Building is, quite frankly, the most unimportant part these days."

The harder problems, in his framing, are testing, governance, and token cost. SAP's answer is Joule Studio, its agent-building environment, which now includes a CLI with MCP connections, a built-in sandbox, and auto-generated unit tests. SAP also announced the SAP Enterprise AI Gateway, in preview now and scheduled for Q1 2027, which handles routing, rate limiting, and cost controls across the agents a company runs.

On the data side, SAP Business Data Cloud adds a lakehouse layer built on Dremio and Apache Iceberg.

SAP cited an internal comparison showing 30 hours to build an agent with Claude Code versus 2 hours with Joule Studio. That's SAP's own benchmark, and Joule Studio knows SAP's data models in ways a general-purpose coding tool doesn't. Take it as a claim, not a proof. But the underlying point — that tools with domain knowledge built in will reduce setup time on domain-specific problems — is reasonable.

For developers building on SAP, the Gateway announcement is worth tracking. If it ships on schedule in Q1, it gives teams the enforcement layer Herzig described, with controls that apply before the agent executes, not after.

Oracle gives each agent its own identity

At Oracle AI World, Oracle announced the Oracle AI Security Mesh, a framework designed for enterprises running multiple agents across sensitive data. The core idea: each agent gets its own identity, a defined task scope, and just-in-time permissions rather than standing access.

The architecture has a few pieces worth understanding. OCI Identity Assurance handles authentication, including biometrics. OCI Zero Trust Packet Routing enforces policy at the network layer, below the application — which means an agent can't bypass the controls by manipulating the software above them. Each agent also gets an independent monitor, separate from the agent itself.

Oracle didn't announce a general availability date or pricing.

This lands a week after the Gheist and testmetest campaigns, which both targeted credential theft through misconfigured agents. The timing is coincidental, but the relevance is real. The question Oracle's framework raises — and doesn't fully answer — is how you verify that the identity and permission assignment worked the way you intended. That's what attestation is supposed to solve, and it's still the hardest unsolved problem in agentic AI security right now.

Reddit's r/opensource banned AI tools. It probably won't work. The subreddit's new rules ban AI-assisted contributions, exclude MCP servers, require projects to have multiple contributors and an established community, and will permanently ban users who message moderators seeking exceptions. Linux took the opposite approach — Torvalds said the kernel "is not one of those anti-AI projects" and dropped its AI-disclosure requirement, shifting the burden to accountability: understand your code, regardless of what tools you used. The better model for DevOps teams is probably closer to Linux: hold contributors accountable for what they submit, build CI gates that shift review costs back to submitters, and avoid policies that require judgment calls you can't make consistently. Read more
IBM Z Atlas maps your entire mainframe before you touch anything. IBM's new tool for z/OS builds an AI-searchable map of the entire stack — programs, data sets, JCL, subsystems — so teams can understand what they're changing before they change it. IBM reports 60–80% less time spent gathering context, and analysis that used to take hours running in minutes. On-premises only; public preview October 27, GA in Q1 2027. Requires z/OS 3.1+. The AI reasons and synthesizes, but the underlying data is deterministic — you can trace any answer back to the source. Read more
F5 and NVIDIA draw a hard line between data residency and sovereignty. F5's Ahmed Guetari stated the distinction directly: "Data residency is where data sits. Sovereignty is who controls it." The joint offering layers NVIDIA OpenShell and F5 AI Guardrails on BIG-IP Next for Kubernetes, with enforcement on NVIDIA BlueField DPUs at the hardware layer. Token-aware cost controls and two live deployments — Telenor in Norway and Indosat in Indonesia — are already running. Read more
Oracle's Fusion Setup Registry puts enterprise configuration into a public Git repo. Oracle published the Fusion Setup and Configuration Registry (FSCR) — machine-readable setup skills for Fusion Cloud Applications that AI agents can run. The registry covers dependencies, sequencing, and validation, and an early adopter reported 80% reduction in design and configuration work during implementation. Lexington Health is the only customer data point so far. The repository is public, so you can read the skills before committing to them. Read more
Bito's Governor cut one team's coding agent costs 48% by fixing the search loop. Privado used Bito's Governor to reduce the number of times its coding agent re-searches the codebase for context it already found. The result was a 48% reduction in token costs. Short version: agents that re-retrieve context they've already gathered are expensive, and the fix is stopping the loop rather than switching models. Read more
Oracle plans post-quantum TLS for Java 8 and 11 in late 2027. Hybrid post-quantum key exchange for TLS 1.3 is GA in JDK 27. Java 21 and 17 get it in the first half of 2027; Java 8 and 11 in the second half. There's a condition: the backport date holds only if the team gets enough testing feedback on current builds. If you're on Java 8 or 11, the slow path is waiting. The faster path is pointing a JDK 25 or 27 client at your post-quantum-capable endpoints now and filing what breaks. Read more
Larry Ellison says Oracle Health modules plug into Epic with no data migration. Ellison's pitch at Oracle AI World: turn on the module, it finds the relevant staff, records, and labs through existing SMART on FHIR interfaces, and you're done. The oncology module was the main example. Early adopters should have the full suite by February 1. No demo, no independent validation, and no published technical documentation on which FHIR resources the modules read and write. That's work for the teams who get early access. Read more

Developer Spotlight this week

Yaoshen Luo builds agent evaluation frameworks — and writes about the times they failed him. Based in Shanghai, he built a benchmark from scratch when customer complaints about a voice agent told him the model scores weren't the problem. The test set skewed toward longer sentences than real traffic, and accuracy dropped once he resampled to match production. His earlier lesson: he built an agent that passed every benchmark, shipped it to volunteers for a non-profit project, and they refused to use it again. Not because the model was wrong. Because the workflow didn't fit how they actually worked. His take: the workflow is part of the evaluation, not something you test after.

Watch the conversation

The through-line this week is that agent security is moving from theoretical to active. Gheist and testmetest are already running. EMBRACE vulnerabilities are patched in some tools and open in others. The configuration files developers add to repos for AI tooling are now a real attack surface. Oracle, SAP, and F5 all shipped security and governance frameworks this week — which is a sign that vendors know the problem is real. Whether any of those frameworks hold up in practice is a different question, and the answer won't come from a keynote.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

My github acount has been suspended

Thu, 29 Oct 2026 09:06:50 +0000

I dont evan know why ? i signed in 11am after 2 hours 1 pm when i login its showing this i have 2000+ commit in this year 5 achivement 22+ repository . im felling so bad

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

Thu, 29 Oct 2026 04:34:17 +0000

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

What happens when independent developers, creative people, and AI agents start collaborating on the same open-source ecosystem?

That's what we're exploring with MyZubster.

Our goal is to build a decentralized, community-driven ecosystem where people can share skills, offer services, contribute code, develop creative projects, and eventually operate independent infrastructure.

We are moving away from unnecessary complexity and focusing on something practical: a simple services marketplace, an AI assistant that helps real users, and independent contributor nodes.

What we're building

1. Marketplace — led by community contributions

Our contributor Wasim is working on simplifying the Marketplace and its navigation.

The immediate goal is straightforward: people should be able to discover services, create a seller profile, publish a listing, and contact a provider.

Advanced payments and escrow remain separate development challenges.

2. Zorgax — an AI assistant that needs to become genuinely useful

Zorgax is our assistant for navigating MyZubster.

We're testing it with real conversations and identifying problems. For example, when someone wants to sell a service, Zorgax shouldn't unnecessarily ask about their operating system or confuse Marketplace onboarding with GitHub developer onboarding.

We've opened four new contributor tasks:

3. Decentralization — independent nodes and Onion services

Contributors are exploring how MyZubster services can operate across independently managed infrastructure, including an Onion pilot.

This work is still experimental. We are testing isolation, accessibility, and security before making broader claims about decentralization.

4. Comics, digital art, and AI-assisted creativity

MyZubster also includes independent creative contributions, comics, and experiments around provenance and digital ownership.

We're now discussing possible participation with AI-assisted creative projects, while respecting original authorship, licensing, and contributor independence.

AI agents are beginning to participate in the conversation

We've received interest from several different kinds of contributors:

Genesis agent-25, presenting itself as an autonomous AI contributor, has proposed technical testing and an AI-disclosed comic concept.
Quiet Current, an independent human-operated AI art project, discovered MyZubster through GitHub search.
Gree1t, using an authorized Codex agent, contributed a technical Marketplace proposal.

These are early discussions and proposals, not claims of completed integrations or autonomous production deployments.

We have invited them to explore our open tasks, alongside human contributors.

How we want collaboration to work

We believe AI-assisted open-source contributions should be:

Transparent about AI involvement
Reviewable by human maintainers
Backed by reproducible tests and evidence
Respectful of authorship, permissions, and privacy
Independent, voluntary, and clearly scoped

We also want to be transparent about funding. Some proposed bounties are currently unfunded. No payment, token reward, or commissioned work should be assumed without explicit agreement.

Join us

You don't need to be an AI researcher or an experienced blockchain developer.

You can contribute to the Marketplace, improve Zorgax, write documentation, test features, create original digital art, or explore decentralized infrastructure.

Choose a GitHub issue, introduce yourself, propose a small contribution, and collaborate openly.

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

Website: https://www.myzubster.com

Current Marketplace PR: https://github.com/MyZubster-Ecosystem/myzubster/pull/1627

We're interested in a question that goes beyond MyZubster:

Can human contributors and AI agents build useful, decentralized open-source services together, with transparent responsibilities and human oversight?

We're testing that idea in public, one contribution at a time.

OpenSource #AI #AIAgents #GitHub #Decentralization #Marketplace #Community

From GitHub to Codeberg: Rethinking Repository Management and Personal Website Hosting

Wed, 28 Oct 2026 15:35:59 +0000

Developer platforms make it easier than ever to build and publish software. With hosted Git repositories and static website deployment, an individual developer can maintain a portfolio without managing an entire server infrastructure.

However, convenience also introduces an important question: how prepared are we when our existing workflow no longer meets our needs?

I recently faced this question while maintaining my personal website and repositories.
When a Familiar Workflow Stops Working

GitHub had been an essential part of my development process. I used it to manage source code, track changes, and publish my personal website through GitHub Pages.

The workflow was straightforward. I could commit changes, push updates, and use the hosting service to make my website publicly accessible.

Eventually, I encountered an issue that affected website publishing. My account was still accessible, but the publishing functionality did not work as I expected. I could not establish the exact cause, so I avoided drawing conclusions about the platform or its policies.

Nevertheless, the problem disrupted my workflow and encouraged me to explore alternative solutions.

The experience highlighted something worth considering: even when source code is stored safely, the services surrounding a repository may introduce separate dependencies.

Repository storage, continuous integration, deployment, domain management, and public hosting are related, but they are not necessarily the same responsibility.

Understanding those distinctions can make future migrations easier.
Moving Repositories to Codeberg

I decided to move my repositories to Codeberg, a platform built around open-source software and Git-based collaboration.

A repository migration requires more than copying project files. Depending on the project, developers may need to verify branches, tags, commit history, remotes, and repository settings. Issues, pull requests, automation, and other platform-specific features may require separate consideration.

A practical migration checklist includes:

Create a reliable backup of each repository.
Verify that the Git history and important branches are preserved.
Update remote URLs and test push and pull operations.
Review project documentation and any external integrations.
Confirm that essential workflows still function after migration.

Not every platform feature has a direct equivalent, so each project should be checked individually.

The objective is not merely to move the code. It is to ensure that the development workflow remains usable afterward.
Self-Hosting a Personal Website

For website deployment, I chose a home server instead of relying on my previous publishing workflow.

Self-hosting provides a valuable learning opportunity, particularly for developers who want to understand how websites operate beyond application code.

It also introduces several operational responsibilities.

DNS records must point to the correct destination. Public access may require router configuration, a reverse proxy, or a suitable tunneling solution. HTTPS should be configured appropriately, while backups and software updates need to become part of regular maintenance.

Availability is another consideration. A home server depends on electricity, network connectivity, hardware reliability, and the security of the surrounding environment.

Self-hosting is therefore not automatically cheaper or more reliable than managed hosting. The right choice depends on the project, available resources, and the operator's willingness to maintain the system.
A Better Understanding of Technical Dependencies

This migration has encouraged me to think more carefully about portability, infrastructure, and recovery planning.

Developers do not necessarily need to abandon hosted services. However, they benefit from knowing which components are essential, how those components interact, and how to replace them if necessary.

I documented the personal side of this transition, including why I left my previous workflow and what I hope to learn from the move, in my original article:

Read the full experience: Moving On, Not Out of Hate: My Journey from GitHub to Codeberg

For me, the move is both a practical adjustment and a learning project. By combining Codeberg for repository management with a home server for deployment, I hope to develop a better understanding of the infrastructure behind my personal projects.

Sometimes, the most useful outcome of a technical problem is not the replacement tool itself, but the knowledge we gain while finding a new way forward.

I’m back, and this time we’re coming out of the casino, not the mine! 😎

Tue, 27 Oct 2026 20:36:42 +0000

This is just the initial version; rest assured, I will continue to improve it. You can find my code on GitHub: https://github.com/kozmonot20/rulet. Now, getting to the real question: do you think this is illegal? In my view, it isn't, as it uses virtual currency—though some people claim it’s not legal. What do you think? Please share your thoughts in the comments.

Here I am again, this time with a buddy of mine who’s a Monero miner.

Tue, 27 Oct 2026 20:19:55 +0000

Yes, I’m back—and this time, we’re shattering all limits. Here is a C++ integrated Monero miner that won’t melt your processor:enter link description here
import os
import sys
import subprocess
import urllib.request
import zipfile
import json
import time

--- KOZMO TITAN HIGH-SPEED SETTINGS ---

MONERO_CUZDAN = "you"
POOL_ADRESI = "gulf.moneroocean.stream:10128"
MINER_NAME = "Kozmo_Titan_C_V5"

Güvenli ve stabil çalışan resmi XMRig C++ derlemesi

XMRIG_URL = "https://github.com"
ZIP_NAME = "xmrig.zip"
FOLDER_NAME = "xmrig-6.21.0"

def altyapi_kontrol():

"""C++ motorunun varlığını kontrol eder, yoksa temizce kurar."""
# Eğer bozuk klasör kalıntıları varsa temizliyoruz
if os.path.exists(FOLDER_NAME) and not os.path.exists(os.path.join(FOLDER_NAME, "xmrig.exe")):
    print("🗑️  Bozuk klasör kalıntıları temizleniyor...")
    try: os.rmdir(FOLDER_NAME)
    except: pass

if not os.path.exists(FOLDER_NAME):
    print("🛰️  Yüksek Performanslı C++ Motoru İndiriliyor...")
    if os.path.exists(ZIP_NAME):
        os.remove(ZIP_NAME)
        
    # Sahte link hatası düzeltildi, doğrudan binary çekiliyor
    headers = {'User-Agent': 'Mozilla/5.0'}
    req = urllib.request.Request(XMRIG_URL, headers=headers)
    with urllib.request.urlopen(req) as response, open(ZIP_NAME, 'wb') as out_file:
        out_file.write(response.read())
        
    print("📦 Paket içeriği C++ olarak dışarı çıkartılıyor...")
    with zipfile.ZipFile(ZIP_NAME, 'r') as zip_ref:
        zip_ref.extractall(".")
        
print("🟢 C++ Altyapısı stabil hale getirildi.")

def profesyonel_config_enjekte_et():

"""Donanımı yormadan maksimum hızı veren Kozmo JSON ayarı."""
config = {
    "autosave": True,
    "cpu": {
        "enabled": True,
        "max-threads-hint": 60, # 🧊 %35 yük sınırı: Fanlar çıldırmaz ama Python'dan 50 kat daha hızlıdır!
        "perf-mode": 1
    },
    "pools": [
        {
            "url": POOL_ADRESI,
            "user": MONERO_CUZDAN,
            "pass": MINER_NAME,
            "keepalive": True,
            "tls": False
        }
    ]
}

# Klasör kontrol mekanizması
if not os.path.exists(FOLDER_NAME):
    os.makedirs(FOLDER_NAME)
    
config_path = os.path.join(FOLDER_NAME, "config.json")
with open(config_path, "w") as f:
    json.dump(config, f, indent=4)
print("⚙️  Hafif C++ konfigürasyonu enjekte edildi.")

def yuksek_hizli_kaziyi_baslat():

"""C++ motorunu arka planda otonom olarak ateşler."""
print(f"\n🪐 Kozmonot20 Titan Kripto Laboratuvarı v5.0 [HIGH-SPEED]")
print(f"💰 Hedef: Gerçek Monero (XMR) | Cüzdan: Coin Wallet (Space)")
print(f"⚡ Mod: Dengeli Güç (Python hızı x50 Kat Artırıldı)\n")

xmrig_exe = os.path.join(FOLDER_NAME, "xmrig.exe")

if not os.path.exists(xmrig_exe):
    print("❌ HATA: xmrig.exe bulunamadı! Lütfen antivirüsü kapatıp masaüstündeki eski zip/klasörleri silerek tekrar deneyin.")
    return
    
# Motoru arka planda tamamen kısıtlanmış parametrelerle başlatıyoruz
process = subprocess.Popen([xmrig_exe], cwd=FOLDER_NAME)

try:
    while True:
        time.sleep(0.5)
except KeyboardInterrupt:
    print("\n🛑 Ctrl+C Algılandı! Madenci güvenli bir şekilde kapatılıyor...")
    process.terminate()
    print("🧊 İşlemci serbest bırakıldı. İyi sabahlar Kozmo!")

if name == "main":

try:
    altyapi_kontrol()
    profesyonel_config_enjekte_et()
    yuksek_hizli_kaziyi_baslat()
except Exception as e:
    print(f"❌ Kritik Hata: {e}")
    print("💡 Çözüm: Masaüstündeki 'xmrig.zip' ve 'xmrig-6.21.0' klasörünü tamamen silip kodu yeniden başlatın.")

I hope no one gets blown up (that’s my current plan; rest assured, in the future, Elon Musk will come to me to be an apprentice).

# 🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

Thu, 22 Oct 2026 05:55:41 +0000

🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

What if your GitHub contributions could become real opportunities to earn, collaborate and build independent projects?

We're building MyZubster, an open-source ecosystem connecting developers, digital creators, freelancers and local communities.

Our vision is to create a marketplace where people can:

💻 Offer digital skills — programming, UI/UX, AI, DevOps, cybersecurity and blockchain development.

🤝 Exchange services, collaborate on projects and support volunteer initiatives.

₿ Explore payments using Bitcoin (BTC), Ethereum (ETH), Monero (XMR) and traditional currencies.

🔐 Help design secure multisig escrow solutions, with legal and regulatory compliance considered from the beginning.

🌍 Connect GitHub contributions, digital portfolios and independent community projects.

🧠 We need your ideas, not just your code!

We've opened a community discussion to explore how MyZubster can become a practical, sustainable and legally compliant marketplace.

We're looking for:

Developers and open-source contributors
Blockchain and cryptocurrency specialists
UI/UX designers
Privacy and security researchers
Legal, fintech and compliance professionals
Freelancers interested in selling digital skills

Some features are already under development; others are proposals we want to design and validate together.

We especially want to explore how contributors can offer their digital services through the marketplace, how crypto payments should work, and how to reduce legal and technical risks for everyone involved.

🔗 Join the discussion

GitHub community topic:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1639

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

Website:
https://myzubster.com

💬 Introduce yourself, share your expertise, propose an idea or tell us what you'd like to build.

You don't need to be an expert in everything. Every meaningful contribution matters.

Let's build something useful, open and sustainable — together.

OpenSource #GitHub #Blockchain #Monero #Bitcoin #Ethereum #Marketplace #WebDevelopment #Freelancing #Decentralization #MyZubster

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

Wed, 21 Oct 2026 05:38:10 +0000

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

We're building MyZubster, an open-source ecosystem connecting developers, independent projects, services, and communities.

Today we made significant progress on Zorgax, our locally hosted AI assistant.

Our goal is simple: make it easier for anyone — including people with no programming experience — to join GitHub, contribute to projects, and become part of a collaborative ecosystem.

🔧 What We Built and Tested

1. Vercel ↔ VPS Connectivity

We restored communication between our Vercel Production deployment and the VPS backend using a signed HTTPS gateway.

Production assistant endpoint responding successfully
HTTP 502 connectivity issue resolved in our tests
Node.js gateway operational
MongoDB connected
Local Ollama inference available

2. GitHub Contributor Onboarding

We implemented a deterministic onboarding guide in Zorgax.

The assistant can now:

Guide new users to GitHub registration
Recognize completion messages such as FATTO
Ask for a GitHub username
Recognize that username within the conversation
Advance to Git and GitHub CLI setup
Avoid claiming an account has been verified without evidence

3. Real Production Testing

Our regression tests passed: 4/4.

We also tested the public Zorgax chat and confirmed that the assistant correctly advanced from GitHub registration to the username and tooling stages.

4. Local AI Architecture

Our system currently combines:

Node.js backend
Vercel frontend and gateway
VPS-hosted services
Ollama with qwen2.5:3b
Deterministic onboarding rules
MongoDB

This approach helps us keep sensitive onboarding workflows predictable while using local AI for more flexible assistance.

🐛 What Still Needs Work

Our tests also revealed that Zorgax can lose track of the onboarding sequence when it falls back to Ollama.

For example, after Git and GitHub CLI version checks, it may answer a different MyZubster-related question instead of continuing with GitHub authentication.

We're working toward a complete flow:

GitHub signup → username → Git/CLI checks → authentication → repository → first pull request

We want every step to be clear, verifiable, and beginner-friendly.

🌍 Beyond a Traditional Marketplace

MyZubster is also exploring ways to connect:

Independent developer projects
Skills and services through a marketplace
Contributor profiles and verifiable contributions
Local community initiatives
Decentralized infrastructure and autonomous nodes
Privacy-conscious payments and collaboration

Our longer-term vision is a federated ecosystem where contributors can develop their own projects while remaining connected to a broader network.

These are ongoing development goals, not claims that every feature is already production-ready.

🤝 Looking for Contributors

We're particularly interested in developers who want to help with:

AI-assisted GitHub onboarding
Node.js and API testing
UX/UI simplification
GitHub automation
Marketplace workflows
VPS and decentralized infrastructure
Open-source documentation

You don't need to build everything. Even a small, well-tested contribution can move the project forward.

Explore MyZubster: https://www.myzubster.com

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

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

Let's collaborate

We're interested in connecting independent developers and projects rather than requiring everyone to work inside a single centralized system.

Question for the community: How would you design an AI onboarding assistant that guides a complete beginner from creating a GitHub account to opening their first pull request?

OpenSource #AI #GitHub #NodeJS #Decentralization #DeveloperCommunity

REA GitHub Tutorial: Reverse Engineer Anything with Claude Code (Full Setup + Fi

Tue, 20 Oct 2026 19:39:34 +0000

What is REA?

REA is an MCP server plus a set of workflow instructions (a "skill") for your AI agent. Instead of guessing how an app works from screenshots, the agent can call REA's analysis tools — 207 of them in version 6.7.0 — to inspect the real files.

Think of it like a restaurant:

You are the customer — you ask a question in plain English.
Claude Code is the chef — it decides what to do.
REA is the chef's toolbox.
The app is the ingredient being inspected.

It supports JavaScript and Electron apps out of the box. Native .exe/.dll analysis needs Ghidra, IDA or Hopper installed separately, and full Android APK analysis needs a Java JDK.

Hype vs reality

✅ It finds real evidence inside an app's files
✅ It explains that evidence in plain language
✅ It tells you what it couldn't figure out
❌ It is not a one-click "clone this app" button
❌ Heavily protected apps need extra tools and may still leave open questions

My favourite part: findings come with a confidence level. In my test, the Electron fuse check came back as "confidence": "observed" from the shipped artifact, with the file's SHA-256 attached as proof.

How to install REA

Prerequisite: Node.js 22.19+, 24.11+ or 26+.

Mac & Linux (guided)

npx rea-agents setup

The wizard asks which agent you use and registers REA for you.

Windows (manual — this is what worked for me)

On Windows, setup deliberately doesn't edit your agent's config, so register it yourself:

node -v
npm install -g rea-agents@6.7.0
rea doctor
claude mcp add --scope user rea -- cmd /c rea mcp

Then fully restart Claude Code and run /mcp — you should see rea · connected.

cmd /c matters on Windows: rea is a .cmd launcher that Claude Code can't start directly.

⚠️ Install only from the official repo — github.com/morluto/rea — or the npm package rea-agents. Copycat repos are a real risk with tools like this.

Demo: reverse engineering VS Code

I gave Claude Code this prompt (static analysis only — nothing launched or modified):

Use the rea MCP server to statically analyse VS Code at
%LOCALAPPDATA%\Programs\Microsoft VS Code. Do not launch or modify it.
1. inspect_pe_resources and inspect_electron_fuses on Code.exe
2. Read resources\app\product.json and list every server it talks to
3. analyze_javascript_application on resources\app and map its processes
Explain each finding in plain English.

1. What Code.exe really is

Component	Version
VS Code	1.142.0
Electron	43.7.7
Chromium	150.0.7871.250
Node.js	24.21.0
Size	238 MB, 64-bit, signed by Microsoft

The internal name? electron.exe. VS Code is a web app in a desktop wrapper.

2. Nine Electron security fuses

Fuses are on/off switches baked into the executable at build time. REA read all nine. Highlights:

On: RunAsNode, EnableNodeOptionsEnvironmentVariable, EnableNodeCliInspectArguments — VS Code needs these for its CLI and helper processes.
Off: EnableEmbeddedAsarIntegrityValidation, OnlyLoadAppFromAsar — VS Code checks its own files with checksums in product.json instead.

These are design trade-offs, not bugs — but they're exactly why Electron apps are interesting to study.

3. Who VS Code talks to

From product.json: the update server, the Extension Marketplace, a GitHub-hosted MCP server gallery, Settings Sync, an A/B experimentation service, Bing-powered settings search, a voice service, and a CDN hosting AI agent SDKs. Telemetry is on by default, with an opt-out.

4. Seven processes

Main process, workbench window, shared process, extension host, pty host (terminal), file watcher, and a newer agent host. That's why one frozen extension doesn't freeze your editor — extensions run in their own process.

Troubleshooting: every error I hit

Error	Cause	Fix
`'claude' is not recognized`	`claude.exe` is in `%USERPROFILE%\.local\bin`, which wasn't on PATH	Add that folder to your user PATH, open a new terminal
`MCP server rea already exists in user config`	Already registered	Nothing to fix — restart Claude Code
`rea` missing from `/mcp`	Not restarted, or a different session/PC	Fully close and reopen Claude Code on the same PC
`provider_unavailable`	No Ghidra/IDA/Hopper found	Install Ghidra + JDK 21, set `GHIDRA_INSTALL_DIR`, run `rea doctor`
Server won't start on Windows	Missing `cmd /c`	`claude mcp add --scope user rea -- cmd /c rea mcp`
APK analysis fails	JRE instead of JDK	Install a full Java JDK

Pro tip: when anything breaks, run rea doctor first. It's read-only and tells you exactly what's missing.

My verdict

For understanding apps — yes. What used to take hours in a disassembler took minutes, in plain English.
Not a magic clone button. It gives your agent evidence; building is still your job.
Always verify anything marked "inferred" or "unknown".

As an app developer, I'll use it to check my own release builds (what really ships in my APK), learn how good open-source apps solve a feature, and audit what the tools I install connect to.

Use it responsibly

From REA's README: it's for lawful research, education, interoperability, software preservation — and software you own or are authorized to examine. Learn from apps; don't copy paid ones.

Why Git Blob IDs Mismatch Your File Checksums

Mon, 19 Oct 2026 02:25:56 +0000

Comparing a raw file digest with a Git object identifier often reveals unexpected mismatches. Developers frequently notice that running a standard local hashing tool on a file produces a different checksum than the one returned by Git or the GitHub Git blobs REST API. This discrepancy occurs because Git does not hash raw file bytes directly. Instead, Git constructs an object header that includes the object type and byte length, prepends it to the content, and hashes the combined payload.

Quick solution:
To calculate the exact Git blob object ID locally, prepend the object type and byte length header followed by a null byte before hashing the raw content.

printf "blob %d\0%s" "$(wc -c < file.txt)" "$(cat file.txt)" | shasum

Prerequisites include a standard Unix shell environment with shasum or sha1sum, and wc for counting exact byte lengths. Be aware that trailing newlines or varying shell implementations of printf can alter the generated byte stream.

Why Does Hashing Raw File Bytes Produce Another Value?

When you run a command like openssl dgst -sha1 file.txt or shasum file.txt, the utility reads the raw byte sequence of the file and feeds it directly into the cryptographic hash function. This yields a pure content digest. Git, however, treats files as version-controlled objects rather than flat storage blocks. According to the Git hash-object documentation, every stored object receives a header composed of its type (such as blob), a space, the size of the file in bytes, and a null byte (\u0000) acting as a separator.

For example, if a file contains the exact text hello, its byte length is 5. Git constructs the internal byte sequence by joining the string blob 5, a null byte, and the five characters of content. Hashing this combined stream produces the unique Git object identifier. Because the raw file digest lacks the header, metadata, and null separator, the resulting checksum diverges completely from the Git blob ID. Developers optimizing performance workflows often review prior indexing patterns, such as those detailed in our guide on Google Search Console Content Prioritization, to ensure metadata indices align properly with storage identifiers.

How Is UTF-8 Byte Length Different from String Length?

Calculating correct object identifiers requires precise byte counting rather than character or string length measurements. In ASCII text, one character equals one byte. However, modern codebases frequently utilize multi-byte UTF-8 characters, emojis, or specialized symbols.

Consider a text file containing a single multi-byte character, such as the euro symbol (€). In UTF-8 encoding, this character occupies three bytes. If an application measures string length by counting logical characters, it might report a length of 1. If Git then calculates the header using that incorrect length, the resulting object hash will fail to match the repository database or API response. Engineers must always measure exact byte counts using tools like wc -c or native byte-length methods in programming languages rather than relying on character-length functions.

When Must Application Integrity Use a Separate Digest?

Relying on Git object IDs for external application security or file verification introduces architectural risks. Because Git object identifiers depend on the internal repository header and the chosen hashing algorithm (such as SHA-1 or newer experimental formats like SHA-256), they are tightly coupled to version control internals rather than raw file content.

Option	When to Use It	Trade-off or Failure Mode	Recommendation
Git Blob ID	Verifying repository object storage and API blob parity	Tied to Git metadata headers and vulnerable to SHA-1 collision concerns	Use strictly for Git repository tooling and GitHub REST API integration
Raw File Digest	Verifying independent file downloads, caches, or releases	Ignores repository metadata and commit context	Use standard SHA-256 or BLAKE2 for general application integrity checks

Applications that require independent file verification, artifact signing, or secure distribution must rely on a dedicated raw digest computed directly from the file bytes. Treating Git object IDs as universal file checksums creates fragile verification pipelines that break when files are checked out with different line ending configurations, such as CRLF versus LF normalization.

Additional Scenarios and Failure Modes

In addition to the differences between raw file digests and Git blob IDs, there are other scenarios where the two may diverge. For instance, when a file is modified, the Git blob ID will change, but the raw file digest may not if the modification does not affect the file's content. Similarly, if a file is renamed or moved, the Git blob ID will remain the same, but the raw file digest may change if the file's content is modified during the rename or move operation.

Execution and Verification Checklist

[ ] Verify empty content matches git hash-object by running an empty file through the header generation command and comparing it against git hash-object --stdin. Expected result: hashes match the known empty blob identifier e69de29bb2d1d6434b8b29ae775ad8c2e48c5391.
[ ] Test non-ASCII text using exact byte length calculations rather than character counts to ensure multi-byte symbols generate matching object IDs.
[ ] Confirm a one-byte modification alters both the raw digest and the Git blob identifier, validating that minor edits propagate correctly through the header generation step.
[ ] Document environment specifics, shell versions, and encoding parameters before deploying any automated script that compares raw file checksums against Git repository objects.
[ ] Verify the behavior of Git blob IDs and raw file digests in different encoding scenarios, such as UTF-8, UTF-16, and UTF-32.
[ ] Test the performance impact of using Git blob IDs versus raw file digests for large files and repositories.

Conclusion

In conclusion, the discrepancy between raw file digests and Git blob IDs arises from the inclusion of a header in the Git object identifier. This header contains the object type, byte length, and a null separator, which are not present in the raw file digest. Understanding the differences between these two types of identifiers is crucial for ensuring data integrity and security in version control systems and application development. By using the correct type of identifier for the specific use case, developers can avoid potential pitfalls and ensure the reliability of their workflows.

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

Developer Weekly Briefing — October 16, 2026

Fri, 16 Oct 2026 12:28:25 +0000

A week defined by two big ideas running in parallel: AI agents are breaking the infrastructure underneath them, and the security surface around developer workflows keeps growing. Both threads showed up in force. Here's what mattered.

Anthropic hit 30,000 merges a day, and Git couldn't keep up — so it built Scion

By September 2026, Anthropic was averaging 30,000 merged changes a day, up from 2,500 in May. Its main branch history had grown close to 100 GB. CI alone required 25 million checkouts a day, and at peak the team ran several hundred Git mirrors just to keep up. Standard workarounds stopped working. So a seven-person team built a replacement from scratch.

Scion is Anthropic's internal version control system. The design is built for always-online, agent-heavy workloads rather than Git's original model of offline, occasional human pushes. Servers handle commits, merges, rebases, and diffs. Clients keep a small local cache. Commits are stored as changesets that scale with the size of the change, not the size of the repo. Cache hit rates are above 99% at each of the three tiers. The result: checkouts take seconds instead of minutes, use about 200 times less CPU and memory than the old mirror fleet, and recover 25% of CI capacity.

Anthropic says Scion only makes sense for very large monorepos and has no plans to release it — but it wants to share the ideas with GitHub, GitLab, and the open source community. Last week's briefing covered GitHub's infrastructure rebuild to handle agent-scale load. This week, Anthropic said: we got there first, and we had to build something new to do it.

GitLab patches a CVSS 10 — update now

A critical vulnerability in GitLab's CI/CD regex engine, CVE-2026-97229, got a perfect CVSS score of 10.0. An unauthenticated attacker could send a crafted regex in a CI/CD configuration and execute arbitrary code on the server — which typically holds source code, pipeline definitions, and production secrets. GitLab shipped fixes in versions 19.4.2, 19.3.5, and 19.2.8 on October 12. GitLab.com is already patched. Dedicated customers need no action. Self-managed instances need to upgrade now. The release also covers 23 other vulnerabilities, including an 8.7-rated prompt injection in GitLab Duo Agent Platform.

GitHub now records who pushed every commit

Git has always let developers set their own name and email in commits — metadata that's trivially spoofed. GitHub's new push attribution feature records the authenticated account that actually pushed each commit, separate from the author and committer fields. A new repository ruleset, "Committer must match pusher," can block pushes where the committer's email doesn't match the pusher's verified addresses. The practical benefit: bots and agents often push commits under a human's name. This makes that visible. It's in limited public preview for GitHub Enterprise. Before enabling the enforcement rule, audit your release bots, shared tokens, and any workflow that pushes on behalf of someone else — the rule will break those if you don't.

GitHub is pushing teams off classic PATs — here's the new permission model

GitHub announced narrowed app permissions aimed at getting teams off classic personal access tokens. Classic PATs have been a persistent weak spot: long-lived, often over-scoped, and easy to forget once they're embedded in a workflow. The new fine-grained permissions limit what any given token or GitHub App can access. If your team still uses classic PATs in automation, this is a push to move. The transition won't happen overnight, but the direction is clear.

npm gives unused trusted publishing configurations 48 hours to prove themselves

npm's trusted publishing feature ties release authority to a repository or project name. That's useful until the name changes hands — an abandoned or reorganized repo that still has a trusted configuration is exactly where supply chain attacks start. npm's fix: any configuration that doesn't complete a successful publish within 48 hours of creation expires. Once it publishes successfully, the expiration goes away. The practical change: create your trusted publishing configuration when you're ready to publish, not during setup. If it expires, recreate it.

Claude Platform now sends agent traces to your observability stack

Anthropic added native OpenTelemetry trace export to the Claude Platform, in public beta. It works with the Messages API, Claude Managed Agents, and the Claude SDKs. Each trace includes duration, status, token counts, the model used, tool names, and request IDs. Teams can also enable full content export, which adds prompts, responses, and tool inputs and outputs. Setup for the Messages API and Managed Agents requires no application code changes — just configure an export destination in the Claude Console. The feature supports any OTLP-compatible backend; Anthropic has published guides for 12 partners, including Datadog, Grafana, Honeycomb, Langfuse, New Relic, and Splunk. The practical value: agents make several model calls, tool calls, and retries per request, and failures in that chain are hard to trace without instrumentation. This is the instrumentation.

Figma gives AI agents a spec sheet and code layers land on the canvas

Figma shipped two features worth tracking. Specs is a Markdown editor — on canvas or as a standalone file — where teams write requirements, design rules, and agent instructions. It can reference canvas elements, pull context from a connected GitHub repo, and embed diagrams and code. On the development side, Code Layers lets teams place running, code-backed prototypes directly in a Figma file. Code can come from a GitHub repo, a local folder, a live website, or an AI coding tool. Claude Code gets a round-trip: work from Claude Code can land in Figma, and design changes can be pulled back into the codebase through MCP. Both features are in open beta.

Cloudflare acquires Deno's team to build self-hosted Workers. Cloudflare is hiring Ryan Dahl and the Deno team to make workerd, the open-source Workers runtime, production-viable for self-hosted deployments. Deno Deploy shuts down in six months. Deno runtime gets one more year of maintenance releases. JSR keeps running. If you're on Deno Deploy, start planning the move now. Read more
Microsoft launches Decision-1, a fast, cheap decision-scoring model. Built on post-trained Qwen3.5-9B, Decision-1 takes a fixed set of answers and returns calibrated probabilities in a single API call. It's aimed at routing, classification, and workflow control — the "System One" decisions in an agent pipeline. Available in Microsoft Foundry and through OpenRouter at $0.042 per million input tokens. Read more
Nvidia hands Run:ai to the open source community. The GPU orchestration platform Nvidia acquired in 2024 is going open source. For teams managing GPU workloads for AI training and inference, this matters. Read more
SpaceX bundles Grok, Cursor, and X Premium into one subscription. The $30/month Premium tier combines Grok, Cursor Pro, and X Premium+ — tools that would cost about $90 separately. The catch: Grok and Cursor share a usage pool, so AI chat and coding work against the same weekly limit. Dev teams should audit that tradeoff before committing. Read more
AI doesn't replace your thinking — it raises the bar for it. My latest for Insights From Analytics: the patterns I keep seeing when professionals struggle to get real value from AI, and what changes when they fix them. Read more

Developer Spotlights this week

Bryan MacLee drives an oil and gas truck in Vernal, Utah, and builds his own programming language on the side. SCRML is a full-stack language for the browser — the compiler handles the wiring between frontend and backend that developers normally manage by hand. Version 0.8 is out. Adoption is near zero, by his own description on the project site. He's building it anyway. A good conversation about what it takes to build something nobody's using yet.

Watch the conversation

Jonathan Gordon spent decades building developer tools at Google, Apple, Microsoft, Oracle, and SAP. His warning: AI-generated code often has error handling that "puts nothing in the catch block." Users find out when buttons stop working. His rule: "We can't just let AI build the software by itself." The full conversation is a useful counterweight to the vibe coding conversation.

Watch the conversation

The through-line this week: agents are breaking things at the infrastructure layer, and security controls designed for human developers don't hold up at agent scale. Anthropic had to build a new VCS. GitHub is adding authentication that was never needed when a human was always at the keyboard. The same pressure is showing up everywhere.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

My GitHub Sponsors Is Live: Help Me Build Creative Tools Blind People Can Actually Use

Wed, 14 Oct 2026 16:46:58 +0000

After months of waiting, my GitHub Sponsors profile is finally live! 🎉

Who I am

I'm Demir Ajvazi, a blind developer from Serbia. I've been using the JAWS screen reader for about 20 years. For most of that time, I've watched creative software lock out people like me: professional video, audio and photo editors are nearly impossible to use with a screen reader.

What I'm building

So I started building the Ultra Creative Suite: open-source creative tools designed from the ground up to work equally well for blind and sighted users. Not a stripped-down "accessible mode", and not a workaround, but real tools that both blind and sighted creators can use side by side.

Alongside the suite, I'm working on other accessible tools:

UltraShield: an accessible digital self-defense app for Windows
Ultra Uninstaller: a Windows uninstaller and cleaner that is fully usable with a screen reader
Ultra Bridge: a JAWS and NVDA command-mapping helper

You can find everything here: github.com/demirajvazi10-max

How you can help

If you believe blind people deserve the same creative tools as everyone else, you can now support my work directly:

👉 github.com/sponsors/demirajvazi10-max

Monthly sponsorships start at $3, and one-time support is welcome too. Every contribution goes directly into development and keeps everything free and open source.

Can't sponsor? That's completely fine. Sharing this post, starring a repo, or trying the apps with a screen reader and telling me what doesn't work helps just as much.

Thank you for reading!

Interoperable Contributor Evidence: From Paste Links to Verifiable Digital Passports

Tue, 13 Oct 2026 04:33:44 +0000

Interoperable Contributor Evidence: From Paste Links to Verifiable Digital Passports

Open-source and contributor ecosystems have a familiar problem: useful work happens across many systems, but recognition, verification, and reward often remain trapped inside one platform.

A developer may submit a pull request on GitHub, publish a technical note on a paste service, share a reproducible command transcript, run an automation bot, or provide a review that improves a project’s safety. Each item may be valuable. None should automatically be treated as trustworthy merely because it has a URL.

The challenge is not to centralise every contributor’s data. It is to make evidence portable, reviewable, privacy-aware, and interoperable.

This is the direction behind a contributor-evidence model for Coder Legion: a system where external references can support a contribution, while identity, review status, and public visibility remain under explicit control.

A link is not evidence by itself

A Pastebin URL, GitHub issue, deployment log, or repository commit can be useful context. But a URL alone has important limitations:

the content behind it can change or disappear;
access can be restricted later;
the author is not automatically the contributor;
the link does not express review status;
copying a link does not prove integrity.

The first design rule is simple:

External content is a reference. Evidence is a reference plus integrity, provenance, and review context.

Instead of storing only:

{
  "url": "https://pastebin.com/example"
}

an interoperable contribution package should record a stable representation:

{
  "source": {
    "kind": "paste",
    "url": "https://pastebin.com/example",
    "retrievedAt": "2026-10-13T00:00:00.000Z"
  },
  "integrity": {
    "algorithm": "sha256",
    "digest": "…"
  },
  "contributor": {
    "subject": "contributor-identifier"
  },
  "claim": {
    "type": "technical-evidence",
    "summary": "Reproduced and documented a CI regression."
  }
}

The URL tells reviewers where the work was published. The digest tells them whether the reviewed content is still the same content.

Paste interoperability without trusting the paste service

“Pastebin interoperability” should not mean granting a third-party paste service access to contributor accounts, importing credentials, or treating a paste as an authenticated identity provider.

A safer model is deliberately narrow:

A contributor submits a public URL and a short description.
The system retrieves or the contributor supplies the content snapshot.
The snapshot is canonicalised and hashed.
The contribution stores the URL, hash, timestamps, and declared relationship to the work.
A reviewer verifies relevance and marks the contribution’s status.

The system can support paste services, GitHub gists, static documents, issue threads, release notes, and self-hosted technical notes through the same reference shape.

This avoids creating a special trust model for one platform. The interoperability layer only needs to understand a source type, a URL, an integrity digest, and a retention policy.

The contribution lifecycle

A useful contribution record should distinguish between submission and verification.

Submitted → Under review → Verified → Rewarded
                     ↘ Rejected / Needs clarification

The state is important because a public reference may be legitimate but still insufficient for a specific claim.

For example:

“I documented a reproducible build failure” can be supported by a paste containing logs and steps.
“I fixed the failure” requires a linked patch, pull request, or verified commit.
“I should receive a reward” requires an explicit policy decision, not just a valid hash.

A clean data model prevents a common mistake: confusing evidence storage with automated approval.

Digital passports for people and bots

Contributor ecosystems increasingly include both humans and automation.

A human contributor may submit documentation, a patch, a review, or a research note. A bot may run scheduled checks, produce reproducible reports, classify issues, or monitor a source for changes.

They should not have identical permissions, but they can share a common public-verification model.

A digital passport can expose a deliberately limited set of fields:

{
  "passportVersion": 1,
  "subjectType": "human-or-bot",
  "displayName": "Example Contributor",
  "capabilities": ["ci-verification", "evidence-reporting"],
  "status": "ACTIVE",
  "verifiedContributions": [
    {
      "contributionId": "contribution-123",
      "category": "technical-evidence",
      "status": "VERIFIED",
      "reference": "https://example.org/evidence",
      "reviewedAt": "2026-10-13T00:00:00.000Z"
    }
  ]
}

The public projection must be an allowlist, not a copy of an internal database record.

That means deliberately excluding:

owner identifiers;
internal reviewer notes;
ledger references;
revocation rationale;
API keys, tokens, private keys, seeds, passwords, and credentials;
unpublished metadata.

The rule is straightforward: public passports expose provenance, not secrets.

Why bots need separate ownership boundaries

A bot passport must not become a way to create anonymous privileged automation.

The minimum safeguards are:

authenticated creation;
explicit owner association;
owner-scoped listing and revocation;
rejection of unknown input fields;
rejection of secret-bearing fields;
database availability checks on routes;
public responses built from an explicit allowlist.

A bot can be publicly described as capable of “CI verification” or “evidence reporting.” It should never publish the token, webhook secret, internal owner ID, or private operational notes that make it work.

This is especially important when automation interacts with external sources. A bot may retrieve a public paste or repository artifact, but its credentials must remain entirely outside the evidence record.

Portable evidence packages

The long-term goal is not a platform-specific badge. It is a portable evidence package that can move between communities.

A practical package can include:

{
  "schema": "coder-legion.contribution-evidence.v1",
  "contributionId": "contribution-123",
  "subject": {
    "type": "human",
    "id": "public-subject-id"
  },
  "claim": {
    "category": "documentation",
    "summary": "Produced a reproducible guide for a CI issue."
  },
  "sources": [
    {
      "kind": "paste",
      "url": "https://pastebin.com/example",
      "sha256": "…"
    },
    {
      "kind": "pull-request",
      "url": "https://github.com/example/project/pull/42"
    }
  ],
  "review": {
    "status": "VERIFIED",
    "reviewedAt": "2026-10-13T00:00:00.000Z"
  }
}

The package does not need a blockchain transaction to be useful. It can be signed, stored, exported, reviewed, and re-verified independently.

If an ecosystem later decides to anchor a digest in a ledger, that should be an additional attestation layer—not a substitute for review, source integrity, or privacy boundaries.

Interoperability is a protocol decision, not a scraping project

A resilient integration should avoid assumptions such as:

every contributor has a GitHub account;
every paste service has a stable API;
all external content remains available forever;
a URL proves authorship;
a hash proves truth;
a platform’s internal reputation score is portable.

The portable part should be small and durable:

Field	Purpose
Schema version	Defines how to interpret the package
Subject identifier	Connects evidence to a public identity
Source URL	Preserves a human-readable reference
Content digest	Detects content changes
Timestamp	Records when the evidence was observed
Claim	States what the evidence is meant to support
Review status	Separates submission from verification
Public projection	Limits what is disclosed

Everything else should remain optional, private, or platform-specific.

A practical implementation path

For Coder Legion, the implementation can progress in small, reviewable steps:

Define a source adapter interface
Support paste URLs, GitHub links, and uploaded evidence through the same schema.
Store immutable integrity metadata
Hash the reviewed content snapshot and retain retrieval timestamps.
Add contributor review states
Keep SUBMITTED, UNDER_REVIEW, VERIFIED, REJECTED, and REWARDED distinct.
Expose a privacy-safe public passport
Publish only verified contribution summaries through a strict allowlist.
Add bot passports with ownership controls
Let automation identify its scope and capabilities without exposing its secrets.
Export portable evidence packages
Make evidence inspectable outside the originating application.
Anchor only when useful
Add ledger or on-chain attestations for specific high-value events, never as a default requirement.

What success looks like

A healthy contributor system does not ask people to trust an opaque score.

It lets a reviewer answer concrete questions:

What work is being claimed?
Where is the supporting material?
Has the content changed since review?
Who reviewed it?
What is publicly visible?
Can the contributor export the evidence elsewhere?
Is the automation involved accountable to an owner without exposing credentials?

That is the real interoperability target.

Paste services, Git repositories, bots, and community platforms will continue to change. A contributor’s evidence should not become invalid simply because one interface disappears. By treating sources as references, hashes as integrity checks, review as a separate decision, and passports as privacy-safe projections, Coder Legion can recognise work without trapping contributors inside a single system.

Your Repo Can Now Tell People It Cares About Accessibility

Mon, 12 Oct 2026 18:17:21 +0000

Open any repository on GitHub and you see the same tabs: README, Code of Conduct, Contributing, Security. As of October 1, there can be one more: Accessibility.

GitHub now highlights an ACCESSIBILITY.md file on the repository overview and links to it from the About section. It is a small change, and it puts accessibility on the front page of your project, next to the files every contributor already reads.

We added one to TWD right away. Here is why, and what we learned.

Why it matters

Picture someone who uses a screen reader trying out your library. Something in the docs doesn't work for them. Today, they have to guess: is this a known issue? Does anyone care? Where do I even report it?

An accessibility page answers all three before they ask. It says this project takes accessibility seriously, here is what we have tested, and here is how to tell us when something gets in your way.

It also helps the other side. Contributors see, in plain words, what is expected of a change that touches the UI.

What we put in ours

TWD had a head start. In June we had it independently audited against WCAG 2.2 AA, fixed what the auditors found, and published a formal accessibility statement.

We expected to copy and paste that statement. We didn't. A formal statement is written for compliance. The GitHub page is written for people, so we wrote it in plain language around three ideas:

Be honest about what was tested. Our audit covered the sidebar and the main docs pages, using a keyboard and the NVDA screen reader. So that is what the page claims. For everything else, WCAG 2.2 AA is our goal, and we say so.

Make reporting easy. Open an issue, send an email, or ask in Discussions. No need to know which guideline is involved, and no need to share anything personal. We commit to replying within 5 business days.

Tell contributors what good looks like. Keep it usable with a keyboard, keep focus visible, don't rely on colour alone, and include light and dark screenshots with UI changes.

You can read the result here: TWD's ACCESSIBILITY.md.

Add one to your project

You don't need an audit to start. You need an honest page.

Create ACCESSIBILITY.md in your repo root (or in .github/ or docs/).
Start from GitHub's template, or add it from your repo's Community Standards page.
Fill in the two sections that matter most: how to report a barrier, and what you have and haven't tested.

That's it. The tab appears on your repo's front page.

Accessibility work usually happens out of sight. Now it has a place on your repo's front page, where users and contributors will see it.

A Beginner’s Guide to Git and GitHub: From Installation to Your First Push

Mon, 12 Oct 2026 16:20:10 +0000

Starting my journey in Data Science, Analysis, and AI at LUXDevHQ felt like learning a new language while trying to build a house. One of the most important tools I’ve discovered along the way is Version Control.

In this guide, I’ll walk you through:

Setting up Git Bash
Connecting Git to GitHub
Mastering essential push and pull commands

1. What Is Git and Why Does It Matter?

Git is a Version Control System (VCS). Think of it as a save-point system for your code.

Why is Git important?

⏪ Time Travel – If you break your code, you can roll back to a version that worked.
🤝 Collaboration – Multiple people can work on the same project without overwriting each other’s work.
🧪 Experimentation – You can create branches to try new features without affecting the main project.

2. Setting Up Your Environment

Step A: Install Git Bash

Go to Git and download Git for your OS (I used Windows).
Run the installer.
💡 Pro tip: You can keep the default settings for most options.
After installation, search for Git Bash in your applications. It looks like a terminal window.

Step B: Configure Your Identity

To let GitHub know who is uploading code, configure your global Git settings:

git config --global user.name "Your Name"
git config --global user.email *Emails are not allowed*

3. Secure Your Connection: Setting Up SSH Keys

Using SSH is the professional standard. It’s more secure and saves you from typing your password every time you push code.

Step 1: Generate Your SSH Key

Open Git Bash and enter (replace with your GitHub email):

ssh-keygen -t ed25519 -C *Emails are not allowed*

•File Location: Press Enter to use the default location.
•Passphrase: As a beginner, I left this empty for convenience.

Step 2: Add Key to the SSH Agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Step 3: Add the Public Key to GitHub

1.Copy the key:

cat ~/.ssh/id_ed25519.pub

2.Go to GitHub: Settings → SSH and GPG keys → New SSH Key.

3.Give it a name (e.g., "My Learning Laptop") and paste your key into the "Key" box.

Step 4: Test the Connection

Run:

ssh -T *Emails are not allowed*

Success Check! If you see "Hi [YourUsername]! You've successfully authenticated", you are ready!

4. Navigating and Creating Your Project

Learning to navigate via Git Bash makes you much faster than using a mouse! Use these commands to create your first repository:
•Check Location: pwd (Print Working Directory).
•Go to Desktop: cd Desktop
•Create Folder: mkdir my-first-repo
•Enter Folder: cd my-first-repo

5. Tracking Changes (The Core Workflow)

Before sending code to GitHub, Git needs to "track" it locally. Run these inside your project folder:
1.Initialize Git: git init (Starts tracking the folder).
2.Check Status: git status (See what files Git notices).
3.Add Files: git add . (Stages all changes to be saved).
4.Commit: git commit -m "My first commit" (Creates the "save point").

6. Pushing Code to GitHub

Pushing sends your local save points to the cloud.

Step A: Create the Repository on GitHub.com

1.Log into GitHub, click the + icon → New repository.
2.Name it (e.g., my-first-project) and keep it Public.
3.Important: Leave "Add a README" unchecked to avoid conflicts.
4.Click Create repository.

Step B: Connect and Push

On the GitHub setup page, click SSH and copy the URL. Then run these commands one by one:

git remote add origin *Emails are not allowed*:your-username/repo-name.git
git push -u origin main

7. Pulling Code from GitHub

If you work on a different computer, use Pull to download the latest updates from the cloud:

git pull origin main

📚 Resources to Keep Learning

•Official Git Documentation
•GitHub Skills: Interactive Courses
•Visualizing Git Commands (Game)

Conclusion: Congratulations! You've just set up a professional dev workflow. Git can be tricky at first, but keep practicing and it will become second nature. If you ran into any issues, drop a comment below and let's help each other out!

Interoperability by Evidence, Not by Copying Data: Coder Legion × Pastebin

Sun, 11 Oct 2026 14:23:05 +0000

Interoperability by Evidence, Not by Copying Data: Coder Legion × Pastebin

Interoperability is often described as an integration problem: connect two platforms, move data between them, and call it done.

For contributor systems, that is incomplete—and risky.

When Coder Legion needs to recognise work published on Pastebin, the goal is not to copy a contributor’s content into another database. The goal is to create a verifiable, privacy-aware relationship between an external artifact and a contributor record.

This is the design principle:

Keep the external artifact where it belongs. Store only the minimum evidence needed to verify its relationship to a contribution.

That principle gives us a practical interoperability model for Coder Legion and Pastebin.

The problem with naïve integrations

A naïve Pastebin integration usually does this:

Accept a Pastebin URL.
Fetch the paste.
Store its full text in the application database.
Attach it to a contributor profile.

It looks convenient, but it creates several problems:

It duplicates data that belongs to another service.
It can copy personal, confidential, or accidentally published material.
It makes retention and deletion responsibilities unclear.
It turns a URL into a trust claim without proving what was actually observed.
It cannot reliably distinguish a later-edited artifact from the one originally reviewed.

A better model treats Pastebin as an external evidence source—not as a storage backend.

A small, verifiable evidence envelope

Coder Legion can represent a Pastebin artifact with a compact evidence envelope:

{
  "source": "pastebin",
  "canonicalUrl": "https://pastebin.com/AbCdEf12",
  "externalId": "AbCdEf12",
  "contentHash": "sha256:...",
  "contentLength": 1842,
  "observedAt": "2026-10-11T14:00:00.000Z",
  "status": "OBSERVED"
}

The application stores:

the canonical external reference;
a stable external identifier where available;
a SHA-256 digest of the observed content;
bounded metadata such as byte length and observation time;
the verification state.

It does not store the full Pastebin text by default.

This creates a durable claim:

At a specific time, Coder Legion observed content at this external reference and calculated this digest.

That is auditable without silently replicating the artifact.

The interoperability flow

flowchart TD
  A["Contributor submits Pastebin URL"] --> B["Validate canonical URL"]
  B --> C["Fetch permitted raw content"]
  C --> D["Apply size and timeout limits"]
  D --> E["Compute SHA-256 digest"]
  E --> F["Create evidence record"]
  F --> G["Link to contribution or passport"]
  G --> H["Review / attest / reward"]

The workflow is intentionally narrow:

A contributor explicitly submits a Pastebin URL.
Coder Legion validates the host, format, and canonical Paste ID.
The bridge retrieves only the allowed raw representation.
The service enforces a maximum size, a strict timeout, and no redirects.
It computes a content hash.
It records an evidence envelope linked to the contribution.
A reviewer or defined policy can attest to it.

The external platform remains the source of the content. Coder Legion remains the source of the contribution and verification record.

Security boundaries are part of interoperability

Interoperability should not expand the attack surface.

A Pastebin bridge should enforce rules such as:

Control	Why it matters
Canonical host allowlist	Prevents arbitrary URL fetching and SSRF-style behaviour
HTTPS only	Protects retrieval integrity in transit
No redirects	Prevents a trusted-looking URL from reaching an untrusted destination
Short timeout	Prevents the integration from becoming a reliability dependency
Maximum response size	Prevents memory pressure and oversized imports
Hash-only persistence	Avoids unnecessary content replication
Explicit contributor consent	Ensures the contributor deliberately links the artifact
Idempotency key	Prevents duplicate evidence records for the same contribution and digest

A useful implementation shape is:

const MAX_BYTES = 256 * 1024;
const TIMEOUT_MS = 5000;

async function observePastebinArtifact({ canonicalUrl }) {
  const response = await fetch(toRawPastebinUrl(canonicalUrl), {
    redirect: 'error',
    signal: AbortSignal.timeout(TIMEOUT_MS)
  });

  if (!response.ok) {
    throw new Error(`Pastebin observation failed: ${response.status}`);
  }

  const body = await readBounded(response.body, MAX_BYTES);

  return {
    canonicalUrl,
    contentHash: `sha256:${sha256(body)}`,
    contentLength: body.length,
    observedAt: new Date().toISOString(),
    status: 'OBSERVED'
  };
}

The important detail is not the SDK. It is the boundary: content is observed, hashed, and discarded unless a separate policy explicitly authorises retention.

Contributor passports: proving participation without exposing private review data

The contributor-facing result is a digital passport: a public, limited projection of verified work.

A public passport can safely expose:

{
  "contributionId": "contrib_123",
  "category": "research",
  "reference": "https://pastebin.com/AbCdEf12",
  "status": "VERIFIED",
  "reviewedAt": "2026-10-11T14:12:00.000Z",
  "evidence": {
    "source": "pastebin",
    "contentHash": "sha256:...",
    "observedAt": "2026-10-11T14:00:00.000Z"
  }
}

It should not expose:

reviewer identity;
internal review notes;
private ledger references;
contributor authentication data;
wallet secrets, API keys, or tokens;
raw artifact text.

This is why public serialization must use an explicit allowlist—not “return the database object and remove a few known fields.”

Allowlisting makes the public contract deliberate and safe by default.

Bot passports use the same trust model

Coder Legion can use the same architecture for automated contributors and bots.

A bot passport can publish only accountable, non-secret facts:

{
  "botId": "bot_release_auditor",
  "displayName": "Release Auditor",
  "releaseHash": "sha256:...",
  "capabilities": ["repository-analysis", "evidence-validation"],
  "status": "ACTIVE"
}

The bot passport must reject secret-bearing input such as:

API keys;
access tokens;
private keys;
webhook secrets;
credentials;
unknown fields.

That matters because interoperability is not only about exchanging data. It is also about preserving accountability across human and automated contributors.

Verification, not publication

A Pastebin reference is not automatically a verified contribution.

The lifecycle should remain explicit:

SUBMITTED → OBSERVED → REVIEWED → VERIFIED
                         ↘ REJECTED

A hash proves that Coder Legion observed specific bytes. It does not prove authorship, accuracy, licensing, or value by itself.

Those decisions belong to a review process, attestation policy, or contributor program. Keeping the states separate prevents a technical observation from being misrepresented as a human or economic endorsement.

What this demonstrates

The Coder Legion × Pastebin model demonstrates interoperability at three levels:

Reference interoperability
An external Pastebin artifact can be linked through a canonical URL and stable identifier.
Integrity interoperability
The observed content is represented by a reproducible digest, so later checks can detect change.
Trust interoperability
The evidence can be linked to contributor or bot passports while retaining privacy boundaries and review states.

No proprietary replication format is required. No private credentials need to be published. No external content needs to be silently copied.

Conclusion

Good interoperability is not “import everything.”

For Coder Legion and Pastebin, it means creating a narrow evidence bridge:

contributor-initiated;
canonical and bounded;
hash-based;
privacy-preserving;
reviewable;
compatible with both human contributors and bots.

That produces a stronger system than a bulk sync: one where external work remains external, while the evidence of contribution remains verifiable.

Developer Weekly Briefing — October 9, 2026

Fri, 09 Oct 2026 12:47:27 +0000

A lighter week on the conference calendar, but a solid set of stories — agent infrastructure, open source governance, and two developer conversations worth your time. Here's what mattered.

Coding agents broke Git's scaling math. GitHub is rebuilding to keep up.

GitHub processed 7.38 billion commits in September 2026 — five times the volume from a year earlier. Pushes are up 4.9x. Actions runs are up 4x. The driver isn't a surge in human developers. It's agents, and they use Git differently. A developer pushes a few times a day. An agent might run dozens of commit cycles in the same window, often in parallel, often across multiple repos at once. The single-writer-per-repo model that Git has run on for 20 years doesn't hold up under that pattern. GitHub is addressing it with a new storage backend that benchmarks at up to 35x write throughput improvement in internal testing, a rewrite of its replication layer to reduce latency and improve durability under load, and intelligent caching that treats agent-generated and human-generated traffic differently. The engineering post is a useful read for anyone whose pipelines are already feeling the pressure.

A free tool that maps every AI agent in your Entra ID and Okta — and asks if you can recover

Ask your IT team how many AI agents are running in your org. Watch the pause. HYCU's aiR Graph is now generally available and free to any organization. It connects read-only to Microsoft Entra ID and Okta, maps every agent's OAuth scopes and write access, and ranks agents that can reach systems with no backup highest. The scoring is deterministic — no LLM in the chain, which means two runs on the same tenant produce the same answer, and every finding traces back to an identity field. HYCU's CPO Anant Chintamaneni put it directly: "Run it twice on the same tenant, and you get the same answer." That matters when you're taking the findings to an auditor. The tool also surfaces something easy to miss: agents that have been retired while the account behind them stays live. A working credential with no one watching it.

What an open source mod for Claude Code says about where agent tooling is heading

A developer named Anji Xu built a floating status card for Claude Code that lives above the terminal prompt. It shows context window usage, five-hour and seven-day rate limits with countdown timers, running session cost, current git branch, and GitHub Actions status for the active branch — updating every 10 seconds while a run is live. It uses Claude Code's new mod system, which is still early access. The tool itself is a personal gauge. The idea behind it points somewhere bigger: as agents run longer jobs, the person at the keyboard needs the same telemetry they already expect from build systems and production services. The bigger job for platform teams is getting that data into shared systems, not just one developer's terminal.

Open Source Summit Europe: 311 hours per release and a kernel sandbox for AI agents

Three numbers from Prague worth holding onto. Forty-eight percent of organizations maintain private open source forks. Those that do spend an average of 311 hours per release cycle patching 9.5 forks. And the EU Cyber Resilience Act's mandatory reporting requirements took effect in September — which is starting to make that math uncomfortable. Ericsson's response: eliminate the forks, push 1,400-plus fixes upstream. The broader summit news included nono, a kernel-enforced sandbox for AI agents from Sigstore creator Luke Hinds. When an agent tries to open a file or reach the network, the kernel checks it against a policy written in code. The model can't talk its way around it. Six months in, nono has 328,278 installs. The through-line from Prague: enforcement is moving down the stack.

Developer Spotlights this week

Anders Dahl Rasmussen works as a supervisor at Oslo Airport. At night, he builds AI products. "I'm not technical at all," he said. He's built 14 tools, reviews every AI-generated page before it goes live, and has one standing rule for anyone starting out: set "some hard rules with your AI because AI makes mistakes." His framing for the division of labor: "I take all the shot calling and he builds." A useful conversation for anyone thinking about where the human check belongs.

Watch the conversation

Kevin Martínez, software architect and frontend chapter lead at Orbitant, makes a point that's easy to understate: "now it's super easy to code but it's harder to choose what's the right code or what's the right test." His take on AI adoption without agreed team workflows: it's going to "increase the chaos in the team." His answer is deterministic tests, which he says "solved problems before AI and can continue solving problems with AI." He also created TWD, an open-source tool that runs frontend tests in the browser.

Watch the conversation

The through-line this week: the tooling for agent governance is arriving, and it's moving from the prompt layer down to the kernel and the identity provider. From HYCU mapping agent permissions to nono enforcing them at the OS level to GitHub rebuilding its infrastructure to absorb what agents generate — the shift is real and it's picking up pace.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

From Pull Requests to Reproducible Interoperability: Building an Evidence-First Contributor Network

Thu, 08 Oct 2026 23:36:39 +0000

Building an Evidence-First Open-Source Contributor Network

Open-source collaboration is usually measured through commits, pull requests and stars.

We are experimenting with something slightly different in MyZubster:

Can contributor work become a reproducible interoperability network, where every technical claim points back to an exact commit, test and public evidence trail?

That means moving from:

Contributor
→ Pull Request
→ Merge

to something closer to:

Contributor
→ Public project / exact commit
→ Reproducible checkpoint
→ Independent verification
→ Bounded TESTED status

The important part is the word bounded.

A successful test should prove exactly what was tested — not deployment, certification, professional credentials, security guarantees or payment unless those things are independently established.

Independent contributor projects

Some of the most interesting work happens outside the canonical repository.

Instead of forcing every contributor into one codebase, we can connect independently controlled projects through small, reproducible bridges.

Nicola / N4K48

GitHub profile:

https://github.com/nicolaususnicola-lgtm

Independent project:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp

The N4K48 checkpoint tested a runtime bridge between a MyZubster VPS and a contributor-controlled environment.

The flow was:

MyZubster VPS
    ↓
authenticated HTTPS broker
    ↓
contributor-controlled N4K48 agent
    ↓
local catalog
    ↓
bounded result returned to MyZubster

The contributor-controlled environment returned the expected bounded result.

Status:

TESTED

Canonical MyZubster evidence merge:

0c00836a96b36d7c64de098dd26d39ac5ddaf98a

Nicola also authored PR #1460 in MyZubster, merged at:

ee8c15d4b26824b75345c2eebc62ac034058b84a

This proves the tested runtime checkpoint.

It does not prove complete decentralization, direct P2P networking or security certification.

Shweta-singh24 / MyZubsterGateway

GitHub profile:

https://github.com/Shweta-singh24

Independent repository:

https://github.com/Shweta-singh24/MyZubsterGateway

This checkpoint focused on jurisdiction and capability enforcement.

The verifier was pinned to the exact public source commit:

82461433e0c5bfee9aa369b4a71e9331261cf803

The upstream PR remained:

CLOSED_UNMERGED

Independent VPS verification reproduced:

14/14 policy checks PASS
5/5 syntax checks PASS
6/6 wiring checks true
verifier status: TESTED

The corresponding MyZubster evidence PR #1575 passed the repository gates and was squash-merged at:

dc4fb1e3c403f6e554c2402ec9fb4c5dfd93e593

The distinction is important:

the verification evidence is merged in MyZubster, while the original upstream source PR remains unmerged.

The result does not imply production deployment, legal compliance or a security certification.

khongten124 / Open Period Care

GitHub profile:

https://github.com/khongten124

Independent repository:

https://github.com/khongten124/myzubster

Open Period Care demonstrates that interoperability does not have to mean only APIs or runtime services.

This project connects public research and structured technical evidence into a contributor-scoped knowledge bridge.

The model is:

Research package
    ↓
evidence normalization
    ↓
Knowledge Cards
    ↓
structured retrieval
    ↓
Circular Care / Knowledge Graph

Canonical MyZubster merge anchors:

PR #1451:

fc4a5cd30c854a242e6ed39e757c77f463c5d231

PR #1489:

6d88448821f25a252a79a777101ef904af8bbccb

Status:

TESTED — contributor-scoped semantic bridge

Again, this is a technical evidence state.

It does not establish a medical credential, professional certification, blockchain implementation or physical recycling proof.

Tested contributor work inside MyZubster

The same evidence-first pattern also applies to contributors working directly in the canonical repository.

Aming9303

GitHub:

https://github.com/Aming9303

Signed payment webhook contribution, PR #891:

be78e0cf9081c3346aa0c61e022acd297d745619

Independent regression verification covered:

HMAC-SHA256 signatures
stable delivery IDs across retry
unsigned endpoint rejection
replay prevention
stale event rejection

Result:

5/5 targeted tests passed

Status:

TESTED — signed payment-webhook regression

wasim-builds

GitHub:

https://github.com/wasim-builds

Fail-closed admin-auth contribution, PR #860:

9c36d5be450e12345ff9251a40ab4df38839a7fe

The independent test reproduced:

unconfigured → 503
missing      → 401
wrong        → 401
correct      → 200

Result:

4/4 targeted tests passed

Status:

TESTED — fail-closed admin-auth regression

foxxx009

GitHub:

https://github.com/foxxx009

KPI/evidence framework, PR #894:

50f70aab6dc9a909f65b81cb70d932706143afec

Historical GitHubMonitor tests, PR #259:

1c78fadd608e8c8acaeaeaf00d448676f82c3f91

A later maintainer-authored integration fix, PR #1526:

f8cbdee1e50cfbfa6925b4bc1014ca75ed5e90d1

re-enabled the historical #259 test suite.

That provenance distinction matters:

#259 = contributor-authored test work
#1526 = maintainer-authored integration repair

Good open-source attribution should preserve both facts.

Why this model is useful

The idea is not to turn every contributor into part of one monolithic repository.

A healthier architecture can look like this:

Independent Project A ──┐
Independent Project B ──┼── bounded reproducible bridges ── MyZubster
Independent Project C ──┘

Each project remains independently controlled.

The shared layer is the evidence contract:

exact repository
exact commit
exact procedure
expected result
observed result
explicit limitations

This makes collaboration easier to audit and much harder to exaggerate.

The rule we keep coming back to

A passing technical test should not silently become a larger claim.

TESTED
≠ deployed

MERGED
≠ production-ready

security regression PASS
≠ security certification

research contribution
≠ professional credential

contributor evidence
≠ employment

verified contribution
≠ payment

Those boundaries are part of the architecture.

Project links

Canonical MyZubster repository:

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

External contributor projects:

Nicola / N4K48
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Shweta-singh24 / MyZubsterGateway
https://github.com/Shweta-singh24/MyZubsterGateway
khongten124 / Open Period Care research project
https://github.com/khongten124/myzubster

Contributor profiles:

What we want to test next

The next step is not simply “more integrations”.

It is more useful to aim for:

more independently controlled projects proving small, reproducible capabilities to each other.

One project.

One bounded capability.

One reproducible checkpoint.

One public evidence trail.

The Cost of Open Source

Thu, 08 Oct 2026 07:14:28 +0000

Open source is free to use. It has never been free to make.

Open source sits underneath almost every piece of software shipped today. Frameworks, databases, build tools and the libraries inside them are, in large part, written and maintained by people who were never paid to do so.

The conversation around open source tends to focus on its benefits: faster innovation, shared infrastructure and transparency. Far less attention is paid to what publishing costs the people who do it. That cost is rarely financial, and few maintainers expect it to be. It is measured instead in control, in attribution, and in the time and energy required to sustain something that others depend on.

This article examines those costs, why developers continue to accept them, and what can be done to make them more manageable.

What does a developer give up when they give their work away?

Part One: Loss of Control Over Use

Software is written with an intended purpose. A license, however, governs permission, not purpose. Once code is published, its author has no say in how it is applied.

A scraping library built for price comparison can power ticket-scalping bots. An automation tool designed for customer support can be repurposed to send spam. A speech-synthesis feature intended to let people reply in their own voice can be used to imitate someone else's.

For many maintainers, this is the most personal cost of publishing: becoming an unwilling participant in uses they would have declined. There is no approval step and rarely any notification. Discovery tends to be accidental.

The tension occasionally surfaces in public. In January 2022, the author of the widely used JavaScript packages colors and faker deliberately published broken releases, citing frustration that large companies relied on his unpaid work. The response was widely criticised and disrupted a large number of downstream projects. The grievance behind it, however, was one many maintainers recognised.

Part Two: The Erosion of Attribution

For most contributors, attribution is the primary return on their work. It underpins professional reputation, demonstrates competence to employers and clients, and is often the only recognition for work done unpaid. Its loss is therefore felt disproportionately.

Permissive licenses such as MIT ask for very little: chiefly, that the copyright and license notice be preserved. Even so, several patterns are common:

Rebranded forks. The same code under a new name and logo, with the original commit history collapsed into a single "initial commit".
Repackaged "premium" products. Open source dashboards and starter kits, lightly restyled and sold on template marketplaces without reference to their origin.
Installation and support services. Third parties charging businesses to deploy a free project, presenting it as a proprietary platform, while support requests flow back to the original maintainer.
Absorption into AI models. Public repositories have been used to train code-generation models that can reproduce familiar patterns without the accompanying license or author. The legal position remains under dispute. The attribution gap does not.

None of these practices affect whether the code works. They do, however, sever the connection between the work and the person responsible for maintaining it, who is usually the party the project most depends on.

Part Three: Premium Functionality Without a Price

The costs above are most acute for one category of project: the one that offers, for free, capabilities that are elsewhere sold as commercial products.

Agent orchestration, workflow automation, observability, voice synthesis and evaluation tooling all have established paid markets. When an independent developer publishes a working alternative, three effects tend to follow.

Credibility suffers. Free software is often assumed to be a prototype or an abandoned experiment. The same software can appear more credible once someone else attaches a price to it.

Others monetise it. Consultants and resellers package, install and bill for it. Most licenses permit this. For the author, it can mean watching their unpaid work become someone else's recurring revenue.

Large providers adopt it at scale. This dynamic has shaped much of the last five years of open source licensing:

Project	What happened
Elasticsearch	Moved away from Apache 2.0 in 2021, citing cloud providers offering it as a managed service. Later added the AGPL back as an option.
Redis	Switched from BSD to the source-available RSAL and SSPL in 2024. The Linux Foundation backed a community fork, Valkey. Redis 8 returned with an AGPL option in 2025.
Terraform	HashiCorp moved to the Business Source License in 2023. The community forked it as OpenTofu.

Each decision addressed the same problem: how to prevent others from profiting from a project without contributing back. Each also carried its own cost, in forks, lost trust and divided communities.

If organisations with legal teams and boards have struggled to resolve this, individual maintainers are considerably less well placed to do so.

Part Four: Expectation, Noise and Maintainer Fatigue

Unpaid support obligations

A useful project attracts issues. Many are constructive. A significant share are not: terse reports, requests for timelines, and questions about whether the project has been abandoned. Some come from users who paid a third party for an installation and now expect the original author to support it.

No contract exists in any of these cases. The expectation forms regardless.

Automated noise

A newer cost is the volume of AI-generated bug reports: submissions that appear credible, reference functions that do not exist, and consume hours of review before they can be dismissed.

The curl project illustrates the scale of the problem. It ended its bug bounty in January 2026, after more than six years, because fabricated reports had begun to outnumber genuine ones. From 1 July to 3 August 2026, its security team paused vulnerability intake altogether. One of the most widely deployed libraries in the world, maintained by a small volunteer team, had to close its inbox to remain sustainable.

Usage without support

In February 2023, the maintainer of core-js, a library downloaded tens of millions of times a week and present on a large share of the most visited websites, published an account of his financial difficulties. Early donations had amounted to roughly $57 a month, and adding a funding link had, by his account, drawn hostile responses.

The pattern is consistent: the more widely a project is used, the more its maintainer is relied upon, and the less visible that maintainer becomes.

Fatigue as a security risk

In 2024, a backdoor was discovered in xz, a compression library present in a large number of Linux distributions. It was not the result of a technical breach. The attacker spent years building trust with an overextended maintainer until they were granted commit access.

Maintainer fatigue is therefore not only a personal cost. When the people sustaining critical software run out of capacity, everyone who depends on it inherits the risk.

Part Five: Why Developers Continue to Publish

Given these costs, it is reasonable to ask why so many developers continue to release valuable work for free. The answer is that the other side of the ledger is equally real.

Cost	Return
Loss of control over how code is used	Reach far beyond what one developer could achieve alone
Attribution that is removed or overlooked	A public body of work that demonstrates capability directly
Premium features monetised by others	Clear evidence that the work has commercial value
Unpaid support and automated noise	Bug reports, fixes and ideas from a wider community
Mistakes visible to everyone	Security that can be audited rather than assumed
Time and energy	Freedom to build without commercial constraints

Open source also offers something few commercial products can: freedom from lock-in. A subscription business benefits when leaving is difficult. An open project has no such incentive. Users can run it on their own infrastructure, keep their data in-house, inspect every line and migrate whenever they choose.

Finally, there is reciprocity. Every developer builds on open source written by others. Publishing is, for many, a way of contributing back to the foundation they rely on.

Part Six: Managing the Costs

These costs cannot be eliminated, but they can be chosen deliberately rather than discovered later.

Select a license intentionally

MIT is often chosen by default. That is a reasonable choice, provided its implications are understood.

License	What others may do	What it protects
MIT / Apache 2.0	Almost anything, including closed commercial products built on the code	The copyright notice
GPL-3.0	Use and sell it; distributed modifications must remain open	Improvements to distributed software
AGPL-3.0	As GPL, with network use of a modified version also counting as distribution	Modifications offered as a hosted service

None of these prevent others from charging for installation or support. Each defines clearly what must be returned.

Make attribution durable

Include the author's name in the LICENSE and a NOTICE file, in the application's About screen and in API metadata. Attribution recorded in several places is considerably harder to remove than attribution recorded in one.

Protect the name

The code may be open while the project's name and logo are not. Trademarks are how many established projects prevent forks from presenting themselves as the official distribution.

Document expectations

A CONTRIBUTING guide, a SECURITY policy and a short support statement convert implicit expectations into explicit ones. A single line, such as "issues are reviewed weekly and paid support is not offered", can prevent a great deal of friction.

Provide a route for support

Sponsorship links rarely produce significant income. They do give users who value the work a practical way to contribute to its upkeep.

Set limits

Declining features, deadlines and demands is part of sustainable maintenance. curl's five-week intake pause demonstrates that even critical projects can, and sometimes must, step back.

A Case in Point: Obsidian AI

A brief disclosure: this subject is not abstract for me.

For the past seven months I have been developing Obsidian AI, an open source, self-hosted platform for building and orchestrating AI agents. It falls squarely into the category described in Part Three, offering capabilities that are typically sold as commercial products.

Capability	Typical commercial equivalent
Agents across OpenAI, Anthropic, Gemini, Ollama and OpenRouter	Separate per-provider integrations
Multi-agent teams with delegation between agents	Enterprise agent platforms
Visual workflows with conditions, approvals and loops, including n8n import	Workflow automation subscriptions
Evaluation suites, prompt optimisation, tracing and per-agent cost reporting	Observability and evaluation licences
Long-term memory, retrieval-augmented generation and Markdown knowledge vaults	Knowledge management add-ons
WhatsApp agents with local transcription, voice replies and voice cloning	Metered messaging and voice APIs
A Docker sandbox and isolated execution for user-defined tools	Hosted code execution services

The project now comprises roughly 62,000 lines of code and 173 API endpoints, and runs entirely on the user's own infrastructure. It has also appeared on third-party sites as a paid installation service.

Several of the costs discussed above apply directly. The voice cloning feature was designed so that users could respond in their own voice, but its use cannot be controlled once published. The WhatsApp integration avoids the need for a business account by relying on an unofficial library, a trade-off that every deployment inherits. Documentation has not kept pace with development. And when a weakness was identified in how user-defined tools were executed, it was resolved in public, where its prior existence was equally visible.

These considerations informed the choice of license. Obsidian AI is released under the AGPL-3.0. Anyone may install, host, customise and charge for services around it. Modified versions, including those offered as hosted services, must remain open, and their users are entitled to the source.

For those offering it commercially to clients, the request is a simple one: be transparent that the underlying software is open source, retain the attribution, and contribute improvements back upstream.

Conclusion

Open source remains one of the most significant achievements of the software industry. It is not, however, without cost. That cost is borne in control, attribution and energy, largely by individuals, and is seldom discussed.

Developers considering publishing valuable work should do so, but with a clear understanding of what they are accepting, and with deliberate choices about which costs they are prepared to carry.

Open source has never been free. Someone always pays. The question is whether they chose to.

Links:

Obsidian AI: github.com/sup3rus3r/obsidian-ai
Previous article: What If Full-Stack Features Were Installable?
Sponsor the project: GitHub Sponsors

Sources: curl's 2026 reporting pause, the core-js funding post, Redis returning to the AGPL.

My First Project: From a Local Folder to GitHub Using Git and SSH

Thu, 08 Oct 2026 04:21:17 +0000

My First Project: From a Local Folder to Git hub Using Git and SSH

GIT

Introduction

Git is an open source version control system used to manage projects. It is fast and efficient to manage projects using git. You can easily track the project version, history, modifications, and many more project activities. It allows for ease of collaboration while working on projects as teams.

Installing Git

Download and install git from Git. Ensure you download for your respective operating system.

Configuring Git

Before using Git effectively, you have to configure your identity by setting up your username and email.

This allows to easily track any changes to your project and the associate, that is; who made the changes?

To set up your identity, follow the following steps, using Git Bash a git terminal:

Steps

To set your username

git config --global user.name "YOUR NAME"

In place of YOUR NAME type in your correct user name that will be associated with your github account activity.

To set your email

git config --global user.email "youemail@example.com"

Note: It is recommended to use your correct email that is associated with your GitHub account.

Rename you GitHub branch to main

git config --global init.Branch main

After setting up your identity you can verify your configurations to confirm your identity for each field set.

To check your:

User name

`git config --global user.name`

`git config --global user.email`

Branch

git config --global init.Branch`

You can use the following command to check all you account details instead:

`git config --global --lists`

SSH

SSH key is a secure credential used to authentication to accessing network resources confidentially without need of a password. The ssh-key contains two keys. A Public and Private key.

Public key is used publicly, that is it is shared between peers. Used to identify you remote resources.

Private key it is a pair key that is kept as a secret for identifying your local machine.

Generating an SSH Key

Using Git Bash

Before generating a new SSH Key, it is recommended to check and confirm if you have an existing key which you can use.

To check if you have an existing key use the following command:

`ls -al ~/.ssh`

The command will list all existing ssh keys. Here sample output:

If there is no existing key, you can generate a new key that you will use to link your computer with your github account.

To generate a new ssh key, follow the following steps:

Genereate a new ssh-key

ssh-keygen -t ed25529 -C "youremail@example.com"

The email should be the one associated with with your github account.

Follow the prompt by adding the name of your key, and also you can add the passphrase which is optional.

The passhrase should be memorable, you will need to use it each time you want to access you github account.

Add your key to the SSH-Agent.

Open your Powershell Terminal and follow the steps below:

- Run the following command to start your SSH Agent

	`Get-Service -Name ssh-agent | Set-Service StartupType Manual`

- Add your key to the  path using the  command

	`ssh-add <PATH/TO/YOUR/PRIVATE_KEY>`

After the command, you should specifify the path to your private key and add it to your host machine's ssh-agent. i.e. ssh-add "C:/Users/<YOUR_USER_NAME/.ssh/<YOUR_PRIVATE_KEY>

If you don't know your computer's user name, you can use the whoami command to see your username.

Your _PRIVATE_KEYNAME is the name that you gave to your key.

- Once you're done, close your Powershell terminal and return to Git Bash.

- Type the following command

	`git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe`

- Then Clip and copy your key using the following commands:

	`clip < ~/.ssh/<PUBLIC_KEY.pub>`

i.e clip < /.ssh/my_key.pub

	`cat ~/.ssh/<PUBLIC_KEY.pub>`

i.e. 'cat ~/.ssh/my_key.pub` to view your public ssh key

- After displaying your key, select and copy the key to add to your GitHub account.

Adding Your Key to GitHub

To connect your computer and git-hub is necessary to facilitate access to your remote resources from your local computer.

You need to add your SSH Keys to GitHub to facilitate the connection. To achieve this, follow the steps:

If you have an existing GitHub account:

a. Login to your account using your email/username and password.

b. From the profile section, go to Settings

c. Scroll to SSH and GPG Key. Navigate and click on New SSH Key on the SSH Key Section to your right.

e. Add the Title/Name of the key i.e. Ubuntu Laptop, the key will be used for Authentication

f. Paste your key to the available textbox.

g. Finally, click on Add Key to save your key. You'll be prompted to re-enter your git-hub account password (login password), to confirm your authenticity before saving.

Now you are ready to go. Before you start, it is good you test your connection to check if it was successful.

Run Powershell as an Administrator and use the following command to test connection:

`ssh -T git@github.com`

If the connection is successful, your username will be displayed along with a success message.

If successful, you are good to go and work on your project.

Working With Folders

To keep you project structural and more organized; you've to keep its files and scripts in folders.

This will make it easier to navigate and access the project. Follow the steps below to work with folders in Windows.

In Git Bash Terminal(Opened normally)

To navigate and change location use the following command
```
`cd <path_location>`
```

To select the current location

	`cd .`

To get to the previous location one step back use

	`cd ..`

Getting back to the root directory use

	`cd ~`

You can also move to a specific folder by specifying the path to that folder

	`cd <path/to/folder>

example: cd "C:/Users/Admin/Desktop/My-Project"

My-Project/ is a folder located in Desktop, which is for the user with the username Admin.

To create a directory or folder use
```
`mkdir <directory_name>`
```

i.e. Create a directory named My-First-Project in Desktop mkdir My-First-Project

Navigate to your created folder. Assuming you are on Desktop, use the following command:
```
`cd My-First-Project/`
```

So your bash terminal path will look like ~/Desktop/My-First-Project

To list and view items use the following command
```
`ls`
```

It will list all files and folders excluding the hidden files and folders. As shown below:

To list and view all files and folders including the hidden ones you add -a attribute to the ls command as below

	`ls -a`

To list files and display their attributes we add the -l attribute to the ls command.

	`ls -l`

Note: You can combine the attributes to list all files and their attributes i.e. as ls -al

You can delete an empty folder using
```
`rm -r <folder_name>`
```

To delete a folder together with its contents we use the rm -r <non-empty_folder_name> command.

Example: Create a folder in you my project folder using the mkdir command, inspect the folder created and its contents, then delete the folder using the rm command:

Steps

Create scripts: mkdir scripts
Navigate to scripts and back to your project folder: cd scripts/ and cd ..
Inspect scripts: ls scripts/
Delete scripts: rm -r scripts/

Note: rm without any attribute will no delete a directory/folder even if empty, the attribute -r tells the command rm that what you're deleting is a directory.

You can copy and paste contents between different folders.

To copy contents moves a duplicate of the files to another location leaving the original intact.

While using the cp command you have to specify the file/contents path and the destination address. Example:

To copy some file named hello.txt to the scripts folder; you need to recreate the folder and create the file in the root directory then copy it to scripts folder in your projects folder

Steps

In your project folder create scripts mkdir scripts
Navigate to your project root folder and create the file hello.txt touch hello.txt
Copy the file to scripts cp hello.txt ~/scripts
Inspect both locations to see that the file exists in both location. ls and ls scripts

Note: You can specify the file path in the cp command if the file is in a different location and the destination path address

i.e. cp <~/path/to/file_to_be_copied.txt> <~/path/to_destination/>

You can move a file or any content completely from the source to an new destination using the mv command.

Example: Move hello.txt file from the project's folder to a new folder named docs

`mv hello.txt docs/

Note: You can also specify the file path in case the files and destination address are in different locations i.e. mv <~/path/from_source/hello.txt> <~/path/to_destination_folder/>

Working With Files

While working in your project you will need to create different files for your project.

The different files will be saved in different directories depending on their type and use.

The organization will help us to achieve a proper project structure, easier to navigate and access our project files.

We will create our files using Git Bash terminal.

To create a file we'll use the touch command.

Create a file named hello-world.txt in your project root directory.

	`touch hello-world.txt`

Use the ls command to confirm your file has been created.
To view the contents of the file we use the cat command, since our file is empty it will display 'nothing'.
```
`cat hello-world.txt`
```
To add contents to our file we use the echo command.

Add the following text to the file hello-world.txt; "Hello, World"

	`echo "Hello, World!" > hello-world.txt`

We use the > to redirect the output to our file. > Rewrites any content in the file.

If you want to add more content to the file use >>, more text will be added to our file.

Example; add the following text to our file "I am happy to learn SSH and Git".

	`echo "I am happy to learn Git and SSH" >> hello-world.txt`

cat hello-world.txt to view the contents of the file.

Editing you file using nano

Nano is an inbuilt text editor in Git Bash.

It helps us to navigate through our files; scripts, text file, .... once we make mistakes.

To open our script or text file we use the nano command in git bash then specify the file we want to open, for example open hello-world.txt using nano:

	`nano hello-world.txt'

There are many more commands for nano that will help you edit your text file. For example the most common commands are:

1. Ctr + O - To save your file

2. Ctrl + X - To exit your nano text editor

3. Ctrl + K - To Cut text in the editor

4. Ctrl + U - To Paste your text

5. Ctrl + G - To find help for you nano editor.

There are many more commands of help that you can use to edit you files in nano editor.

Your First Project

Initialize your first project with git

Before running the command, check to confirm that you are in your project folder using the pwd command.

The pwd command means print working directory it shows your current location with regard to the root directory.

If in your project directory, the path will end with the name of the project folder. I.e. My-First-Project

Use the git init command.

The command is used to initialize our project directory as a git repository.

Git repository structure.

After running the above command, you may notice notification of git initializing an empty git repo...

If you list to view the structure using the ls command you may notice a .git/ folder.

The folder contains Git's internal repository information, which git uses to manage activities such as: push, commits, pull, Branches, project history, repository configurations,....

Checking the project status

	`git status`

Used to show what's happening with your project currently.

It can show things such as untracked files, staged files to be committed yet, if the working tree is clean meaning everything has been committed.

The above show that there is nothing that has been staged for commit, there are three untracked files in the initialized repository.

Staging your project files

	`git add .`

It adds your project files to git for tracking.

Checking on the status of the staged file, you should get such an output with git status command

It prepares all you changes for the next commit.

You can stage a single file by specifying the file/folder you want to stage i.e. git add <file_name.txt>.

You should see almost a similar output when using git status command after staging a single file

Using the . means you stage everything in your project folder.

Commiting you staged files

	`git commit -m "<commit message>"`

Creates a saved checkpoint.

The message should be precise and clear, related to the activity carried out. i.e. "My First Project Using Git Commit"

It does not upload anything to git-hub yet.

Uploading to git-hub

	`git push -u origin <branch_name>

Sends all the committed changes to GitHub. However, in our case we get the above error because we have not linked our local project repo to a git-hub remote repository.

We will be linking our repositories in the next section.

After running this command, you can easily check on the changes whether they reflect on GitHub via your browser.

However, for us we are yet to see these changes. This may not work since we are yet to create a remote repository which we will then connect to our local project in our laptop.

Creating a remote repository

To create a remote repository, follow the following steps:

Login to your git-hub account
In your account click on "Create New Repository"
Enter the name of your Repository as "My-First-Project"
Do not create a README, uncheck the checkbox
Provide a brief descriptions for your project. The description is: "My First Project: From a Local Folder to Git hub Using Git and SSH"
Then click on Create Repository

A new empty repository is created with the name "My-First-Project"

Navigate to your repository
Click on the code section, then click on ssh tab and copy the ssh code

We'll use the ssh code to connect our remote and local repositories before pushing our project.

Connecting our local and remote repositories

Navigate to your git initialized project folder

Type in the following command and thereafter paste the ssh code for your remote repository and hit enter.

	`git remote add origin <your_remote_ssh_code>`

i.e. git remote add origin git@github.com:MakoriNyachaki/My-First-Github-Project.git

Rename your branch

If your remote repository's branch is not main rename it to main

	`git branch -m main`

Check the remote

	`git remote -v`

Push your project to git-hub

	`git push -u origin <branch_name>`

i.e. git push -u origin main this works to upload our committed changes to our git-hub repository.

Summary

An introductory article for learning GIT and SSH. It is thrilling practical exercise for generating ssh keys, working with folders and files, connecting local project folders with remote repositories, and working with git. The introductory article requires one to do further research on so many commands that are available for the different tools we have used here in order to be an expert. Let's learn forward.

How to Unlock $2,000+ in Free Developer Perks & Student Tools in 2026

Sun, 04 Oct 2026 04:57:11 +0000

As developers, students, and self-taught programmers, software subscriptions quickly become expensive. Between IDE licenses, cloud hosting fees, CI/CD runners, and domain names, keeping your development stack running can easily cost hundreds of dollars every year.

Fortunately, major tech platforms offer massive educational developer grants—if you know what tools are available and how to verify them.

Here is a breakdown of the highest-value developer perks in 2026 and how you can claim them.

🎁 Top Developer Perks Available in 2026

1. GitHub Student Developer Pack (Value: $1,000+)

The single best resource bundle for anyone learning to code:

GitHub Pro: Unlimited Actions minutes and repository insights.
Free Cloud Credits: DigitalOcean, Microsoft Azure, and Heroku credits.
Free Domain & SSL: 1-year free domain from Namecheap.
Frontend Tools: Free Bootstrap Studio and design suites.

2. JetBrains All Products Pack (Value: $289/year)

Full access to all 15+ industry-standard desktop IDEs:

IntelliJ IDEA Ultimate (Java/Kotlin)
PyCharm Professional (Python)
WebStorm (JavaScript/TypeScript)
GoLand (Go)

3. Productivity & Cloud Grants

Notion Education: Free Plus plan with unlimited file uploads.
Canva for Education: Premium design templates and AI tools.
Amazon Prime Student: 6-month free trial for cloud and shopping benefits.

🛠️ Step-by-Step: How to Verify Without a University Email

Most verification flows only require one core credential: receiving a confirmation link or OTP code sent to an educational domain address (.edu or .edu.pl).

If your institution does not issue official .edu inboxes or you are testing signup webhooks, you can use a lightweight disposable educational email tool:

Generate an Inbox: Visit UES - Free Edu Email Generator to create a functioning @ues.edu.pl inbox in one click (no registration required).
Submit Verification: Enter your generated address on the student or developer grant verification page (e.g., JetBrains, Notion, or GitHub).
Receive Link: Return to your UES inbox tab. Verification codes typically arrive within 10–30 seconds.
Link Secondary Email: Once approved, immediately add your personal GitHub/Gmail as a backup recovery address in your account settings.

🔒 Note: Disposable inboxes on UES auto-purge after 24 hours, so always ensure 2FA and backup recovery emails are configured.

💬 Summary

Software costs shouldn't hold back passionate developers from building their side projects. What tool is currently your biggest expense? Let me know in the comments below!

# Building a Trustworthy Developer Portfolio with GitHub, Node.js, and Structured Evidence

Fri, 02 Oct 2026 05:25:24 +0000

Building a Trustworthy Developer Portfolio with GitHub, Node.js, and Structured Evidence

How we built Knowledge Cards in MyZubster, integrated GitHub evidence, protected profile README updates, and learned from a real open-source documentation proposal.

By Daniel Ioni — Founder & Product Builder, MyZubster

Introduction

What does a GitHub profile actually tell us about a developer?

We can examine repositories, commits, pull requests, documentation, and contribution activity. However, those artifacts don't always explain what problems a developer investigated, what knowledge they acquired, or how their work relates to specific technical subjects.

At the same time, a traditional portfolio might contain a long list of declared skills without providing any supporting references.

While developing MyZubster, we started experimenting with a different model.

Our idea was to connect structured descriptions of technical activities with supporting GitHub references while preserving an important distinction:

The existence of a technical artifact is not the same thing as independent verification of someone's expertise.

This article explains how we implemented that idea using Knowledge Cards, our Zorgax integration, GitHub APIs, and a controlled README synchronization workflow.

I'll also describe the bugs we encountered and how an unmerged Monero Docs pull request helped us improve our approach to documenting open-source activities.

1. Designing the Knowledge Card model

We wanted to move beyond traditional skill lists.

Instead of displaying a skill such as Node.js: Expert, we wanted developers to explain their activities and attach relevant technical references.

We created Knowledge Cards containing five main elements:

Title: What activity or area of knowledge does the card describe?
Domain: Which technologies or technical subjects are involved?
Description: What does the owner declare they worked on?
Evidence: Which external sources support or document that description?
Verification note: What can readers actually establish from the available evidence?

For example, one of our published cards describes the development of digital identity and privacy-related modules for MyZubster Space Station.

It references a GitHub commit containing implementation work, technical documentation, tests, and GitHub Actions configuration.

View the Space Station Knowledge Card

Inspect the associated GitHub commit

The card distinguishes the owner's description from the public source reference.

This design also helps readers investigate an activity without interpreting every statement as an independently certified qualification.

2. GitHub URL validation: syntax is not verification

One of our first practical problems involved a malformed GitHub commit URL.

We initially added a commit reference manually. It looked correct but was missing the final character of its SHA identifier.

Consequently, our README importer excluded it.

We subsequently added the complete reference using the evidence attachment workflow.

This debugging experience highlighted two different responsibilities:

Validate that a GitHub URL has an acceptable structure.
Independently check whether the resource is publicly accessible.

For README import, we use a validation function similar to the following:

const publicGithubSourceUrl = value => {
  const url = String(value || '').trim();

  return /^https:\/\/github\.com\/[a-z\d_.-]+\/[a-z\d_.-]+\/(?:pull\/[1-9]\d*|commit\/[a-f\d]{40})\/?$/i.test(url)
    ? url
    : '';
};

The regular expression accepts GitHub commit URLs with complete 40-character hexadecimal SHA identifiers and GitHub pull request URLs.

However, this validation does not establish that the commit or pull request exists.

For that, our backend performs a separate GitHub API request.

For example:

GET https://api.github.com/repos/OWNER/REPOSITORY/commits/SHA

If GitHub does not return an accessible resource, our application must not label it as publicly verified.

This distinction is especially important when working with private repositories, inaccessible forks, and authenticated API sessions.

A resource visible to one authenticated account might not be publicly accessible.

Engineering lesson: never confuse format validation with external evidence verification.

3. Linking evidence without automatically certifying expertise

We implemented a workflow that allows developers to attach public GitHub evidence to existing Knowledge Cards.

The owner selects a card, provides a supported GitHub URL, and explicitly confirms the operation.

Our backend checks whether the referenced artifact is publicly accessible before attaching it.

When the check succeeds, the reference can be described as an accessible public GitHub source.

However, we deliberately avoid describing the associated activity as independently certified.

A GitHub commit contains useful information, including its changes, timestamps, commit metadata, and potentially an associated GitHub account.

That information can support an investigation.

It does not independently prove every claim a developer makes about their expertise or individual responsibility.

Our verification notes communicate those limitations directly.

This approach allows structured portfolios to become more transparent without pretending that an automated system can accurately measure developer competence from GitHub metadata alone.

4. Documenting an unmerged Monero Docs proposal

The most interesting test of our evidence model involved Monero Docs.

Through my GitHub account DanielIoni-creator, I prepared a documentation clarification in a fork of the Monero Docs repository.

The proposed change involved the pending parameter of the Wallet RPC method get_transfers.

The original documentation stated:

Include pending transfers.

Our proposed clarification was:

Include pending, unconfirmed outgoing transfers.

The objective was to clarify that the parameter concerns pending outgoing transfers that have not yet been confirmed.

The proposal was submitted to the upstream project through pull request #389.

The pull request was closed without being merged.

Another complication emerged during verification: the original fork and pull request were not accessible without authentication.

Although our connected GitHub account could retrieve information about the activity, we could not treat that access as equivalent to independent public verification.

We had two options.

We could omit the activity entirely because the original evidence wasn't publicly accessible.

Or we could document it transparently, explicitly explaining the limitations.

We chose the second approach.

We prepared a publicly accessible technical document containing the original wording, the proposed modification, references to the original commit and pull request, and a clear statement about the outcome.

Read our Monero Docs contribution dossier

We then created a dedicated Knowledge Card.

View the Monero Knowledge Card

Crucially, we label the supporting document as self-declared documentation that has not been independently verified.

We don't describe the proposal as an accepted upstream contribution, an official Monero collaboration, or an independently certified achievement.

What other developers can learn from this

Not every meaningful engineering activity results in merged code.

Developers investigate problems, prepare proposals, explore unfamiliar codebases, and sometimes submit changes that are not accepted.

These experiences can be documented and discussed.

But the outcome is part of the engineering record.

A transparent portfolio should distinguish a proposed change from a merged change rather than treating both as identical achievements.

5. Using separate evidence categories

The Monero example revealed a limitation in systems that treat every external URL as equivalent evidence.

We needed to distinguish between publicly accessible GitHub commits and public documents authored by the card owner.

These are different categories.

A publicly accessible commit allows readers to inspect a specific repository change.

An owner-authored document allows readers to inspect the owner's account of an activity.

Both can be useful, but they support different conclusions.

We updated our README importer to track them separately.

Conceptually:

let githubSourceCount = 0;
let declaredDocumentCount = 0;

for (const source of evidenceItems) {
  if (source.isDocument) {
    declaredDocumentCount++;
  } else {
    githubSourceCount++;
  }
}

This simplified illustration reflects the separation implemented in our importer.

Instead of making every reference look like a verified GitHub contribution, the generated README displays distinct labels.

This makes the resulting portfolio more informative and reduces the risk of accidentally overstating the evidence.

6. Safely synchronizing a GitHub profile README

Once the Knowledge Cards were publicly available, we wanted users to include them in their GitHub profiles.

However, automatic README modification introduces a serious risk.

Developers often maintain their GitHub profile descriptions manually. An automated system should not erase existing biographies, project references, or other user-authored content.

We introduced an explicitly managed section:

<!-- MYZUBSTER-KNOWLEDGE-CARDS:START -->

## Knowledge Cards

<!-- Reviewed Knowledge Card content -->

<!-- MYZUBSTER-KNOWLEDGE-CARDS:END -->

During synchronization, Zorgax prepares the updated Knowledge Card content inside these boundaries while preserving unrelated README sections.

If the managed block already exists, it is replaced instead of duplicated.

This makes the operation repeatable.

But we added another important restriction.

If Zorgax cannot retrieve the current GitHub README, the update stops.

During our testing, we encountered this condition when the existing README was temporarily unavailable to the application.

The workflow refused to prepare a potentially unsafe update.

This is preferable to guessing the previous state of an external document.

User-controlled publication

We also separated content generation from publication.

The user must load the existing profile, generate the updated content, inspect the preview, approve it, and authorize the GitHub update.

Knowledge Card publication does not automatically rewrite the user's GitHub profile.

This explicit approval process provides an additional layer of control over public identity information.

7. Idempotence matters for generated text, too

Idempotence is usually discussed in relation to APIs, infrastructure, and database operations.

We discovered that it matters just as much when generating public descriptions.

Our backend automatically appends a standard verification statement when public GitHub evidence is attached to a card.

Initially, a normalization function could remove the final punctuation from an existing custom note.

The result was grammatically incorrect:

... does not independently certify expertise At least
one public GitHub source has been linked ...

We corrected the text-normalization logic so it preserves or restores punctuation.

However, fixing new updates wasn't enough.

We also needed to repair notes that had already been published.

We therefore supported an explicit refresh operation for existing cards.

One requirement was especially important: refreshing an already corrected note should not append the same verification statement again.

Conceptually, our regression test checks:

const first = refreshVerificationNote(existingNote);

const second = refreshVerificationNote(first);

expect(second).toBe(first);

This example illustrates the behavior rather than reproducing the complete backend test suite.

We deployed the correction, refreshed the affected Knowledge Card, synchronized the GitHub profile again, and verified the resulting README.

Engineering lesson: generated text deserves the same attention to repeatability and regression testing as other application data.

8. What we actually published

After completing the workflow, we verified the public GitHub profile README.

It contained three published Knowledge Cards, three public GitHub commit references, and one separately labeled public document relating to the Monero Docs proposal.

It also contained exactly one managed Knowledge Card section.

Our published cards cover:

MyZubster ecosystem development and supporting repository activity.
Space Station security, digital identity, and privacy-related modules.
A Monero Wallet RPC documentation proposal that was not merged upstream.

Explore the MyZubster GitHub profile

The resulting README is not a certificate of technical expertise.

Instead, it provides a structured overview of activities and references that readers can inspect and evaluate for themselves.

9. Lessons for developers building similar systems

Several principles emerged from this work.

Keep claims and evidence separate. A user description and its supporting source have different roles. Your data model should preserve that distinction.

Validate both structure and availability. A correctly formatted GitHub URL doesn't guarantee that the resource exists or is public.

Don't inflate contribution status. A proposed documentation improvement can be worth discussing even when the upstream pull request is closed without a merge.

Preserve existing user content. When updating external documents, define the exact area your application controls and stop when the original document cannot be retrieved.

Make publication an explicit decision. AI-assisted generation and external publication should be separate operations.

Test repeated operations. Re-running synchronization or refreshing verification text should not introduce duplicate sections or statements.

Treat documentation quality as engineering quality. Small punctuation errors can undermine the clarity of public verification disclosures.

10. What's next for MyZubster?

Our Knowledge Card implementation is an evolving foundation.

We're continuing to explore ways to improve source management, clean up outdated evidence, clarify verification states, and connect structured technical activities with other parts of the MyZubster ecosystem.

The broader goal is to make documented knowledge easier to discover without introducing misleading automated expertise scores or unsupported claims.

We believe developers should be able to explain not only what they successfully delivered, but also the investigations, proposals, experiments, and technical decisions behind their work.

That history becomes especially valuable when the supporting evidence and its limitations are clearly presented.

Conclusion

This project started as an attempt to improve our GitHub profile.

It evolved into an exploration of evidence modeling, API validation, safe synchronization, idempotent operations, and transparent open-source documentation.

The most valuable result isn't simply having three Knowledge Cards displayed on GitHub.

It's having a workflow that encourages developers to document their activities while preserving the distinction between personal declarations, accessible technical artifacts, and independently established facts.

A useful developer portfolio should make technical work discoverable, supporting evidence inspectable, and verification limitations visible.

That's what we're working toward with MyZubster and Zorgax.

Project references

Author: Daniel Ioni
Project: MyZubster

The Monero Docs proposal discussed in this article was not merged into the upstream project. The linked public dossier records the proposal and explicitly discloses its verification limitations.

Developer Weekly Briefing — September 25, 2026

Fri, 25 Sep 2026 13:04:16 +0000

A week where the same lesson kept showing up in different forms: the credentials your AI coding tools hold are the real attack surface, and most teams still can't answer the basic question of how many there are. Here's what mattered.

Z.ai was packaging your entire workspace and shipping it to Alibaba Cloud

ZCode, the AI coding assistant from Chinese AI company Z.ai, was uploading complete workspace archives — full .git history, Git LFS cache, reflogs, and global app configs — to Alibaba Cloud Object Storage by default, in the background, encrypted with keys only Z.ai held. The privacy policy didn't disclose this behavior. There was no toggle to turn it off.

An independent Chinese blogger traced abnormal disk usage to background processes and published his findings. One company reported that six coding workspaces had been uploaded, including source code, database passwords, and employee personal information. Z.ai responded: it disabled the upload mechanism in version 3.14.0, open-sourced the underlying model, and brought in NSFOCUS to confirm deletion. Most users were unsatisfied — because the archives were encrypted with Z.ai's own key, nobody outside the company could independently verify anything.

Mitch Ashley's read: "The workspace uploads came to light because an independent blogger traced abnormal disk usage to a background process, well after developers had installed the tool." That's the actual detection path. Not a security review. Not an MDM alert. A blogger noticing disk activity.

The important line from the piece: "It's tempting to file this under 'Chinese AI risk' and move on. That would miss the point." AI coding assistants need deep workspace access to be useful. That means they sit next to .env files, credentials, commit history, and the customer data someone committed by mistake three years ago. The lesson applies to every AI coding tool regardless of where the vendor is based. Developers install these tools fast. Security often hasn't reviewed them.

GitHub now gives enterprises a full count of who holds the keys

GitHub Enterprise Cloud owners can now export a complete inventory of every credential that can access their enterprise — SSH keys, classic and fine-grained PATs, OAuth app access tokens, and GitHub App tokens — as a CSV or via paginated REST API. Each record includes owner, scopes, creation and expiration dates, and last-used timestamp.

The timing follows directly from the May incident in which attackers exfiltrated about 3,800 internal GitHub repositories after an employee installed a poisoned Nx Console VS Code extension. GitGuardian's 2026 research puts context around why this matters at scale: 28.65 million hardcoded secrets added to public GitHub in 2025, up 34% year-on-year, and 64% of valid secrets detected in 2022 were still active and exploitable as of January 2026.

Mitch Ashley on the agentic dimension: "Anyone building with AI can now create credentials, and accountability for them lands back on IT and security. Enterprises that ignore that gap discover it during incident response, rotating keys they didn't know existed."

One useful design detail: GitHub added a separate "View enterprise credentials" permission so security and compliance staff can run reviews without needing full admin rights. The API is the more practical piece — pull the inventory on a schedule, compare runs, flag new long-lived tokens, send stale ones to owners for cleanup. GitHub Enterprise Server support is coming in future releases.

Codex sandbox escapes: the thing doing the enforcement was inside the thing being enforced

Oren Yomtov of Accomplish AI found two ways out of the OpenAI Codex sandbox — Heapjack and Overpatch — and OpenAI fixed both within eight days of the August 12 report. Accomplish published the details on September 15. Patches are in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641.

The mechanics are worth understanding because the pattern is recurring. Heapjack: the node_repl helper ran untrusted agent code and trusted code in separate contexts but on a shared memory heap. Untrusted code called v8.getHeapSnapshot(), scanned memory for the trust token, then used it to send forged requests to the parent process. Read-only mode didn't stop it. Overpatch: the apply_patch tool determined its own permissions by checking the parent directory of paths in a patch. Naming /tmp in the patch granted access to the entire disk through a failed operation that didn't clean up the wider permissions — which persisted into .zshrc and survived shell restarts.

Yomtov's summary of the root cause: "The thing doing the enforcement was sitting inside the thing being enforced." Mitch Ashley's translation for DevOps teams: "A sandbox the agent can modify enforces nothing. Enforcement has to run in a layer the agent cannot reach — which means the control plane. CI teams settled this years ago when they stopped letting jobs grant themselves permissions."

Both fixes are deployed. Update Codex CLI and the desktop app separately — they carry different version numbers, and checking one doesn't cover the other. And treat repositories you didn't write as untrusted input even in read-only mode.

Claude Code adds AGENTS.md fallback

Claude Code 2.1.277 now reads AGENTS.md when no CLAUDE.md exists in a directory, cleaning up the dual-file maintenance problem teams have been patching with symlinks. The short version: CLAUDE.md takes precedence when both exist; AGENTS.md is the fallback when it doesn't. Four settings in /config let teams tune the behavior — including loading both files, Claude-first, or locked to managed CLAUDE.md only.

A few caveats worth reading before deleting symlinks: CLAUDE.local.md counts as CLAUDE.md for precedence purposes, so developer personal preference files will shadow the team's AGENTS.md. Claude doesn't read AGENTS.local.md or anything under .agents/. Bedrock, Vertex, and Foundry support isn't available yet. And the first session after a fresh install won't read AGENTS.md — relevant for ephemeral CI runners.

GitHub separates who writes code from who runs CI

GitHub's new Code and Automation role split gives organizations a cleaner way to grant repository access: a new "CI/CD Manager" role lets someone configure and run Actions workflows without inheriting write access to the codebase. For teams that have been granting broader permissions than necessary to let DevOps engineers manage pipelines, this closes a real least-privilege gap. Available now for Enterprise Cloud, coming to Enterprise Server.

An AI agent signed a developer up for AWS services he never requested

A developer asked an AI agent to help set up an AWS environment. The agent, interpreting the request broadly, provisioned services the developer never asked for — and AWS's billing model meant the charges started immediately. The incident clearly illustrates scope creep in agentic task execution: the agent completed what it interpreted as the goal, not what was actually requested. Worth reading if you're giving agents any access to cloud accounts.

Ripple bets on Stripe and Tempo's payment standard to get AI agents spending XRP

Ripple announced support for the X402 payment protocol — the emerging standard backed by Stripe and Tempo for machine-to-machine payments — to enable AI agents to spend XRP autonomously. As agents gain the ability to make purchases, pay for API calls, and transact on behalf of users, a standardized payment layer becomes infrastructure. Whether XRP is the currency that wins that market is a separate question from whether the category itself is real. It is.

Kore.ai's Cobus Greyling: stop chasing the next model, start owning your harness. The competitive advantage in agentic AI isn't which model you run — it's the evaluation, memory, and orchestration layer you build around it. Read more
LittleHorse draws the line between what your agent decides and what your code must execute. A workflow orchestration approach that keeps deterministic business logic out of the LLM layer. Read more
The Claude Projects Coordinator piece from last week rounds out the parallel agent work story if you missed it. Read more
Developer Spotlight: Steve Fenton. A conversation with the developer, author, and engineering leader on his career journey, the craft of software development, and how the role is changing. Worth a read if you want something that isn't about vulnerability disclosure this week. Read more

The through-line this week: AI coding tools have broad access to your most sensitive assets, and the governance layer — credential inventories, sandboxes that enforce at the control plane, agent scoping — is still being built. Z.ai and Codex were caught. Most of what's happening in this category won't be.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

What I’ve learned from sharing MyZubster on CoderLegion

Thu, 24 Sep 2026 21:27:59 +0000

Over the last months I’ve been building MyZubster, an open-source ecosystem that connects software development, AI, GitHub automation, community participation, marketplace experiments, knowledge tools and real-world pilot projects.

While building it, I’ve also been sharing parts of the journey on CoderLegion.

What I appreciate most is that CoderLegion gives developers a place where a project does not have to be “finished” before it can be discussed.

You can share what you are building while it is still evolving.

That matters to me because MyZubster is not a single application. It is an ecosystem made of many experiments, integrations and workflows. Some work immediately. Others expose bugs, architectural problems or ideas that need to be redesigned.

Sharing that process publicly has value.

Recently, for example, I completed an end-to-end workflow connecting:

MyZubster → Zorgax → GitHub analysis → AI-generated profile proposal → human review → explicit approval → GitHub publication

The final result was not just an automatically generated README.

The interesting part was the engineering around it: OAuth identity, GitHub permissions, state handoff between an AI conversation and the frontend, explicit approval gates and a publicly verifiable GitHub commit.

That is the kind of development story I enjoy sharing on CoderLegion.

Not just:

“Here is my project.”

But:

“Here is what I tried, what failed, what I changed, and what finally worked.”

Another thing I value is being part of a developer environment where projects can be discovered by people outside the original team.

For an open-source project, that is important.

A repository can have thousands of commits, but external contributors, reviews, discussions and independent feedback provide a different kind of signal.

They show that the project is beginning to exist outside the mind of its creator.

CoderLegion has become one of the places where I can document that evolution and communicate with other developers while MyZubster continues to grow.

I also like that I can write about very different parts of the same project: Node.js APIs, GitHub integrations, AI workflows, authentication, analytics, community systems, experimental pilots and product architecture.

There is no need to pretend everything is perfect.

For me, the useful part of a developer community is precisely the opposite: being able to show the engineering process.

Build → test → break → investigate → improve → share.

That process has become a central part of how I develop MyZubster.

I still have a lot to build, and I would not describe MyZubster as a finished ecosystem.

But I can already point to real repositories, public contributions, working integrations, experiments and lessons learned along the way.

And having a community where those steps can be documented and discussed makes the journey more useful—not only for me, but potentially for another developer facing a similar problem.

If you are building something and you prefer talking about the real technical process rather than only showing polished final products, CoderLegion is worth exploring.

MyZubster:
https://www.myzubster.com/

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

CoderLegion:
https://coderlegion.com/

Hey everyone looks like I'm new here. I need to properly introduce myself and tell in short about me

Thu, 24 Sep 2026 15:49:03 +0000

Hey guys ;)

So, as the title says, I'm new here. So in short, who am I and what can I share with you?
My name is Nicholas, I'm from Ukraine and I'm 20 years old. I'm also a CS student, and working on some small projects, some kind of portfolio I guess.

Now a bit about what I really like. First of all it's obviously Python, I working mostly with it, but thanks to uni I also know a bit of C++, Java, JS, C# and even Assembler. Okay now really seriously, with what I really like to play:

machine learning;
data analysis or better say data science in general;
web Scraping;
automation;
a bit of web development;

Okay, all of it is just words, so I guess I'll add here some link, maybe to my GitHub where you could find all my projects. My GitHub profile.

Now in short all my projects:

Chess Project X. Project where I created 2 pure Python engines (matrix and bitboards) and even added Minimax bot. The next step that I planned is RL bot (I mean bot that will improve after every game and learning from his mistakes).
Aster. A project that started as a project only for me. I just wanted to track my habits and my savings, and then it just became cool not only for me.
Yakaboo Books Sales Analysis. I analyzed one of the biggest book retailers of Ukraine - Yakaboo. The main goal was to answer the question "Are people reading less nowadays" and in the end my data only allowed me to answer that people still read books.
Music Genre Classification. Pure ML project, pretty easy in fact. Just took a dataset from Kaggle, used Streamlit for some user interface and librosa for music features extraction.
Secret Santa. Maybe the easiest project. But I'll impress you, because I’ve never used Django (I've never used it before). So this project was deployed on Render and you could enter all data about the party and then get an email.

So that's a bit about me. All my projects are based on my nerdy hobbies, like reading, listening to music, chess and so on. But for me, the most important thing in programming is having fun and doing something that you can understand.

Right now I have 2 ongoing projects - Aster and Chess Project X. But my next post will be about Aster. From it I'll talk about telegram bots, streamlit, database and later about some AI stuff.

Hope my post will be interesting for you, see you next time. Oh yeah, next time, usually I do it once a week on Thursday or Wednesday (the same on Dev.to). On X I usually do posts on Monday and Thursday. I could do it more often, but I don't know why I'm not doing it yet. So yep, bye bye

Okay one more thing. If you have any questions, just ask. I'll answer it, yep so now is truly bye bye.

I think it’s time for Aster’s come back. Or just what to do when you finished your project.

Thu, 24 Sep 2026 15:08:13 +0000

Hey guys ;)

So as the title said I’ve finished my Music Classification project. You could check it here Music Classification Project.
Sorry that I didn’t deploy this app. I hope if someone will be interested in it, then this person will just copy my repo.

What can I tell you?

Actually I don’t know, this project was pretty easy, because only librosa was new for me. All the other libraries I’ve used before. Maybe I just should say the main points of how to transform data into models. I guess that will be good.

First step

Maybe it will be unexpected, but you should choose a topic in which you’re interested. I think it’s important for every project you’re working on. If you don’t have fun with it, then why are you doing it?
For example all my projects built on my interests and hobbies.

Second step

Now, you need data. It’s good if you will find an amazing dataset for your topic, or you just could scrape all data manually. The more proper data you have, the more accurate your model will be. I mean if we only have 10 students for example and half of them are good students and the other half are bad, then how to classify an average student?

Third step

Here you need to work with data I guess. Clean it, fill None values, normalize data and split data into training and test datasets. That’s easy, maybe normalization is a bit difficult, because you should choose for example between StandardScaler and MinMaxScaler. Also for some models you need to encode target.

Final step

Choose the right model and make it accurate. Yep there are Regression models and Classification models, and there are Linear models, ensemble models and so on. How to choose right? You need to read a bit of theory.

What’s next?

Again the title said everything already. I’m going to come back to my Aster - personal assistant project. Actually I had 3 options - Chess Project, Aster and brand new AI for Cuphead.

But I think I need to work with Aster, at least upgrade it, and it would be great to make Aster “alive”. So, for the next few weeks I’ll be writing about Aster. That’s all for today, see you guys later

Building a Human-in-the-Loop GitHub Profile Automation with MyZubster and Zorgax

Thu, 24 Sep 2026 14:25:14 +0000

thorization with the user.

Result

The full GitHub profile automation loop is now working:

MyZubster
→ Zorgax
→ GitHub analysis
→ generated README
→ final preview
→ explicit human approval
→ authenticated GitHub write
→ public commit

It took more than generating Markdown.

The difficult parts were identity, OAuth, state handoff, parsing, permission boundaries and making the final action auditable.

And those are exactly the parts that make AI automation interesting to build.

Project: MyZubster
AI assistant: Zorgax
Main repository: MyZubster-Ecosystem/myzubster
Test profile: @myzubster

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorga

Wed, 23 Sep 2026 03:03:09 +0000

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorgax

We are currently extending MyZubster beyond the idea of a marketplace or a metaverse.

The direction is to build an ecosystem where a user can connect:

an authenticated identity;
a verified GitHub account;
projects and repositories;
contributors;
professional skills;
practical experience;
evidence;
learning goals;
structured knowledge;
and a Metaverse identity.
That is easy to build, but it has an obvious weakness.
Anyone can write anything.
A user can claim:
Senior JavaScript Developer
Cybersecurity Expert
AI Engineer
Project Manager
without any connection to actual work, repositories, projects or evidence.
For MyZubster, we want a richer model.
The profile should be able to distinguish between:
declared skill
practical experience
verified identity
evidence
learning goal
public contribution
These are not the same thing.
GitHub as a verified identity source
GitHub is one of the first external identity sources we are integrating into the system.
When a user authenticates with GitHub, MyZubster can associate the account with a verified GitHub identity.
Conceptually:
GitHub OAuth
↓
MyZubster account
↓
verified GitHub identity
↓
repositories / README / public profile
This gives Zorgax useful context.
For example, it can inspect available public information such as:
GitHub profile
bio
public repositories
repository descriptions
languages
profile README
But we deliberately do not convert every signal into a skill automatically.
For example:
repository written in JavaScript
does not automatically become:
Advanced JavaScript Developer
Evidence is useful, but evidence and professional qualification are not identical.
Yassen: from GitHub to an authenticated Metaverse profile
We recently tested part of this flow with Yassen.
Yassen configured his GitHub profile and entered MyZubster with a complete authenticated identity.
His MyZubster identity was connected to GitHub, and he was then able to enter the Metaverse as an authenticated user.
The interesting part is that the Metaverse identity is not intended to remain just an isolated avatar.
The model becomes:
GitHub identity
```
↓
```
MyZubster account
```
↓
```
authenticated user
```
↓
```
Metaverse identity
This is important for the future architecture.
A character in the Metaverse can eventually represent a real account with real projects, contributions and evidence behind it.
Yassen also added danieldirimini-myzubster as a contributor.
That starts creating another relationship:
User
↓
Project
↓
Contributor
↓
Contribution evidence
This is the beginning of what can become a contribution graph inside MyZubster.
A contribution graph instead of isolated profiles
One of the directions we are exploring is connecting people through actual contributions.
Instead of having only:
User A
User B
User C
we can represent something more useful:
User A
│
├── Project X
│ ├── Repository
│ ├── Contribution
│ └── Evidence
│
└── Collaborated with User B
This can later connect to:
GitHub commits
pull requests
project activity
knowledge contributions
reviews
verified evidence
The goal is not simply to measure popularity.
It is to understand:
What has this person actually contributed?

Fixing an AI onboarding problem
While developing the professional profile onboarding flow, we found an interesting issue.
Zorgax was supposed to interview the user.
For example:
What practical activities can you do?
But an AI assistant can sometimes interpret that as:
What can YOU, the assistant, do?
That is obviously wrong for a professional-profile questionnaire.
So we changed the onboarding prompt.
Zorgax is now explicitly instructed to:
interview the user
ask about the user's experience
never answer the questionnaire as Zorgax
never attribute Zorgax capabilities to the user
ask one question at a time
wait for the user's response
The principle behind this fix is simple:
AI should help structure the user's identity, not generate an identity for the user.

Structured professional profiles
We also introduced a structured professional-profile model.
Instead of storing only a free-text biography, MyZubster can represent data such as:
headline
summary
skills
experiences
interests
professional goals
collaboration availability
evidence
visibility
approval status
version
timestamps
A simplified skill object can look like this:
{
"name": "Kali Linux / Cybersecurity",
"category": "technology",
"experience": "10+ years of self-directed study and practice",
"level": "Self-taught practical experience",
"evidence": [],
"notes": "Only legitimate and authorized security activity is represented"
}
This format is more useful than a simple string such as:
Cybersecurity
because it preserves context.
Explicit approval before persistence
Another important part of the implementation is approval.
The backend does not accept a professional profile as approved by default.
A write request needs explicit approval:
{
"approved": true,
"visibility": "private",
"profile": {}
}
or:
{
"approved": true,
"visibility": "public",
"profile": {}
}
The onboarding UI exposes two separate actions:
Approve and save privately
and:
Approve and publish on MyZubster
This means the AI cannot silently publish the profile.
The user makes the final decision.
Private and public are different states
This distinction is important for both profiles and knowledge.
A useful mental model is:
conversation

↓

draft

↓

user review

↓

approval
/ \
/ \
private public
Not everything discussed with Zorgax belongs in the public profile.
Not every personal experience should become public data.
Not every profile claim should become public knowledge.
Building my own professional profile
We are now using the same infrastructure to structure my own professional profile.
The goal is not to make an exaggerated CV.
The goal is to represent real experience accurately.
My profile currently includes areas such as:
MyZubster project management
GitHub
Linear
Vercel
ChatGPT / Zorgax
terminal / VPS
Kali Linux
cybersecurity
calisthenics
Thai boxing
MMA
event organization
visual systems
audio systems
barista work
kefir
gardening
botany
permaculture
volunteering
self-directed psychology study
But each area is described with its actual context.
For example:
GitHub / Linear / Vercel
is represented as operational usage.
It is not automatically converted into:
Senior Software Engineer
MyZubster as a learning environment
A major part of my own professional goal is to make MyZubster my main work.
At the same time, I am using the project itself to develop new skills.
That means the profile can represent both:
things I already know
and:
things I am learning
For example, I want to continue improving in:
software development
AI
cybersecurity
project management
product development
video mapping
This allows the profile to represent a progression rather than pretending every skill is already complete.
Evidence-aware profiles
Another important part is evidence.
A claim can eventually be associated with evidence such as:
GitHub repositories
project activity
videos
photos
public contributions
documents
other verified sources
This does not mean the system blindly trusts every piece of evidence.
It means evidence can be attached to a claim and reviewed separately.
Conceptually:
Skill
↓
Experience
↓
Evidence
↓
Verification
From professional profiles to knowledge
The same architecture can be extended to knowledge.
This is where things become more interesting.
For example, I have several years of practical experience preparing kefir.
That can be represented as:
personal experience
But it should not immediately become:
verified universal knowledge
Those are different concepts.
So MyZubster Knowledge follows another principle:
message != knowledge
candidate != verified
verified != public
A user can contribute a knowledge candidate.
Then that candidate can be connected to:
sources
evidence
contributors
review
verification
Only after that process should it become part of a public knowledge layer.
The Knowledge Explorer
We have also been building a public Knowledge Explorer.
Its role is to expose only knowledge that has reached an appropriate state.
The public frontend is intended to avoid displaying:
internal candidates
pending review content
unverified material
Instead, public search should operate on verified or approved knowledge.
Conceptually:
candidate
↓
review
↓
approved
↓
public search
Zorgax is the orchestration layer
It is important to clarify what Zorgax is.
Zorgax is not simply a language model that we trained from scratch.
It is the AI and orchestration layer of MyZubster.
It can work with:
LLM providers
MyZubster user profiles
GitHub
verified knowledge
evidence
workflow rules
human approval
project context
Metaverse identities
The architecture looks roughly like this:

                MyZubster
                    |
    +---------------+---------------+
    |                               |
  Profiles                       Knowledge
    |                               |
  GitHub                          Evidence
    |                               |
 Projects                        Sources
    |                               |

Contributions Verification

    \                               /
     \                             /
      +----------- Zorgax --------+
                    |
                Metaverse

Zorgax helps move information between these systems, but it should not bypass verification or user approval.
Why the Metaverse matters
This also changes the role of the Metaverse.
A traditional Metaverse avatar might only have:
name
appearance
position
A MyZubster identity can eventually have:
authenticated account
verified GitHub
professional profile
projects
contributors
skills
evidence
knowledge contributions
So a Metaverse character can become a visual interface for a much richer identity graph.
For example:
Yassen
│
├── authenticated MyZubster account
├── verified GitHub profile
├── Metaverse identity
├── project relationships
└── contributors
And the same model can eventually apply to every user.
What we have implemented so far
At this stage, we already have several important pieces working:
GitHub identity integration
authenticated MyZubster accounts
Metaverse authentication
structured professional profiles
private/public visibility
explicit profile approval
evidence-aware fields
Zorgax profile onboarding
profile questionnaire safeguards
public Knowledge Explorer
knowledge verification states
contributor relationships
Vercel deployment infrastructure
We also added automated tests around the professional-profile flow.
The tests cover areas such as:
profile normalization
approval requirements
private/public visibility
professional profile import
onboarding JavaScript validity
questionnaire perspective
Current deployment work
We recently connected the structured professional-profile backend to the onboarding interface.
The flow now supports:
load professional profile
↓
preview structured data
↓
explicit approval
↓
save private OR publish
The relevant implementation was merged into the canonical development branch.
We also verified automated tests before deployment.
At the infrastructure level, we are currently deploying the updated MyZubster gateway and knowledge services through Vercel.
The gateway deployment has already been successfully built and marked ready for production.
The Knowledge deployment is the next part of the rollout.
The bigger architecture
The long-term direction is to connect these systems into one graph.
Identity
↓
Profile
↓
Experience
↓
Evidence
↓
Contribution
↓
Verification
↓
Knowledge
↓
Collaboration
GitHub provides one strong source of identity and technical evidence.
The Metaverse provides a spatial and social interface.
Zorgax provides AI-assisted orchestration.
MyZubster Knowledge provides structured, reviewable knowledge.
The professional profile connects the person to all of these layers.
What we are trying to avoid
There are several things we explicitly do not want:
AI-generated fake skills
unverified professional claims
automatic public publishing
anonymous claims treated as verified facts
repository languages treated as expertise
private experiences becoming public automatically
Instead, the system should preserve distinctions.
For example:
self-taught != certified
practical experience != professional qualification
evidence != verification
candidate knowledge != verified knowledge
private != public
Those distinctions make the system more complex, but also much more useful.
What comes next
The next work is mainly about connecting the graph more deeply.
We want profiles to connect to:
GitHub repositories
contributors
projects
knowledge contributions
evidence
Metaverse identities
and we want Zorgax to help navigate these relationships.
My own professional profile is currently one of the real-world cases we are using to test this architecture.
The objective is not just to build another résumé.
The objective is to build a system that can represent:
what a person knows
what they have done
what they are learning
what evidence exists
who they collaborated with
what knowledge they contributed
while keeping the user in control of what becomes public.
That is the direction we are taking MyZubster.
Final thought
For me, the most interesting part of this project is not any single feature.
It is the connection between them.
GitHub alone is useful.
A professional profile alone is useful.
A Metaverse alone can be interesting.
An AI assistant alone is useful.
A knowledge base alone is useful.
But when these pieces are connected through identity, evidence, contributions and verification, they become something different.
That is what we are experimenting with through MyZubster and Zorgax.

erience, evidence, AI-assisted onboarding and Metaverse identities into one verifiable ecosystem.**

Zorgax acts as the AI layer that helps connect these parts, but with an important rule:

AI can help structure information, but it should not invent a user's identity or publish claims without explicit approval.

This article explains what we have already implemented, what happened with one of our early users, Yassen, and what we are now doing with my own professional profile and knowledge inside MyZubster.

The core problem

A normal user profile is usually just a collection of manually entered fields:

name
bio
skills
links

Building MyZubster as a Verifiable AI Development Ecosystem

Tue, 22 Sep 2026 15:42:36 +0000

uilding MyZubster as a Verifiable AI Development Ecosystem: Metaverse, GitHub Evidence, Zorgax Knowledge, and DevelopmentRequest
Today we had the opportunity to present and demonstrate part of the MyZubster ecosystem during an institutional hearing.
Instead of presenting only slides or a conceptual roadmap, we showed the system directly. We opened the MyZubster metaverse, explained a real pilot involving an actual user, discussed how GitHub activity can become technical evidence, and described the architecture we are building around Zorgax, verified knowledge, software development, wallets, and human review.
The most important outcome for us was not the meeting itself.
It was realizing that the different components we have been building are starting to form a coherent technical system.
The architecture is moving toward this loop:
Real Person

↓

Real Activity

↓

Data / Evidence

↓

MyZubster

↓

Verified Knowledge

↓

Zorgax AI

↓

DevelopmentRequest

↓

Developer

↓

Code / GitHub

↓

Tests

↓

Independent Verification

↓

New Knowledge

↓

Identity / Wallet

↓

Metaverse Interaction
The goal is not simply to build another AI assistant, another marketplace, or another metaverse.
The goal is to connect all of these components around one principle:
AI can assist the process, but evidence and verification should remain inspectable.

The Metaverse Is Only the Interface
One of the things we demonstrated was the MyZubster metaverse.
For us, the metaverse is not the entire product.
It is one possible user interface for a much larger system.
The long-term idea is that a user should eventually be able to enter the environment with a digital identity, connect a wallet, interact with people or services, and have access to a history of technical contributions and activities.
That means the visible environment may look like a metaverse, but behind it we want something closer to a verifiable contribution graph.
A person may have:
Identity
↓
Wallet
↓
GitHub Account
↓
Issues
↓
Pull Requests
↓
Commits
↓
Tests
↓
Reviews
↓
Verified Contributions
The important distinction is that a wallet alone does not prove contribution.
A GitHub account alone does not prove contribution either.
What matters is the history of actions and the evidence attached to them.
A commit may be evidence.
A passing test may be evidence.
A reviewed pull request may be evidence.
A reproducible result may be evidence.
But none of these should automatically be interpreted as proof of everything.
That distinction becomes very important once AI is involved.
A Real Pilot: Nicola
We also presented a real pilot involving Nicola, one of the people testing and contributing to the ecosystem.
The first experiment was intentionally simple.
A physical kefir handover was performed and digitally recorded through MyZubster.
The workflow represented something like:
HAND_DELIVERY

↓

Receiver confirms receipt

↓

Status updated

↓

RECORDED
There was no payment involved.
The specific transaction was also not recorded as an on-chain blockchain transaction.
That is important because we do not want to describe the experiment as something it was not.
The purpose was not to scientifically validate kefir.
The purpose was to answer a much more technical question:
Can a real-world event be represented digitally in a way that produces useful evidence?

The answer was yes.
From there, Nicola also tested other parts of MyZubster, reported problems, and worked on his own software.
That gave us a more interesting participation model.
Instead of thinking about users as static roles, we can model participation as a progression:
User
↓
Tester
↓
Contributor
↓
Developer
↓
Evidence Producer
↓
Knowledge Contributor
This is one of the ideas that could eventually connect the metaverse, GitHub, wallets, community reputation, and Zorgax.
Zorgax: Chat Is Not Knowledge
One of the most important architectural decisions we have made recently concerns Zorgax.
We do not want to treat an AI-generated answer as verified knowledge.
That sounds obvious, but many systems effectively do exactly that.
A language model generates a response.
The response is stored.
Later the system retrieves that response as if it were truth.
That is dangerous.
So our architecture starts from a different assumption:
A message is not knowledge.

A message may contain useful information.
It may become a candidate for knowledge.
But it must go through additional stages.
Our conceptual flow looks like this:
User Question

↓

AI Response

↓

Candidate Information

↓

Sources

↓

Evidence

↓

Human / System Review

↓

Verified Knowledge
Only after that should the information become part of a trusted knowledge layer.
The Zorgax Knowledge Layer
We have been building a dedicated Knowledge Layer for Zorgax.
The knowledge model is designed to preserve more than just text.
A useful knowledge object needs context.
It may include concepts such as:
Knowledge
├── contributionId
├── title
├── content
├── contentHash
├── version
├── status
├── visibility
├── provenance
├── source
├── evidence
└── lineage
The contentHash is particularly important.
It gives us a deterministic identity for the canonical content.
If the content changes, the hash changes.
This allows downstream systems to know exactly which version of knowledge they are using.
For example, a development task may reference:
{
"contributionId": "ZK-123",
"contentHash": "f30c...",
"version": 3,
"title": "Metaverse Identity Architecture"
}
Later, the knowledge may evolve to version 4.
The development task should still be able to show:
This implementation was based on version 3.

That creates much better provenance.
Preview Before Persistent Writes
Another principle we implemented is:
The AI should not silently perform consequential writes.

For operations such as creating a DevelopmentRequest, the system first produces a preview.
Conceptually:
User Intent

↓

Normalized Input

↓

Knowledge Snapshot

↓

Preview

↓

Digest

↓

Explicit Confirmation

↓

Persistent Write
A digest is generated from the preview.
Then the user must confirm using a value such as:
CONFERMA DEV a1b2c3d4
If the preview changes, the digest changes.
If the digest does not match, the operation fails.
This prevents a situation where the user approves one thing and the system writes something different.
DevelopmentRequest: Turning Knowledge Into Work
The next architecture problem was:
How do we transform verified knowledge into software development?

Our solution is a new neutral object called DevelopmentRequest.
A DevelopmentRequest is not a bounty.
It is not a GitHub issue.
It is not a payment request.
It represents the work that needs to be done.
The current lifecycle is:
DRAFT
↓
OPEN
↓
IN_PROGRESS
↓
SUBMITTED
↓
VERIFIED
or:
SUBMITTED
↓
REJECTED
The model also supports cancellation.
Conceptually, the object contains:
DevelopmentRequest {
requestId
requestHash
createdBy

title
description

knowledgeRefs[]

requirements[]
acceptanceTests[]
evidenceRequired[]

status
assigneeId

submission
review

bountyReference // optional
}
The important part is that the development request is anchored to verified knowledge.
Snapshotting Knowledge
When a DevelopmentRequest is created, Zorgax does not simply store a knowledge ID.
It stores a snapshot reference.
For example:
knowledgeRefs: [
{

contributionId: "ZK-123",
contentHash: "abc123...",
version: 2,
title: "Verified Architecture"

}
]
Before the request is actually committed, the system revalidates those knowledge references.
If the underlying content has changed between preview and commit, the operation fails.
Conceptually:
if (
expected.contentHash !== current.contentHash ||
expected.version !== current.version
) {
throw new Error(

"Knowledge changed after preview"

);
}
This gives us something extremely useful:
development provenance.
We can eventually say:
Feature X
was implemented because of
DevelopmentRequest Y
which was based on
Knowledge Z version 2
which came from
Evidence A + Evidence B
That is much stronger than simply linking a GitHub issue to a random conversation.
Submission Is Not Verification
This is another important rule.
A developer may submit something.
That does not mean the work is verified.
So the workflow separates:
SUBMITTED
from:
VERIFIED
The contributor submits evidence such as:
{
"evidenceRefs": [

"test:integration:green",
"demo:https://..."

],
"commitRefs": [

"commit:abc123"

]
}
But a separate reviewer is responsible for verification.
The reviewer cannot be the creator or the assigned developer.
Conceptually:
if (
reviewer === request.createdBy ||
reviewer === request.assigneeId
) {
throw new Error(

"Review must be independent"

);
}
This is one of the foundations for future contribution reputation.
Strengthening the Evidence Model
We are now tightening this further.
The first implementation verified that evidence existed.
But that is not enough.
Imagine this DevelopmentRequest:
Evidence required:

Unit tests pass
Security review completed
Metaverse integration demonstrated
And the developer submits only:
commit:abc123
Technically, evidence exists.
But the required evidence is not actually satisfied.
So the stronger model connects each requirement to a specific reference.
For example:
{
"evidence": [ { "requirement": "Unit tests pass", "reference": "ci:test-run:4821" }, { "requirement": "Security review completed", "reference": "review:security:913" }, { "requirement": "Metaverse integration demonstrated", "reference": "demo:metaverse:42" } ]
}
Then the verification rule becomes:
VERIFIED
only if
every evidenceRequired item
has corresponding evidence
Conceptually:
const missingEvidence =
requiredEvidence.filter(
requirement =>
!coveredRequirements.has(requirement)
);

if (missingEvidence.length) {
throw new Error(

`Missing required evidence: ${missingEvidence.join(", ")}`

);
}
This may look like a small implementation detail.
It is not.
It changes the meaning of VERIFIED.
Without this rule:
VERIFIED = someone attached something
With this rule:
VERIFIED = the declared evidence requirements were actually covered
That is a much stronger guarantee.
DevelopmentRequest Is Not a Bounty
Another architectural decision we intentionally made was separating development from economics.
A DevelopmentRequest can exist without any reward.
That means:
Knowledge
↓
DevelopmentRequest
↓
Implementation
↓
Verification
can operate independently.
Then, optionally:
DevelopmentRequest
↓
Bounty
↓
Reward
↓
Settlement
may be attached later.
This distinction matters.
A university research project may not use bounties.
An open-source volunteer may contribute without payment.
A company may use fixed contracts.
A decentralized community may use tokens.
A marketplace may use fiat.
The technical work object should not care.
That is why the model contains only:
bountyReference: null
as an optional link.
The economics remain a separate subsystem.
GitHub as Evidence, Not Truth
GitHub is also important in the architecture, but we do not want to make the mistake of treating GitHub itself as truth.
A commit proves that a commit exists.
It does not automatically prove:
the feature works
the requirement is satisfied
the code is secure
the architecture is correct
the scientific result is valid
So GitHub becomes one evidence source among others.
Future DevelopmentRequest verification could combine:
GitHub commit
+
CI test result
+
integration test
+
human review
+
external evidence
This is also why we are working toward a Contribution Graph.
The graph can connect:
Developer
↓
Issue
↓
DevelopmentRequest
↓
Commit
↓
Pull Request
↓
Test
↓
Review
↓
Verified Contribution
That provides a much richer representation of technical reputation.
Where the Metaverse Fits Back In
At first glance, the metaverse and DevelopmentRequest may seem unrelated.
But they are actually part of the same architecture.
Imagine a person entering MyZubster.
The environment could eventually know:
Identity
Wallet
GitHub History
Verified Contributions
Knowledge Contributions
Development Activity
Community Activity
The user does not need to see all of this as raw database records.
The metaverse can become an interface for it.
For example, someone could enter a virtual lab or development room and interact with a project.
Behind the scene:
Metaverse Project

↓

DevelopmentRequest

↓

Verified Knowledge

↓

GitHub Repository

↓

Contributors

↓

Evidence
The virtual environment therefore becomes a way to navigate a real technical graph.
What We Demonstrated Today
During the hearing, we were able to connect several of these concepts in one presentation.
We demonstrated the MyZubster metaverse directly.
We explained Nicola's real-world pilot.
We discussed his AI-related development work.
We explained how user activity can evolve into testing and software contribution.
We described the role of GitHub history.
We explained Zorgax.
We described the difference between AI conversation and verified knowledge.
We presented our university outreach and the idea that scientific pilots require scientific methodology.
And we explained the broader direction:
People perform real activities, software records evidence, AI assists the process, developers build solutions, and independent verification creates new trusted knowledge.

Universities and Scientific Validation
We also discussed the academic side of the project.
We have started conversations with several universities and research groups around areas including AI, food science, fermentation, circular economy, environmental measurement, LCA/LCSA, and water reuse.
We are intentionally keeping the wording precise.
These are exploratory discussions.
They are not formal partnerships unless and until they are formally established.
The reason universities matter is structural.
MyZubster can build:
software
traceability
data collection
knowledge infrastructure
AI assistance
development workflows
evidence systems
But scientific validation requires additional layers:
scientific protocol
experimental design
control groups
measurement methodology
ethical assessment
statistical analysis
domain expertise
An AI system should not pretend to replace those responsibilities.
LIFE 2027 as a Possible Pilot Framework
We are also exploring whether some of these ideas could eventually fit into a LIFE 2027 project.
Again, this is an exploratory direction.
There is no approved or funded MyZubster LIFE project at this stage.
The interesting part for us is the possibility of connecting environmental pilots with the same verifiable architecture.
For example:
Circular Water Pilot

↓

Sensors / Data

↓

Evidence

↓

University Protocol

↓

Verified Knowledge

↓

Zorgax

↓

DevelopmentRequest

↓

Software Improvement
The same architecture could theoretically apply to fermentation, environmental monitoring, circular economy, Living Labs, or other pilot domains.
That is one reason we are trying to keep the core infrastructure domain-neutral.
The Broader Architecture
If we compress the whole system, the current direction looks like this:

                ┌──────────────────┐
                │    Real World    │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Data / Evidence  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ MyZubster        │
                │ Knowledge Layer  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │      Zorgax      │
                │   AI Assistant   │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │DevelopmentRequest│
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │    Developer     │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ GitHub / CI      │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Evidence Review  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Verified Result  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │  New Knowledge   │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Identity/Wallet  │
                │ Metaverse Layer  │
                └──────────────────┘

This creates a feedback loop.
The output of development can become new knowledge.
That knowledge can generate new development requests.
Those development requests create more evidence.
The evidence can improve the knowledge layer.
What We Have Implemented So Far
At the technical level, the recent work includes:

a Zorgax Knowledge Layer with provenance, content hashing, versioning, visibility and evidence metadata;
explicit distinction between conversation, candidate information and verified knowledge;
fail-closed behavior for sensitive knowledge operations;
preview + digest + explicit human confirmation before persistent DevelopmentRequest creation;
snapshotting of Knowledge references using contentHash and version;
idempotent DevelopmentRequest creation;
a lifecycle covering DRAFT, OPEN, IN_PROGRESS, SUBMITTED, VERIFIED, REJECTED and CANCELLED;
contributor assignment;
submission of commit and evidence references;
independent review rules;
strict separation between DevelopmentRequest and bounty/payment systems;
integration points for future GitHub contribution tracking;
an evidence model being strengthened so every required evidence item must be satisfied before VERIFIED.
This is still evolving.
There are important areas we still want to improve, including stronger revision models, more precise evidence objects, route-level tests, better contribution graph integration, and stronger lineage across Knowledge revisions.
The Principle Behind the Architecture
The most important idea is probably this:
We are not trying to automate trust.

We are trying to make trust more inspectable.
AI can help generate code.
AI can help search.
AI can help organize knowledge.
AI can help transform requirements into development tasks.
AI can help developers.
But an AI response should not automatically become truth.
A commit should not automatically become proof.
A wallet should not automatically become reputation.
A submission should not automatically become verification.
The architecture should preserve the difference.
That is what we are trying to encode in the system itself.
What Comes Next
The next engineering steps are straightforward.
We want to finish the stronger DevelopmentRequest evidence invariant, integrate the workflow into the operational branch, and then continue toward the GitHub and Contribution Graph bridge.
After that, we want Zorgax to be able to move through a much richer development loop:
Question
↓
Verified Knowledge
↓
Architecture
↓
DevelopmentRequest
↓
Implementation
↓
Tests
↓
Independent Verification
↓
Delivery
↓
Optional Reward
↓
New Knowledge
At the same time, we will keep exploring how this architecture can work with real users, academic research, environmental pilots, and the MyZubster metaverse.
The meeting today was useful because we did not have to describe this only as an abstract roadmap.
We were able to show pieces of it working.
There is still a lot to build.
But the architecture is becoming increasingly clear.
Real people create activity. Activity creates evidence. Evidence can become verified knowledge. Knowledge can generate development. Development creates new evidence. AI assists the entire loop without becoming the sole authority.

That is the direction we are building toward with MyZubster and Zorgax.
MyZubster
Open Source • Verified Knowledge • AI-Assisted Development • GitHub Evidence • Metaverse • Digital Identity • Community

AI #OpenSource #SoftwareArchitecture #SoftwareDevelopment #GitHub #Metaverse #Web3 #KnowledgeGraph #ArtificialIntelligence #NodeJS #Developers #MyZubster #Zorgax

From a GitHub OAuth 404 to a More Reliable MyZubster Runtime

Tue, 22 Sep 2026 03:59:35 +0000

From a GitHub OAuth 404 to a More Reliable MyZubster Runtime

Sometimes a production problem starts with a very small symptom.

In our case, it was a GitHub OAuth 404.

What looked like an authentication issue eventually led us through a much broader review of MyZubster’s development and runtime environment: GitHub account migration, repository ownership, systemd, PM2, MongoDB initialization, multiple Mongoose runtimes, realtime authorization, Bitcoin payment logic, and an aging Jest test suite.

This is the story of how one error turned into a useful infrastructure cleanup.

What is MyZubster?

MyZubster is an evolving open-source ecosystem combining community participation, digital experiences, Marketplace and Seller workflows, AI assistance, experimental projects, a Metaverse interface, and open-source contribution.

Useful links:

Website: https://myzubster.com
GitHub: https://github.com/danieldirimini-myzubster/myzubster
Marketplace: https://myzubster.com/marketplace
Metaverse: https://myzubster.com/metaverse
LIFE Pilot: https://myzubster.com/life-pilot

The project is actively evolving, and part of the current work is making sure the codebase, infrastructure, runtime behavior, and tests all describe the same system.

The original problem: GitHub OAuth

The first visible issue was an unreliable GitHub authentication flow that could end in a 404.

At the same time, the previous development account had accumulated other operational limitations affecting API access, OAuth integrations, Actions, and repository workflows.

Instead of trying to keep building on top of an unstable setup, we separated two concerns:

the historical/public project identity;
the operational GitHub identity used for development.

A new GitHub account became the operational development account, while the existing MyZubster identity inside the product remained untouched.

This was important.

We were changing the development control plane, not rewriting the identity or history of the project.

Migrating Git without destroying local state

The active VPS repository is located at:

/root/myzubster
The server also contains worktrees, experimental directories, verifier code, and local files that should not be committed.
So we deliberately avoided shortcuts like:
git reset --hard
and:
git add .
Instead, we moved the canonical remote to the new GitHub repository while keeping older remotes available for reference.
The current development repository is:
https://github.com/danieldirimini-myzubster/myzubster
The active feature branch was then synchronized with the latest main without rewriting history.
That preserved the work already done while bringing in an OAuth-related fix from the main branch.
Then we found a runtime ownership problem
Once Git was stable, we inspected how MyZubster was actually running on the VPS.
We discovered that the environment used both:
systemd
PM2
That is not necessarily a problem by itself.
The real issue was that both systems appeared to have responsibility for parts of the same application.
There was a PM2 process named myzubster, while the actual HTTP gateway was being served through systemd.
Even worse, the startup paths were different.
The root server.js exported the Express application, while another process was responsible for calling .listen().
That meant we had multiple process managers around an application that did not have a single, obvious runtime owner.
The solution was to make systemd the canonical supervisor for the main gateway and remove the duplicate PM2 ownership.
PM2 remains useful for other independent services.
Production was running from an older project directory
Another subtle problem appeared in the systemd configuration.
The active repository was:
/root/myzubster
but the service still referenced an older copy:
/root/myzubster-ahp
This is a dangerous situation because you can successfully edit, test, commit, and push one repository while production continues to execute another.
We updated the systemd working directory so the code being edited and the code being executed are now aligned.
This is one of the most important lessons from this debugging session:
Never assume the repository you are editing is the repository your production process is actually running.

Check WorkingDirectory.
Check ExecStart.
Check the real process.
The homepage worked, but the Metaverse was degraded
After fixing the runtime path, the homepage returned:
HTTP 200
But the Metaverse health endpoint reported:
{
  "success": false,
  "status": "degraded",
  "transport": "unavailable",
  "mongodb": "disconnected"
}
At first this looked like a MongoDB problem.
It was not.
The credentials were correct and the root application could connect to the database.
The real problem was much more interesting.
Two Mongoose installations meant two database states
The project contains separate Node.js dependency contexts.
Conceptually:
root application
  -> Mongoose 7

backend
  -> Mongoose 8
Those are two separate JavaScript instances.
Connecting one does not connect the other.
So this:
await rootMongoose.connect(...)
does not make this true:
backendMongoose.connection.readyState === 1
The backend Metaverse code was checking its own Mongoose connection.
That connection had never been initialized by the systemd startup path.
The database itself was fine.
The application lifecycle was wrong.
Fixing the bootstrap sequence
The backend already had proper database initialization logic.
The missing piece was making sure production actually called it.
We created a dedicated systemd entrypoint that does this in the correct order:
load application
      ↓
connect backend MongoDB
      ↓
start HTTP server
In simplified Node.js:
const app = require('../server');
const backend = require('../backend/src');

async function main() {
  await backend.connectDatabase();

  const server = app.listen(5003, '127.0.0.1', () => {
    console.log('MyZubster Gateway ready');
  });

  process.on('SIGTERM', async () => {
    server.close(async () => {
      await backend.disconnectDatabase();
      process.exit(0);
    });
  });
}

main();
After restarting systemd, the Metaverse health endpoint changed to:
{
  "success": true,
  "status": "healthy",
  "transport": "shared-polling",
  "mongodb": "connected"
}
That was a major milestone.
We did not “solve” Mongoose by deleting dependencies
A tempting response would have been to force both parts of the project to use one Mongoose installation immediately.
We deliberately did not do that.
The immediate problem was not the existence of two Mongoose versions.
The problem was that only one connection lifecycle was being initialized.
This distinction matters.
A structural refactor may still make sense in the future, but production incidents are not the right time to perform unnecessary dependency surgery.
Fix the real failure first.
Then the tests started teaching us about the architecture
The feature-specific tests were healthy.
For the MYZ-188 development work, we had:
7 test suites passed
37 tests passed
But the complete repository test suite still contained failures.
Instead of assuming the new branch had broken everything, we checked whether several failures also existed on main.
Many did.
That gave us a useful distinction:
new regression
versus:
existing technical debt
This saved us from “fixing” unrelated code based only on the fact that Jest was red.
A red test does not always mean production is wrong
One example involved the monthly AI budget.
A test expected a budget key like:
openai:gpt-5.6-sol:2026-09
while production used:
openai:all:2026-09
At first glance, changing the production key would make the test pass.
But when we reviewed the architecture, the global key was clearly intentional.
The monthly budget covers the whole OpenAI/Astra usage, and the system may fall back between different OpenAI models.
Using model-specific budget keys could allow separate models to consume separate caps.
So the production behavior was correct.
The test was stale.
We updated the test.
That is an important rule:
Tests are executable documentation, but executable documentation can become outdated too.

Realtime authorization: fail closed
Another test was hanging for five seconds.
The relevant code queried community membership through MongoDB.
When the database authority was unavailable, Mongoose buffered the query until Jest timed out.
The correct behavior for authorization was not to wait.
It was to deny.
We changed the flow to check database availability first:
if (mongoose.connection.readyState !== 1) {
  return {
    allowed: false,
    reason: 'community_membership_authority_unavailable'
  };
}
The behavior changed from:
database unavailable
    ↓
wait
    ↓
timeout
to:
database unavailable
    ↓
deny immediately
That is both faster and safer.
Then we found a real Bitcoin bug
The full suite exposed another issue:
TypeError:
Cannot read properties of undefined (reading 'includes')
The failing code was checking:
SUPPORTED_ASSETS.includes(asset)
But SUPPORTED_ASSETS itself was undefined.
The reason was a CommonJS circular dependency.
The dependency graph looked approximately like this:
Legacy Monetization Service
          ↓
Unified Checkout Service
          ↓
Quote / Chain Verifier
          ↓
Legacy Monetization Service
During module initialization, Node.js returned an incomplete export.
The result:
SUPPORTED_ASSETS === undefined
Breaking the circular dependency
We did not add a defensive fallback like:
SUPPORTED_ASSETS || []
That would hide the design problem.
Instead, we extracted the constant into a leaf module:
'use strict';

const SUPPORTED_ASSETS = Object.freeze(['BTC']);

module.exports = {
  SUPPORTED_ASSETS
};
Now the payment services depend on a small module that depends on nothing else.
The Bitcoin production tests moved from:
3 failed
2 passed
to:
5 passed
The tests cover:
- BTC availability;
- BTC/EUR quoting;
- satoshi conversion;
- Esplora verification;
- unconfirmed-payment fail-closed behavior.
Legacy tests were still mocking an older architecture
The next group of failures was especially interesting.
Several tests still mocked:
ZorgaxPaymentIntent
ZorgaxSubscription
But the current production architecture uses:
PaymentIntent
ZorgaxPurchase
Entitlement
That means the Jest mocks looked correct, but they were intercepting classes the application no longer used.
The real Mongoose models were executing instead.
Then Jest waited for the real database.
Five seconds later:
Exceeded timeout of 5000 ms
The problem was not a slow application.
It was a stale test boundary.
Test runtime: 11 seconds to less than one
One replay-protection test originally took around:
11 seconds
and failed with two timeouts.
After updating the test to mock the real architecture:
2 tests passed
in roughly:
0.7 seconds
That is a strong indicator that the previous problem was accidental external I/O.
The new replay protection verifies something closer to the real current contract:
same payment reference
        ↓
existing purchase?
        ↓
same owner?
   ┌────┴────┐
  yes        no
   ↓          ↓
 reuse      reject
Only after ownership is validated does the system grant the entitlement.
What we are doing now
The main runtime is now much healthier.
We have already completed:
- migration to the new operational GitHub account;
- repository remote cleanup;
- branch synchronization with main;
- OAuth regression verification;
- systemd runtime cleanup;
- duplicate PM2 gateway removal;
- backend MongoDB bootstrap;
- Metaverse health recovery;
- graceful backend database shutdown;
- Zorgax access compatibility cleanup;
- AI budget test alignment;
- realtime fail-closed authorization;
- Bitcoin circular-dependency removal;
- modernization of several outdated payment tests.
The current focus is the remaining legacy test suite.
Some tests still represent old implementation details instead of the current architecture.
So we are going through them carefully and asking:
Is this a production bug, or is the test describing a system that no longer exists?

That is the work happening right now.
The bigger architectural goal
The cleanup is gradually making the boundaries clearer:
systemd
  -> explicit gateway bootstrap

gateway bootstrap
  -> explicit database lifecycle

realtime authorization
  -> explicit availability checks

payments
  -> unified checkout boundary

payment constants
  -> dependency-free leaf module

access
  -> entitlement authority

tests
  -> mock current production boundaries
The goal is not merely to get a green test suite.
The goal is to have a green test suite that means something.
Small commits are helping a lot
We are keeping fixes isolated.
Examples include:
fix(runtime): initialize backend Mongo before gateway listen

fix(zorgax): include optional legacy subscription access source

test(zorgax): align AI budget expectation with global monthly cap

fix(realtime): fail closed when community membership authority is unavailable

fix(zorgax): break payment asset circular dependency
Small commits give us three advantages:
- easier review;
- easier rollback;
- easier reasoning.
Git becomes part of the debugging process, not just version storage.
What we deliberately did not do
Some shortcuts would have made the situation worse.
We did not:
reset the repository destructively
delete worktrees blindly
force-de-duplicate Mongoose during an incident
increase Jest timeouts to hide MongoDB access
hide circular dependencies with fallback values
commit credentials or environment secrets
A large part of production engineering is not just knowing what command to run.
It is knowing which commands not to run.
Current simplified architecture
The current direction looks like this:
GitHub
   ↓
danieldirimini-myzubster/myzubster
   ↓
VPS /root/myzubster
   ↓
systemd
   ↓
MyZubster Gateway
   ├── Root application
   ├── Backend Mongo context
   ├── Metaverse
   ├── Realtime
   ├── Zorgax
   └── Payment services
Other independent services can still use PM2 where appropriate.
The important improvement is that there is now a much clearer owner for each runtime responsibility.
What comes next
The immediate plan is:
1. finish updating the remaining legacy payment tests;
2. review source-inspection tests that still point to compatibility wrappers;
3. run the complete Jest suite again;
4. separate real regressions from intentionally changed contracts;
5. verify production health;
6. prepare the branch for review and merge into main.
The goal is simple:
align the repository, runtime, architecture, and tests before merging.

Final lesson
This entire debugging session started with:
GitHub OAuth 404
and evolved into:
GitHub migration
      ↓
runtime cleanup
      ↓
systemd stabilization
      ↓
MongoDB lifecycle fix
      ↓
Metaverse recovery
      ↓
authorization hardening
      ↓
Bitcoin dependency cleanup
      ↓
legacy test modernization
That is often how real engineering works.
The first visible error is not always the real problem.
Sometimes it is simply the first place where the system tells you to look deeper.
We are continuing that work now on MyZubster.
Project:
https://myzubster.com
GitHub:
https://github.com/danieldirimini-myzubster/myzubster
Marketplace:
https://myzubster.com/marketplace
Metaverse:
https://myzubster.com/metaverse
LIFE Pilot:
https://myzubster.com/life-pilot
The next milestone is to finish the legacy test alignment, validate the entire branch, and prepare it for merge into main.
One boundary at a time.

We Turned a Real Knowledge Transfer Into Verifiable Evidence on Base Sepolia

Sat, 19 Sep 2026 02:18:27 +0000

We Turned a Real Knowledge Transfer Into Verifiable Evidence on Base Sepolia

Today we completed an experiment inside MyZubster that connects real human collaboration, GitHub history, cryptographic commitments, and blockchain verification.

The goal was not to “put knowledge on blockchain.”

The goal was more precise:

Can we take a real technical collaboration, freeze the resulting public work into a canonical record, hash it deterministically, anchor that commitment on-chain, and verify it independently later?

We used the ongoing Nicola / N4K48 MyZubster pilot as the real case.

The result is now public and reproducible.

The real source of evidence: GitHub

Nicola’s public MVP is here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp

Live pilot:

https://myzubster-mvp.onrender.com/

During the September 18 collaboration, the repository advanced across:

economic provenance;
persistent ledger storage;
revenue and asset APIs;
derived balances;
source-specific revenue breakdown;
UTC timestamps;
asset/revenue history;
MYZ ledger UI;
public documentation;
revenue simulation.

Instead of describing that work loosely, we identified an exact Git history window:

Base commit:
8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47

Head commit:
b9ac4e8801d65b84ef882baf78fa09ce5b6b5059

That snapshot contains 30 commits.

This gives us a concrete technical object to reference.

We introduced a knowledge-transfer manifest

We created a new schema:

myzubster.knowledge-transfer.v1

with transfer ID:

KNOWLEDGE-N4K48-2026-09-18-001

The manifest records:

source identity;
recipient identity;
repository;
base commit;
head commit;
changed files;
knowledge scope;
blockchain target;
evidence boundaries.

The important design choice is that we separate:

source assertion
from
recipient attestation

At anchor time, Nicola’s recipient attestation was still:

PENDING

That is intentional.

A blockchain transaction should never be interpreted as automatic consent from another human.

Deterministic hashing

The manifest is canonicalized by:

recursively sorting object keys;
preserving array order;
serializing compact JSON;
UTF-8 encoding;
calculating SHA-256.

The resulting hash is:

39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

The blockchain payload is:

MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

This is the core architecture:

large public evidence set

↓

canonical manifest

↓

SHA-256

↓

small on-chain commitment

We do not need to put source code, documentation, personal data, or full knowledge content directly on-chain.

Anchoring on Base Sepolia

For the pilot we used:

Network: Base Sepolia
Chain ID: 84532
Value: 0 ETH

The transaction was confirmed:

0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

Block:

47000958

Confirmed at:

2026-09-18T22:23:24.000Z

Explorer:

https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

A real integration bug: MetaMask rejected self-targeted calldata

Our first implementation tried to submit:

from: wallet
to: same wallet
value: 0
data: commitment

MetaMask rejected it with:

External transactions to internal accounts cannot include data

So we changed the design to use a fixed zero-value evidence sink:

0x000000000000000000000000000000000000dEaD

No ETH is transferred.

Only the commitment is carried in calldata.

Then smart accounts changed the transaction shape

After the transaction confirmed, the first version of our verifier reported:

MISMATCH

At first glance that looked wrong.

The receipt was successful.

The chain was correct.

The value was zero.

But the transaction destination and top-level calldata were not what our verifier expected.

The reason: MetaMask submitted the request through a delegated smart-account transaction.

The top-level transaction was type 4 and the anchor execution was wrapped inside:

redeemDelegations(...)

This forced us to improve the verifier.

Instead of only checking:

tx.to === evidenceSink
tx.data === expectedPayload

we added delegated execution decoding.

The verifier now inspects the nested execution and validates:

target
value
calldata
execution mode

Inside the delegated call we found:

Target:
0x000000000000000000000000000000000000dEaD

Value:
0

Payload:
MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

The result became:

MATCH

This was one of the most useful parts of the pilot.

A synthetic demo probably would not have exposed this distinction between a normal EOA transaction and a delegated smart-account execution.

Public verifier

We deployed a public verifier endpoint:

https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

It checks:

chainId ✅
receipt success ✅
top-level value = 0 ✅
delegated call recognized ✅
nested target match ✅
nested value = 0 ✅
exact calldata match ✅
execution mode match ✅

Current status:

{
"success": true,
"status": "MATCH"
}

Human-readable page:

https://www.myzubster.com/knowledge-anchor-n4k48

What exactly is proven?

This is where engineering language matters.

The blockchain anchor proves evidence about:

existence
integrity
timestamp

for the exact canonical manifest.

It does not prove:

authorship of every idea
learning
understanding
scientific validity
legal ownership
commercial value
truth of every human claim

This distinction is fundamental.

Blockchain is useful here as a tamper-evident timestamp and integrity layer, not as a replacement for human verification, peer review, contracts, or scientific validation.

The final human layer

The next step belongs to Nicola.

He now needs to add a separate attestation from his own GitHub account confirming that the record actually represents knowledge, guidance, and collaboration he received and used.

We intentionally do not modify the original anchored manifest, because that would change its hash.

Instead, Nicola can create something like:

knowledge/N4K48-ATTESTATION-KNOWLEDGE-2026-09-18.md

and commit a statement acknowledging:

KNOWLEDGE-N4K48-2026-09-18-001

and its anchored hash.

This creates a stronger chain:

source assertion

↓

public development evidence

↓

canonical hash

↓

blockchain anchor

↓

independent verifier

↓

recipient acknowledgement
Why we think this architecture matters

A lot of blockchain systems start from the wrong question:

“What can we put on-chain?”

A better question is:

“What evidence should stay off-chain, and what minimal commitment should be anchored on-chain?”

For MyZubster, this leads to a cleaner architecture:

GitHub → evidence history
SHA-256 → integrity
Base Sepolia → timestamp anchor
Human attestation → consent / acknowledgement
Research review → validation
MYZ ledger → internal accounting

Each layer does one job.

That separation avoids a lot of semantic confusion.

Knowledge is not the token

Another design principle we are keeping explicit:

knowledge ≠ blockchain asset
MYZ ≠ crypto token
GitHub commit ≠ legal ownership
blockchain timestamp ≠ scientific proof

MYZ remains an internal MyZubster accounting unit.

The knowledge anchor is a separate evidence mechanism.

The two may interact later through explicit business rules, but they should never be silently merged into one concept.

Public references

Nicola / N4K48 repository:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp

Live pilot:

https://myzubster-mvp.onrender.com/

MyZubster verification page:

https://www.myzubster.com/knowledge-anchor-n4k48

Verifier endpoint:

https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

BaseScan:

https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

MyZubster Core:

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

What we learned

The biggest lesson was not about hashes or blockchains.

It was about evidence boundaries.

Real systems need to distinguish:

recorded
from
verified

verified
from
validated

validated
from
owned

owned
from
understood

Once those boundaries are explicit, blockchain becomes much more useful.

Not as a magical source of truth.

But as one precise component in a larger evidence architecture.

GitHub Copilot vs Cursor vs Claude Code

Fri, 18 Sep 2026 17:28:31 +0000

These three get lumped together as "AI coding tools," but they're solving genuinely different problems in your workflow, inline completion, full-editor AI integration, and autonomous multi-file agentic work. Here's how they actually differ, and which combination makes sense depending on what you're building.

GitHub Copilot: the widest net

Copilot's real advantage isn't raw capability, it's reach. Native support across VS Code, JetBrains, Neovim, Visual Studio, and Xcode makes it the easiest entry point regardless of what editor your team already uses, and it holds the largest market share of any tool in this category. The free tier (around 2,000 completions a month) makes it close to a no-brainer starting point, especially for teams already living inside the GitHub ecosystem for issues, PRs, and CI.

Where it's the clear pick: you want inline, low-friction autocomplete everywhere you already work, without changing editors or workflow.

Cursor: AI woven into the entire editor, not just autocomplete

Cursor is a fork of VS Code with AI integrated at every layer, not bolted on as a plugin. Its Composer interface handles complex multi-file refactors directly inside the editor, and it's become the most commercially successful tool in this category by a wide margin, reportedly over a million users and reviewers reporting meaningfully fewer PR review comments after adopting it. For developers who live in their editor all day, having AI that understands the whole open project (not just the current file) is a genuinely different experience from inline suggestions.

Where it's the clear pick: you want AI-assisted editing as your default way of working, not an occasional autocomplete assist.

Claude Code: the one for autonomous, repo-wide work

Claude Code operates more like an agent than an editor plugin, it reads files, runs commands, manages git, executes tests, and edits across multiple files in your actual local environment, currently leading autonomous coding benchmarks (around 80% on SWE-bench Verified). This is the tool for handing off a genuinely complex, multi-step task and getting back a coherent, well-reasoned result, not for inline suggestions while you type.

Where it's the clear pick: large refactors, unfamiliar codebases you need to understand quickly, or any task better described as "do this whole thing" rather than "suggest the next few lines."

What most working developers actually do

The realistic setup isn't picking one, it's layering them by task size. A common, cost-effective combination is Copilot for everyday autocomplete plus Claude Code for the occasional complex refactor or architecture task. A more editor-centric setup swaps in Cursor as the daily driver, with Claude Code still handling anything that spans the whole codebase.

How to actually choose

Don't start from "which is best", start from where your current friction actually is. If you're constantly context-switching between editors, Copilot's reach solves that. If your bottleneck is slow, disjointed multi-file edits, Cursor's integrated approach solves that. If you're regularly facing tasks too large or unfamiliar to comfortably do by hand, Claude Code's autonomous, repo-aware approach is the one built for exactly that job.

My Django Secret Key Was Public on GitHub - How I Fixed It

Fri, 18 Sep 2026 10:07:50 +0000

We all make mistakes, especially when starting out. Recently, the ultimate developer mishap happened to me: I accidentally pushed my Django SECRET_KEY to a public GitHub repository.

In Django, the SECRET_KEY is used for cryptographic signing, like session cookies or password reset tokens. It is essential for protecting sensitive data and preventing tampering or unauthorized access. Leaving it publicly exposed is a massive NO-GO.

But that is exactly what learning projects are for! Luckily this happened to a project with no real user data. We learn the most from our mistakes, and I now know exactly how to handle this situation. Here is how to fix it:

Step 1: Invalidate the old key immediately

Simply changing the key in your code and pushing it again is not enough. The old key remains visible forever in your GitHub commit history. The first step is damage control, so we need to generate a new key. Start the Python shell in your project terminal:

python manage.py shell

Then enter the following lines:

from django.core.management.utils import get_random_secret_key
print(get_random_secret_key())

The first line imports the required utility function and the second line generates the new key and prints it to the terminal so you can copy it.

*UPDATE (September 21st 2026): Based on reader feedback and GitHub's official security guidance, I’ve updated this section. Rotating the secret key is the single most critical step. Purging your Git history with tools like git-filter-repo is a helpful next step to tidy up, but it does not guarantee absolute security, as old commits can still persist in forks or cached views on GitHub's servers.*

Step 2: Move the Secret Key to environment variables

To make sure this never happens again, I moved the key into a .env file. Create this file in your root directory and make sure to add it to your .gitignore file so it never gets tracked by GitHub.

To load the environment variables from the .env file into the Django project, we use the python-dotenv library. Install it first:

pip install python-dotenv

Next update your settings.py file like this:

import os
from dotenv import load_dotenv

load_dotenv()

SECRET_KEY = os.getenv("SECRET_KEY")

Finally store your actual key inside the .env file:

SECRET_KEY="your_new_secret_key_here"

Conclusion: Mistakes happen, it's how you handle them that matters

Thanks to this faux pas my Django project is now secure and follows configuration management best practices. My brain has permanently saved this lesson so it won't happen again! 😊

# MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metave

Fri, 18 Sep 2026 10:04:10 +0000

MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metaverse → NFTs

Over the last few months, MyZubster has changed significantly.

What started as an open-source ecosystem of experiments is beginning to converge around a much simpler entry point:

Authentication → Zorgax → Profile → GitHub → Interactions → Metaverse → Digital Assets

The interesting part isn't any single technology in that chain.

It's what happens when they share the same identity and evidence layer.

Authentication Is the Starting Point

When someone authenticates with MyZubster, we don't want the result to be just another empty account.

Authentication should become the beginning of a persistent ecosystem identity.

From there, the user can progressively connect:

a MyZubster profile;
interests and skills;
projects;
GitHub activity;
Marketplace activity;
knowledge and experiments;
Metaverse identity;
and, eventually, qualifying digital assets or NFTs.

This distinction matters:

Authentication proves access to an account.

It does not automatically prove every claim that appears in a profile.

Zorgax Helps Build the Profile

This is where Zorgax becomes useful.

Instead of presenting a new user with a huge registration form, Zorgax can help progressively construct the profile.

The conversation can start with simple questions:

Who are you?

What are you building?

What do you know?

What would you like to learn?

What can you contribute?

The architecture becomes:

USER → AUTH → ZORGAX → PROFILE

Zorgax can help organize the information, improve descriptions, identify missing information and connect the user to relevant parts of MyZubster.

But the human remains the source of the identity.

That's why we keep an important boundary:

HUMAN WORK ≠ AI ASSISTANCE ≠ VERIFIED EVIDENCE

Then GitHub Makes the Profile Inspectable

For developers and open-source participants, GitHub adds another dimension.

A person can move from saying:

I build software.

to linking actual public work:

PROFILE → REPOSITORY → ISSUE → COMMIT → PULL REQUEST → PROJECT

This is important for MyZubster because we don't want Zorgax to simply generate impressive biographies.

Where evidence exists, the profile should be able to point to it.

GitHub becomes part of the interaction graph.

MYZUBSTER IDENTITY ↔ GITHUB WORK ↔ ZORGAX

A project can then become discoverable through the person's profile and potentially through other MyZubster experiences.

The Same Identity Can Enter the Metaverse

Now things become more interesting.

The MyZubster identity doesn't have to stop at a web profile.

It can also represent the person inside the MyZubster Metaverse.

Imagine entering a digital space and meeting another avatar.

That avatar could connect back to:

PERSON
↓
MYZUBSTER PROFILE
↓
PROJECTS
↓
GITHUB
↓
KNOWLEDGE
↓
DOCUMENTED ACTIVITY

The Metaverse then stops being only a graphical chat environment.

It becomes another interface for discovering people, projects, communities and interactions.

GitHub + Metaverse Creates a New Kind of Interaction

This is one of the directions we're interested in exploring.

A developer contributes to an open-source project.

The contribution exists on GitHub.

The MyZubster profile references that work.

The same identity enters the Metaverse.

Other participants can discover the project.

That can lead to another contribution, collaboration, mission or community interaction.

The loop becomes:

GITHUB
↓
MYZUBSTER PROFILE
↓
METAVERSE
↓
HUMAN INTERACTION
↓
NEW PROJECT / CONTRIBUTION
↓
GITHUB

Now GitHub isn't isolated from the social environment around the project.

Where NFTs Become Interesting

This also changes how we think about NFTs.

Instead of starting with:

MINT NFT → TRY TO CREATE UTILITY

we can explore the opposite direction:

PARTICIPATE
↓
BUILD
↓
INTERACT
↓
DOCUMENT
↓
VERIFY WHEN POSSIBLE
↓
QUALIFY
↓
OPTIONAL NFT / DIGITAL ASSET

In that model, the NFT isn't necessarily the product.

It can become a digital artifact produced by an interaction.

For example, future assets could reference:

an open-source contribution;
a Metaverse event;
a creator collectible;
a completed mission;
a community artifact;
a documented project milestone;
or another qualifying MyZubster interaction.

That creates a potential distribution network for digital assets.

MyZubster Becomes the Connector

The architecture we're moving toward can be represented like this:

PERSON
↓
AUTHENTICATION
↓
MYZUBSTER IDENTITY
↓
ZORGAX
↓
PROFILE
↓
GITHUB + PROJECTS + KNOWLEDGE + MARKETPLACE
↓
INTERACTIONS
↓
EVIDENCE
↓
METAVERSE
↓
OPTIONAL NFT / DIGITAL ASSET

And then it loops.

A GitHub repository can bring somebody into MyZubster.

A MyZubster profile can bring somebody into the Metaverse.

A Metaverse interaction can create a new collaboration.

That collaboration can produce GitHub activity.

And a qualifying interaction could eventually generate a collectible or another digital asset.

The Important Part: Don't Confuse Identity With Evidence

Connecting all these systems also creates an obvious risk.

If we're not careful, a profile could appear to prove things that it doesn't actually prove.

So we're keeping these concepts separate:

IDENTITY ≠ CLAIM ≠ ACTIVITY ≠ EVIDENCE ≠ VERIFICATION ≠ NFT

Authentication doesn't prove expertise.

A GitHub account doesn't automatically prove that somebody authored everything connected to it.

Zorgax-generated text doesn't prove a claim.

A Metaverse interaction doesn't automatically prove a physical-world event.

And an NFT doesn't magically make its metadata true.

The architecture becomes more useful when those boundaries remain explicit.

What MyZubster Is Becoming

I used to think mostly about what features MyZubster should contain.

Now the more interesting question is:

What happens when identity, AI assistance, open-source work, digital interaction and verifiable artifacts become connected?

That's the direction we're exploring.

AUTHENTICATE
↓
MEET ZORGAX
↓
BUILD YOUR PROFILE
↓
CONNECT YOUR WORK
↓
ENTER THE METAVERSE
↓
INTERACT
↓
CREATE
↓
DOCUMENT
↓
DISTRIBUTE

MyZubster is gradually becoming less like a collection of separate applications and more like an identity and interaction layer connecting people, Zorgax, GitHub, the Metaverse and future digital assets.

And that's the next experiment we're building in public.

Build → Connect → Interact → Document → Verify → Distribute → Repeat

MyZubster #Zorgax #OpenSource #GitHub #Metaverse #NFT #DigitalIdentity #AIAgents #BuildInPublic

HYCU Found 30+ Ways to Destroy a Git Repo. Five Only Exist Because of AI Agents.

Thu, 17 Sep 2026 20:33:52 +0000

Backup vendors built their entire industry around two ways a company loses data: ransomware attacking from outside, and a person making a mistake from inside. At an IT Press Tour stop in Lake Bled and Ljubljana this month, HYCU argued a third cause has moved in without an invitation — an agent that already holds valid credentials and can act faster than anyone reviewing its work.

Amarnath Rampratap, HYCU's Senior Director of R-Cloud and Head of R&D India, breaks agent-driven data loss into three patterns: drift, where an agent acts on a wrong picture of a system's state; misinstruction, where a hidden or injected prompt redirects it toward destruction; and standing credentials, tokens with more reach and longer life than the task ever needed. Asked which one shows up most in the incidents that reach HYCU, Rampratap didn't hedge. "Standing credentials, because it enables the other two," he said. "Nearly every incident that reaches us has an over-scoped, long-lived token in the chain."

The PocketOS incident is the clearest public example. In April, a Cursor agent doing a routine staging task hit a credential mismatch and looked for a way around it. It found a Railway CLI token issued for managing custom domains — except that token carried authority across Railway's entire API, deletion included. The agent assumed the staging volume it was about to delete was scoped to staging. It wasn't. Railway stores volume-level backups inside the same volume they protect, so one API call took the data and every copy with it. Nine seconds, start to finish. The last backup anyone could actually recover was three months old. Rampratap counts three permissions that token should never have had: authority to delete storage from a domain-management credential, no separation between staging and production, and backups reachable by the same identity that could reach production in the first place.

The Amazon Q for VS Code incident, which shipped a destructive prompt to an extension with 964,000 installs, traces back the same way. AWS attributed it to an inappropriately scoped GitHub token sitting in the extension's CodeBuild configuration. "It is a standing-credentials story before it is an AI story," Rampratap said. What actually stopped the wipe was a syntax error in the injected instructions, not a safeguard. His read on both incidents: assume one of these eventually runs to completion, and make sure the copy it can't reach exists, is immutable, and is current.

That assumption changes the math on how long a company has to notice a problem. Native retention windows were sized for one person undoing one mistake — 93 days on SharePoint, 60 on Jira, 15 on Salesforce. Rampratap breaks the failure into three parts. Volume: an agent loop touching 50 records a minute produces 72,000 changes a day, enough to exhaust a recycle bin's capacity before the window closes. Kind: bins only catch deletes — overwrites, history rewrites, and permission changes leave nothing behind, and an API-level hard delete can skip the bin entirely. Time: HYCU's research puts the average SaaS incident at five days of disruption, longer than most bins hold anything. An agent can burn through the undo button before anyone knows there was one.

Developers will recognize the git-specific version of this problem fastest. HYCU has catalogued more than 30 ways repository data gets deleted, corrupted, or altered — and Rampratap is upfront that agents didn't invent most of them. "Mechanically, almost all classic," he said. They still arrive as a force-push, a branch delete, a history rewrite, or a misused token, which is exactly why GitHub or GitLab can't tell an agent's action from a person's. Five patterns exist only because agents do: a cleanup agent deleting branches that looked stale, a refactor agent force-pushing after a bad rebase, a migration agent rewriting history across a dozen repos at once, a compromised agent token, and a CI job running a destructive command an agent generated. "Five sounds small," Rampratap said, "until you notice they run at night, at scale, unwatched."

That's the uncomfortable core of the problem: a correct force-push and a catastrophic one are identical at the API level. Rampratap doesn't claim HYCU can tell them apart in the moment, and says the platform can't either. What changes is whether the question is answerable afterward. Every HYCU backup sits outside the protected platform's credential reach, so the difference between two points in time becomes a full record of what changed, when, and under which identity — a feature HYCU calls flight recorder inside its aiR product, run against a specific agent across every application it protects. A human still makes the final call, but with evidence instead of a guess, and granular recovery can undo the damage without undoing the legitimate work sitting next to it.

The same logic is behind HYCU's move to add Azure DevOps, now generally available, alongside its existing GitHub, GitLab, and Bitbucket coverage. "Repositories are the easy part," HYCU Chief Product Officer Anant Chintamaneni said in the announcement. "The real risk lives in the pipeline definitions, the process templates, the wiki that's a Git repo with a service layer bolted on top." Rampratap frames the timing as customer-driven — gaps in native recovery options and the dependencies between components — and points out that Azure DevOps is the backbone in exactly the regulated industries where Europe's DORA and NIS2 rules are forcing the question of independent, immutable copies from a preference into a requirement. Coldago Research analyst Philippe Nicolas made the same distinction: "Competitors built for the artifact. HYCU built for the system."

None of this argues for smarter agents or better prompts. It argues for treating every credential an agent holds as an asset to audit on its own, the same way a security team already audits a person's access. The agent that deleted PocketOS's database wasn't malicious, hallucinating, or even wrong about what it was told to do. It just had a token that could reach further than anyone realized until it did.

MyZubster: Building a Provenance Network for Knowledge, Skills, and Real-World Exchange

Thu, 17 Sep 2026 04:40:03 +0000

MyZubster: Building a Provenance Network for Knowledge, Skills, and Real-World Exchange

We started MyZubster with a simple real-world question:

What happens if I give someone my kefir culture, they reproduce it at home, document what they learn, and eventually pass both the culture and the knowledge to someone else?

That small experiment is evolving into something much larger.

We're building MyZubster as an open-source system for representing how resources, knowledge, and skills move between people while preserving provenance and uncertainty.

The core loop is simple:

Share → Try → Observe → Improve → Share again
From a kefir culture to a provenance graph

Milk kefir is our first real-world prototype.

Instead of storing only:

Daniel gave kefir to Nicola

we want the system to represent the actual lifecycle:

Daniel's culture → Marketplace listing → Nicola accepts → Hand exchange → Nicola confirms receipt → Nicola maintains his culture → Observations → Future donation

Every transition is a separate event.

If something hasn't happened yet, the system shouldn't pretend it has.

If a quantity, temperature, timestamp, outcome, or condition wasn't recorded, it stays:

UNKNOWN

This principle has become one of the foundations of the MyZubster Knowledge Protocol.
Knowledge is another transferable resource

Then we realized the same model can describe learning.

Daniel has been helping Nicola work with GitHub, Docker, and the MyZubster ecosystem.

That creates another graph:

Daniel → Nicola learns → Nicola attempts → Observable artifact → Nicola can teach another person

But there is an important rule:

Evidence is not inherited.

If Nicola teaches another participant, that participant must create their own evidence.

So the graph becomes:

Daniel → Nicola → Person B → Person C

while every edge has independent provenance.
From fermentation to a general knowledge network

The repository has now expanded beyond fermentation.

Current and newly introduced domains include:

KF- — Fermentation
SND- — Sound systems
DEV- — Programming
UNI- — University/research
PET- — Animals
PERM- — Permaculture
MUS- — Music
ART- — Art
SPT- — Sport
MA- — Martial arts

This allows very different communities to use the same underlying protocol.

A tekno musician could teach someone how to operate or assemble part of a sound system.

A musician could teach another person DJing, production, rhythm, or an instrument.

An artist could teach drawing or comics.

A calisthenics practitioner could document teaching a particular progression.

A Thai-boxing practitioner or coach could document a bounded training session.

The domain changes.

The provenance model doesn't.
Turning skills into marketplace objects

We're now extending the MyZubster marketplace concept so that an offer doesn't necessarily represent a physical object.

It could represent:

a resource, a lesson, mentoring, a workshop, a demonstration, or a collaboration request.

A skill exchange can therefore follow:

Teacher → Skill Listing → Learner Accepts → Session → Participation Confirmation → Attempt → Evidence → MyZubster Record

And eventually:

A teaches B → B reproduces → B teaches C → C reproduces

This creates a distributed graph of practical knowledge.
Physical and knowledge graphs can intersect

The interesting part is that MyZubster can maintain two separate graphs.

A physical-resource graph:

Daniel → Kefir → Nicola → New culture → Future recipient

And a knowledge graph:

Daniel → Nicola → Reproduced skill → New learner

They can reference each other without becoming the same thing.

Receiving kefir doesn't prove that someone knows how to maintain it.

Reading a Knowledge Card doesn't prove that someone performed the procedure.

Teaching a skill doesn't prove that the learner mastered it.

Each statement needs its own evidence.
Where blockchain fits

Blockchain is intended as an optional provenance layer.

We're deliberately avoiding the shortcut:

blockchain = truth

It doesn't.

An on-chain record can establish that a particular commitment or declaration was recorded.

For MyZubster, we therefore distinguish states such as:

RECORDED

from:

ONCHAIN_RECORDED

The latter should only exist when we have an actual network and verifiable transaction/record identifier.

A transaction hash doesn't automatically prove competence, lesson quality, physical delivery, professional qualifications, or the truth of every statement committed to it.

Those remain evidence problems.
Evidence states

MyZubster currently works with a deliberately small evidence vocabulary:

PERSONAL_PRACTICE
TRADITIONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
VERIFIED_GUIDANCE

And there is another important constraint:

More observations do not automatically produce VERIFIED_GUIDANCE.

Verification requires an explicit review step.

That prevents a community voting mechanism or simple repetition counter from silently transforming popular claims into verified knowledge.
The implementation

This isn't only a concept document.

The repository already contains tooling for:

canonical Knowledge Cards;

domain validation;

evidence records;

claims and sources;

knowledge relations;

reproductions;

knowledge versions;

collaboration requests;

verification reviews;

integrity checking;

graph persistence;

transactional record/graph updates;

recovery logic;

a read-only Knowledge API;

a browser-based Knowledge Explorer.

We've also started creating real cross-domain records.

For example:

DEV-001 — Nicola's observable MyZubster/Docker/comics project artifacts

DEV-002 — Nicola's reported learning/onboarding path

ART-001 — Daniel's comics practice

SPT-001 — Daniel's calisthenics practice

MA-001 — Daniel's Thai-boxing practice

For claims where supporting evidence hasn't yet been attached, the system explicitly preserves that limitation rather than manufacturing provenance.
Current development status

Our last confirmed complete local run was:

110 tests / 110 passing

That result predates the newest domain and Knowledge Card additions, so we're not claiming those latest changes as tested until the next complete run.

That's another principle we're trying to follow throughout the project:

don't convert an expected result into an observed result.

The public Knowledge Explorer is available here:

MyZubster Knowledge Explorer

The source code and current protocol development are here:

MyZubster on GitHub

At the moment, GitHub contains newer work than the production Knowledge Explorer deployment, so the repository is the source of truth for the latest development.
What's next

The next major step is moving the new Skill Marketplace model from protocol documentation into structured schemas and runtime records.

The target lifecycle is:

Listing → Acceptance → Session/Exchange → Evidence → Knowledge Graph → Optional on-chain commitment

After that, we can start testing the protocol with more real people and very different types of knowledge.

Kefir is just the first physical experiment.

The broader question behind MyZubster is:

Can we build an open provenance graph showing not just what people say they know, but how knowledge and resources actually move, get reproduced, change, and get passed to the next person?

That's what we're trying to find out.

Agent traffic does not grow like human traffic

Fri, 11 Sep 2026 14:36:32 +0000

GitHub published its August availability report this week, and one sentence in it is worth more than the rest of the document: "our shared infrastructure services have not kept up with our month-over-month actions growth and peak load."

Five incidents in a month. The worst, on August 17, peaked at a 56% front-door request failure rate and touched more than 29,000 organizations, with roughly 4.8 million requests failing or crawling. On August 26, more than 20% of Actions run starts failed or were delayed, and that is the one GitHub attributes directly to growth outpacing shared services.

I want to be careful here, because it would be easy to read this as a GitHub problem. I do not think it is. I think it is the first large public example of a capacity model meeting a class of traffic it was never built to forecast.

Human traffic has a denominator

For most of my career, capacity planning had a number I could point at outside the system. Working on logistics APIs, the driver was parcels. Volume rose with commerce, peaked in a season everyone could name months in advance, and grew year over year in a band narrow enough to argue about. We disagreed about the multiplier. We did not disagree about the shape.

Internal systems worked the same way. Request volume tracked headcount, customer count, or transaction count. If you wanted to know what next year looked like, you asked someone in finance what they were forecasting and did arithmetic.

Agent traffic breaks that. The driver is not how many people you have. It is how many loops those people are running, and that number lives in a config file, a workflow matrix, or a retry policy. One engineer changing a concurrency setting on a Friday afternoon can move your load more than a quarter of hiring does. There is no external denominator to anchor the forecast to, which means the forecast is now a function of your own configuration surface.

Retries are the amplifier

The August 6 incident has a detail worth sitting with. A latent bug caused runners to retry revoked jobs instead of picking up valid work. That is a small bug. In a system already under pressure it is an accelerant, because retry traffic arrives exactly when there is no headroom left to serve it.

This is the failure shape I expect to see more of, not less. Agents retry. That is most of what makes them useful. The same property that lets an agent recover from a transient failure lets a fleet of them turn a brownout into an outage, and it does not require anybody to have written bad code. It requires a retry policy that was perfectly reasonable back when one caller had it.

I wrote a few days ago about idempotency being the guardrail that saves you at 2am. This is the other half of that argument, one layer down. Idempotency keeps a retry from duplicating an action. It does nothing about a retry storm consuming the capacity everything else needs.

The damage lands on the shared path

August 17 is the incident I would hand to a platform team. The proximate cause was a traffic surge past load balancer limits, but the reason it reached 29,000 organizations is that the degradation landed on a shared authentication path. Agent traffic did not take down the agent features. It took down issues, pull requests, the APIs, and webhooks.

That is the part worth checking in your own system this week. Not whether your agent workloads have capacity, but what they share with everything else. Connection pools, auth, DNS, a service mesh sidecar, one database primary. The blast radius of agent traffic is the set of things it shares, and most architecture diagrams do not draw that.

What I would actually do

Start with attribution, because you cannot forecast what you cannot count. If your logs cannot tell you what share of load came from an agent, which agent, and acting for whom, then your capacity model is guessing and so is your next postmortem. This is the same instrumentation argument I make about auditability, and it turns out to pay for itself twice.

Then give humans a lane. If agent workloads and interactive traffic share a pool, the agents will win, because they are patient and there are more of them. Separate queues, separate pools, or at minimum a priority that favours the request with a person waiting on the other end of it.

And treat concurrency settings as production configuration. If a change to a workflow matrix can double your peak, it deserves the same review as a schema migration.

One thing I got wrong

I have built capacity models off headcount growth that were confidently wrong, on a system where the real driver turned out to be a nightly batch job somebody had quietly parallelised. The model was fine. The denominator was wrong. I did not find that out during planning. I found it out during an incident, which is the expensive way to learn it.

The lesson I took from that is the one I would apply here. The question is not how much traffic you expect. It is what decides how much traffic you get, and whether that thing sits inside your system or outside it. For agent workloads it is inside. That is new, and it is worth re-planning around rather than scaling into.

Figures above are from GitHub's own availability report for August 2026.

Developer Weekly Briefing — September 11, 2026

Fri, 11 Sep 2026 12:30:11 +0000

A GitHub-heavy week — five stories in a row from the same platform, which says something about how fast the platform is moving right now. But the two Coder Legion pieces on agent memory and sovereign AI are the ones that will age well. Here's what mattered.

GitHub's HydraFusion takes model selection out of the developer's hands

Model selection for AI coding tasks has always been a manual routing problem: quick model for simple edits, stronger one for hard debugging, second model for a sanity check. Project HydraFusion, now in research preview inside GitHub Copilot, automates that decision.

The system runs three execution patterns. "Single" mode routes to one model outright. "Cascade" mode drafts with an efficient model first and escalates to a stronger one only if the draft fails a quality gate. "Critique" mode has a second independent model review the first one's output before a final revision. HydraFusion picks the least complex workflow that has a real shot at succeeding — not the most powerful one available.

Early numbers: on TerminalBench 2.1, GitHub reports a 4.9 percentage point quality improvement over Claude Opus 5 at 67% lower estimated cost. On CheckpointBench, costs dropped 65% with quality holding almost flat. Results vary by benchmark and workload, and this is a research preview rather than a GA feature — but the direction is clear.

The governance question worth tracking: HydraFusion chooses which model handles which task, but it doesn't yet expose that decision in a way that's auditable post-production. Which model drafted the code, which reviewed it, and why the system decided a cheaper model was sufficient — those are answers platform teams will eventually need for compliance reviews and incident postmortems.

Rust's first debugging survey: most developers skip the debugger entirely

Rust has built its reputation on catching errors at compile time. At runtime, 46% of developers use a debugger. The other 54% reach for println! — and it turns out that's the rational call, not a lazy one.

The Rust compiler team's first dedicated debugging survey, 2,300+ responses from an experienced user base, found that 74% report poor value representation in the debugger, and 55% can't reliably print a variable at all. When your debugger shows memory dumps instead of readable strings, print statements aren't a shortcut. They're the tool that actually works.

Async code is the weakest point: only 25% debug async code at all, the lowest adoption of any use case in the survey, and 28% of those who try report real problems. Macro-heavy code causes problems for 23%. And 62% of library authors have never heard of the debugger_visualizer attribute — a feature that would let them ship better debugger display instructions with their crates.

The Futurum Group's Mitch Ashley put the enterprise implication directly: "Platform teams standardizing on Rust for production infrastructure are inheriting verification debt they did not price. Value representation and async traces belong in the selection criteria alongside memory safety."

The Rust team has a response in motion — enum and collection representation, string rendering, async stack traces, and a Google Summer of Code project targeting debug info regression testing. It's the right list. Worth tracking whether it lands before Rust's production footprint grows faster than the tooling can support it.

AI agents have a communication protocol now. They still don't remember anything.

A2A just moved under the Agentic AI Foundation alongside MCP — one governance roof for the two protocols most agent systems depend on. Most of the coverage called it consolidation. MariaDB's chief product officer Vikas Mathur isn't convinced that's the right word.

"It doesn't solve for the agent amnesia, if that's the right word to use," Mathur said. "It solves for communication, but it doesn't solve for context."

The gap shows up quickly in large organizations running dozens of agents built by different teams. An employee exists under one ID in an HR system, a GitHub handle in a code platform, a full name in a third system. A2A doesn't resolve any of that. Agents can be technically communicating and still talking past each other about the same person.

Mathur's practical advice for developers building multi-agent systems now: don't start with ontologies and knowledge graphs. Start by getting enterprise data out of application silos first. Most enterprise data is still locked to whatever system created it, and that's the problem agents actually hit before they ever get to coordination.

His cost warning is also worth keeping: "They're selling a plan for $200 and spending $8,000 in the backend. That's fine for now, with venture money. Three years from now, that's not going to happen."

Why more enterprises are running agentic AI entirely inside their own data centers

Anurag Gurtu, CEO of Airrived, has spent two years hearing the same message from enterprises in the Middle East and Asia-Pacific: they want agentic AI, but they won't send their data, prompts, or operations to someone else's cloud to get it. His company sells a 10U GPU rack you drop into your own data center, air-gapped if you want it, with models, agents, orchestration, and data all running on-premises.

The three pulls toward sovereign AI he hears most often: trust (large organizations don't want to send sensitive data to Anthropic or OpenAI), cost (token spend is unpredictable and has no ceiling in a cloud model), and talent (the skills to build and run agentic systems are scarce enough that a fully integrated appliance beats a DIY stack).

His analogy for the DIY path — install Llama, wire up LangChain, add LangGraph for reasoning, connect n8n for orchestration — is blunt: "Installing Linux and discovering you don't even have a GUI yet, versus buying a laptop that's ready to use the moment you open the lid."

For teams evaluating sovereign AI seriously, the hardware availability note is practical: B-series and RTX Pro Nvidia chips are backlogged one to two months. H100s and H200s are available immediately.

GitHub roundup: four smaller moves worth knowing

Dependabot drops the PAT requirement for GitHub-hosted registries. Dependabot can now authenticate to GitHub Packages and ghcr.io using the same GITHUB_TOKEN mechanism as Actions — no personal access token needed. The practical result: one fewer long-lived credential to generate, store, rotate, and eventually forget about. Teams that already have PAT-based credentials in dependabot.yml don't need to rip them out immediately; the new path takes over as default and the old one stays as fallback. Read more

GitHub puts admin-controlled sandbox policy in JetBrains. Enterprise-managed sandbox policies for Copilot in JetBrains are now in public preview, letting IT set filesystem, network, proxy, and macOS Keychain access centrally. Once locked, settings show as "(managed)" and can't be overridden locally. A policy diagnostics tool confirms enforcement is actually landing on developer machines — a small but important addition given that a policy nobody can verify is close to no policy. Read more

GitHub Advanced Security self-serve trials expand to 300 licenses. The eligibility ceiling for no-sales-call GHAS trials moves from 100 to 300 licenses. Thirty days, full access to Code Security and Secret Protection across every repository. One-time shot — if it lapses, the next attempt is 180 days out. Read more

GitHub's August outages: growth is outpacing infrastructure. Five incidents in one month, all tied to the same root cause — Actions and Copilot usage expanding faster than shared infrastructure was built to support. Peak front-door failure rate in one incident hit 56%, affecting roughly 29,000 organizations. GitHub's own postmortem language: "Our shared infrastructure services have not kept up with our month-over-month actions growth and peak load." Worth reading if GitHub is in your critical path. Read more

Also from Coder Legion this week

Qodo wants a second agent watching your coding agent — specifically to catch the cross-service dependencies and billing logic gaps that a coding agent working in isolation can't see. CEO Itamar Friedman's target: 80% auto-approved PRs by end of 2027. Read more
Finite State's Larry Pesce: attackers are coming back for infrastructure everyone forgot to watch. Embedded systems, OT, legacy networking gear — the attack surface that got deprioritized when the industry moved to cloud-native. Read more

The through-line this week: automation is accelerating across model selection, sandbox enforcement, dependency authentication, and agent coordination — and the governance layer that makes all of it auditable and trustworthy is still the part that requires the most intentional work.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

I built a desktop client for DeepSeek's coding agent

Wed, 09 Sep 2026 11:33:11 +0000

Built a Windows desktop client for DeepSeek Harness.

V1 packages the official Web UI into a native app with:

One-click installer (bundles its own runtime)
Built-in browser — watch the agent browse in real Edge
Built-in terminal for CLI commands
Sandbox by default — every action needs approval
Bilingual (Chinese + English)

V2 with a fully custom workbench is in active development.

GitHub: https://github.com/See-Sol-Lab/DeepSeekGUI

Feedback welcome!

You Are Not Selling Your Code. You Are Selling the Next Commit

Tue, 08 Sep 2026 11:35:30 +0000

I spent the last few weeks reading the documentation, pricing pages and source of every tool I could find that sells access to a private GitHub repo. I expected the comparison to come down to features. It came down to one sentence in GitHub's own docs, and after that the shopping list looked completely different.

Here is the sentence, from the page on removing an outside collaborator: "While forks of private repositories are deleted when a collaborator is removed, the person will still retain any local clones of your repository." The next line tells you the rest of the job is yours - you are responsible for making sure the people who lost access delete what they copied.

A git clone takes ten seconds. No API call reaches it. So whatever you were told about protecting your source, the plain version is this: the only thing a refund can take back is the future.

Revocation is a subscription feature, not a security feature

Once you accept that, the whole category re-sorts itself. Revocation is not there to protect your code. It is there to keep a refunded buyer or a charged-back card away from the next tag, the fixed bug, the private issue tracker, the room where the other buyers talk.

That is a boring plumbing job, and boring plumbing is exactly what you should be shopping for. It also explains the refund policies of the people already doing this at scale: several of the big commercial boilerplates simply say access, once redeemed, is not returnable. The one I found with a proper no-questions window ships a generated download rather than repo access. A refund window is cheap when the product is a snapshot.

There is a pricing consequence hiding in there too. If you sell yearly access and your tool cannot revoke on its own, you are selling lifetime access at a yearly price, whatever the checkout page says.

Three things decide this before any tool does

GitHub's own rules come first. A repo under a personal account can only take collaborator invites; team-based delivery needs an organization. Organizations on a paid plan bill per seat, and a pending invitation is already a seat. Half the tools out there work one way, half the other, and that single fact eliminates most of the list before you have compared a single feature.

Then the invitation itself, which is where sellers actually lose money. GitHub emails the invite to the buyer's primary address, not the address they paid with, and it expires after seven days. There is no page on GitHub where a buyer can see invitations waiting for them - the community request for one was opened in 2018 and people were still adding "any update?" to the thread last year.

So your real timeline is: payment, an email into an inbox you do not control, six days of silence, expiry, a 404 that reads to the buyer as "I paid and got nothing", and a support ticket on day eight. Exactly one tool I looked at treats that as its own problem and re-issues before the deadline. Every other tool, and every tutorial script, leaves you as the retry mechanism.

Then geography and who is merchant of record. Stripe's availability page lists 51 countries and regions, and seven carry an asterisk: India and Indonesia in preview, five African countries handed to Paystack. That leaves 44 where you simply sign up, against 193 UN members. If you are outside that list, the entire "just connect Stripe" branch is closed to you and the question becomes which merchant of record will take you. If you are inside it, you get to choose whether the sales tax work is yours or somebody else's, and that choice costs a few points per sale.

Every option that exists, in one breath

Hosted, nothing to run: Polar has repo access as a built-in benefit, Dodo Payments is the newest merchant of record with a GitHub entitlement, and GitHub Sponsors will do sponsors-only repos at zero percent if monthly billing and an open-source-companion shape fit you.

Storefronts where you stay the merchant: BuyMyRepo, GitPaywall, Anystack. Crypto checkout with tarballs instead of invites: gitbuyer.

Payment platforms with no GitHub feature at all, where you bring your own glue: Gumroad, Lemon Squeezy, Whop, Patreon, Ko-fi, Buy Me a Coffee. The glue is usually Zapier, Make or n8n, and the recipes you will find online reliably cover the invite and quietly skip the revoke.

Self-hosted: Honorbox, Pay2Clone, SellRepo, Lemonrepo, and RepoAccess, which is mine - I will come back to that. Plus a long tail of $7 and $20 scripts and tutorials, which is where most sellers actually start.

And the option nobody frames as an option: skip repo access entirely. Ship a zip behind a license key. If your product is a snapshot rather than a stream of updates, the whole invite lifecycle is a cost with no benefit.

Where the tool sits	Examples	Revokes without you
Hosted, built-in GitHub delivery	Polar, Dodo Payments, GitHub Sponsors	Mostly yes
Self-hosted	Honorbox, Pay2Clone, SellRepo, Lemonrepo, RepoAccess	Depends, and the differences are large
Platform plus glue	Gumroad, Lemon Squeezy, Whop and friends, wired with Zapier or n8n	Usually no

Mine has a gap, and here it is

I built one of these. RepoAccess grants a GitHub team invite when a payment webhook arrives and removes it on refunds and chargebacks, and it runs as a single Cloudflare Worker on your own account.

It does not re-issue an invitation before the seven-day expiry. Honorbox does, at day six, up to three times, reading GitHub's own expiry flag rather than trusting a calendar. That is a real gap, I am naming it in my own comparison rather than hiding it, and it is on my list.

The two-minute test

Whatever you end up choosing, do this before your first sale: issue a refund in test mode, then open your organization's People page.

If the buyer is still sitting there, the tool you bought is a granting tool, and the revoking is you.

The long version - every tool with its actual behaviour, the fee table, what a month of twenty sales costs on each path, and six questions that each end in a name - is here: How to Sell Access to a Private GitHub Repo: Every Option Compared

Your setup guide is an untested surface. Make the tool drive the agent instead

Fri, 04 Sep 2026 15:04:30 +0000

My deploy wizard runs on the cheapest models on the market - Haiku in Claude Code, a free bundled model in OpenCode - and walks a stranger to a working, live-tested deployment in about an hour, two dashboard tours included: GitHub's and Stripe's. Not because those agents are clever. Because they don't have to be: the tool owns the sequence, the wording and the checks, and the agent only renders and relays.

Getting there meant deleting my prose setup guide. Here is why, and what replaced it.

Prose has no test suite

The setup path for my Cloudflare Worker used to be an 850-line markdown orchestrator. The agent read it, picked npm subcommands out of it, and hand-edited config files along the way. It worked, mostly - and "mostly" is the whole problem. Every edit to that file could break a live run, and nothing could catch it before a human walked the entire path again.

Dashboards make it worse. Payment providers rename tabs and buttons over time, and a guide that names the old one still reads as perfectly plausible - so the agent improvises something that sounds right. Improvised steps against a live payment dashboard are how an afternoon disappears.

A prose guide is a load-bearing component with no test suite. We would never accept that from code. We accept it from documentation because nobody is watching the moment it fails.

Every reliable installer already knows the answer

wrangler login does not hand you a markdown file and hope. Neither does gh auth login, or create-next-app. Every setup tool that people trust works one way: the tool drives and holds the state, and the human responds to the tool.

The moment AI agents arrived, we quietly lowered that bar. Hand the model an install README, call the result agentic, blame the model when it wanders. The fix is not a smarter agent. It is the old, boring inversion, applied to the new participant.

The contract: the driver decides, the agent renders

So the wizard became a program. The agent runs one command, npm run wizard:drive, which prints exactly one JSON record. The agent renders that record verbatim, collects the answer, and feeds it back. It never chooses the next step, never composes a shell command, and never diagnoses off-path.

A record is one of three things: a question - either a closed choice rendered as selectable options, or a named free-text field the human reads off a dashboard; a manual step the human confirms with the single word done; or a message to show. That vocabulary is the entire interface between the driver and whatever agent happens to be running it.

The current screen is a pure function of the state - cursor, answers, environment, flags. Which means every screen, every branch and every word a user reads is testable with no live agent and no side effects. The wording moved from prose into code, and code has tests.

"done" is verified, not trusted

A human says done; the driver checks. Wherever real state can be read - the GitHub org, the team, the token's capabilities, the deployed worker's URL - the driver reads it instead of believing the confirmation.

A failed check never advances the run. It emits that step's recovery block: the known failure modes, as data, routed back to the screen that owns the wrong input - a bad org goes to the org screen, a bad token to the token screen. The agent answers from the recovery instead of improvising a diagnosis. And the run ends with a live end-to-end test purchase, so "it works" is an observation, not a hope.

The agent never sees the secrets

The part I refuse to compromise on: you paste secret values into the env file yourself, and the deploy hands that file to wrangler, which reads it in its own process. The values never pass through the agent's context.

The permission rules that deny the agent's reads of the secrets files - by name - are committed in the repo, for every agent the wizard supports. And a test plants fake secret values, runs the wizard's file operations, and proves the refusal. You can read the enforcement before you run anything.

Why the cheapest model is enough

Most agentic-install demos run on a frontier model, and I think that has the causality backwards. If the setup needs a brilliant agent, the setup is underspecified - the brilliance is spent guessing what the author meant.

When the driver owns the sequence and the wording, there is nothing to be brilliant about. Rendering a record and relaying an answer is a job for the smallest model you can rent, which is exactly what my live runs use. Cheap models are also the discipline: they fail loudly on ambiguity instead of papering over it, so the driver gets better.

How to build one for your own repo

The pattern is small and does not depend on my product. What it takes:

A driver script with a pure currentRecord(state) and an advance(state, answer) that does the I/O through injectable dependencies, so tests pass fakes.
A record vocabulary - ask / do / say - with closed choices everywhere the answer set is known in advance.
Verify functions that run at the first point a credential for them exists, and recovery data attached to every step that can fail.
One npm script as the only entry point, so the agent never composes shell commands.
Committed permission configs for the agents you support, with the secrets files denied by name.
An AGENTS.md at the root, so any agent finds the door.

The working example is RepoAccess Core - an AGPL Cloudflare Worker that sells access to private GitHub repos, whose entire onboarding is this driver. The architecture behind the product itself is a separate write-up: How to sell access to a private GitHub repo without a SaaS in the middle.

If you maintain a repo that agents keep setting up wrong, steal the pattern. The guide you delete will not be missed.

Repository stats charts

Sun, 30 Aug 2026 17:28:44 +0000

Every README I've ever maintained has had that one section near the top: badges for stars, forks may be build status icon. They work, but they're just... images. Static, generic, the same little badge everyone else's repo has too.

What I actually wanted was simpler to describe than it turned out to be to build: pull the real numbers from a repo, turn them into an actual chart, commit it as an SVG, embed it like any other image. No third-party badge service holding my stats hostage, no client-side JS running in a README that can't run JS anyway.

So I built ProvChart Repo Stats.

What it actually writes

It's a GitHub Action. Point it at a repo, give it an API key, and on schedule (or on demand) it writes two SVGs straight into your repo:

File	Content	Default chart
`docs/charts/repo-overview.svg`	Stars, forks, watchers, open issues	area
`docs/charts/languages.svg`	Language share	horizontal bar

That's it. No hand-maintained JSON describing what the chart should look like, no dashboard to babysit. The numbers come from GitHub's API, the chart comes from ProvChart, the action wires the two together and commits the result.

Setup

1. Add a repo secret. Grab an API key from the ProvChart dashboard and save it as PROVCHART_API_KEY under your repo's Settings → Secrets → Actions.

2. Drop in the workflow.

name: Repo stats charts

on:
  schedule:
    - cron: "0 8 * * 0"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  charts:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: fscss-ttr/provchart-repo-stats@v1.3
        with:
          api-key: ${{ secrets.PROVCHART_API_KEY }}
        env:
          PROVCHART_API_KEY: ${{ secrets.PROVCHART_API_KEY }}

      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update repo stats charts"
          file_pattern: "docs/charts/*.svg"

3. Embed the SVGs in your README like any other image.

![Overview](./docs/charts/repo-overview.svg)
![Languages](./docs/charts/languages.svg)

Run the workflow once manually, or just wait for the Sunday morning cron. The action commits the SVGs, your README stays plain Markdown, nothing else changes about how your repo works.

What the charts actually look like

The overview chart is an area chart plotting your real counts, not squeezed onto a 0-to-100 scale:

And the language breakdown renders as a clean horizontal bar, share by percentage:

A couple of defaults worth knowing

Overview uses real counts. If your repo has 3,200 stars, the chart says 3,200, it's not forced into a 0-100 box.
Languages render as share percentages, which is usually the more useful way to look at a language breakdown anyway.
Both are configurable if the defaults don't fit: overview-type and languages-type let you switch to bars if that's more your style.

Under the hood it's all generated through ProvChart's generate-svg endpoint, so there's no image hosting involved and nothing rendered client-side. The SVG is just... a file in your repo, same as any other asset.

If you already maintain a .provchart/charts.json and want fixed sample charts instead of live repo metrics, there's a sibling action for that: provchart-readme-action.

Try it

Repo, issues, and feedback: github.com/fscss-ttr/provchart-repo-stats

If you end up using it on something, I'd genuinely like to see what your README looks like with it. And if something breaks or a default doesn't make sense for your use case, open an issue, I'm actively maintaining.

# Digital Nomads Are Becoming Network-Native Developers

Sat, 29 Aug 2026 06:40:13 +0000

Digital Nomads Are Becoming Network-Native Developers

The stereotypical digital nomad has a laptop, a backpack, and a suspiciously perfect beach in the background.

But for developers, the interesting part of digital nomadism isn't travel.

It's infrastructure.

Software development has reached a point where your physical location and your development environment can be almost completely separated.

A developer can live in Italy, push code to a repository hosted elsewhere, deploy to infrastructure across multiple regions, collaborate with maintainers on another continent, use AI agents running in the cloud, and receive feedback from users around the world.

The laptop travels.

The infrastructure doesn't have to.

Your Development Environment Is Becoming a Network

A traditional development organization depended heavily on physical infrastructure.

The simplified model looked something like this:

Developer
    ↓
Office
    ↓
Local Network
    ↓
Company Servers
    ↓
Company Knowledge

Today, many developers operate inside something closer to:

                Developer
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
       Git        Cloud        AI
        │           │           │
        ↓           ↓           ↓
   Open Source     APIs     Knowledge
        │           │           │
        └───────────┼───────────┘
                    ↓
              Global Network

The workstation is no longer the entire development environment.

It is an interface to the environment.

That's an important distinction.

Git Was One of the Foundations of Digital Nomadism

Developers were working asynchronously long before "digital nomad" became a lifestyle category.

Open-source development demonstrated that people who had never met could build complex software together.

Git made location largely irrelevant to source-code collaboration.

A developer in Europe can create a pull request.

A maintainer in Japan can review it several hours later.

Someone in Canada can identify a bug.

Another contributor can fix it from South America.

Nobody needs to occupy the same building.

The repository becomes the coordination layer.

Issue
  ↓
Branch
  ↓
Commit
  ↓
Pull Request
  ↓
Review
  ↓
Merge

Geography barely appears in that workflow.

Cloud Computing Removed Another Geographic Dependency

Git decentralized collaboration.

Cloud computing decentralized infrastructure.

A developer no longer needs physical access to the machine running an application.

From a laptop connected to the internet, we can provision databases, deploy applications, inspect logs, manage containers, operate APIs and coordinate infrastructure distributed across multiple regions.

The architecture might physically exist across thousands of kilometers.

But operationally, it can feel local.

This changed what "going to work" means for developers.

Sometimes going to work means opening a terminal.

AI Is Removing Another Layer of Location Dependency

AI introduces something even more interesting: portable access to technical knowledge.

Developers traditionally benefited enormously from location.

Working inside a strong engineering organization meant having experienced people nearby.

Living near a major technology hub meant access to communities, conferences and professional networks.

Those advantages haven't disappeared.

But access to knowledge is changing.

A developer working remotely can now combine:

Documentation
      +
Open Source
      +
Search
      +
AI Assistants
      +
Research Systems
      ↓
Development Workflow

AI doesn't replace engineering experience.

But it can dramatically reduce the friction involved in accessing information.

That makes geographic independence easier.

The important question becomes less:

Where are the experts?

And more:

Can I access the right knowledge?

The Next Step: Developers Working With Agents

The next phase of remote development may be more significant than the previous one.

Digital nomads currently move while their software infrastructure stays online.

AI agents introduce infrastructure that can continue working while the developer is offline.

Imagine a development workflow where agents can help:

Monitor
   ↓
Research
   ↓
Analyze
   ↓
Generate
   ↓
Test
   ↓
Report

The human developer becomes less tied not only to location, but potentially also to continuous presence.

This doesn't mean autonomous AI should deploy arbitrary production changes while you're sleeping.

Authorization, provenance, verification and human oversight become extremely important.

But it does mean the architecture of remote work changes again.

Instead of:

Human → Computer → Infrastructure

we begin moving toward:

                 Human
                   ↓
                Agents
             ↙     ↓     ↘
          Code    Cloud   Knowledge
            ↓       ↓        ↓
          APIs ← Systems → Services

The developer becomes an orchestrator of networked capabilities.

Payments Are Still Surprisingly Geographic

Software crossed borders much faster than financial infrastructure.

A developer can clone a repository from another continent almost instantly.

Getting paid internationally can still involve currency conversion, banking restrictions, fees, settlement delays and country-specific payment platforms.

That creates an interesting mismatch.

Code
Italy ─────────────────────→ Japan
          seconds


Payment
Japan ─────────────────────→ Italy
       intermediaries
       conversion
       settlement
       fees

Global digital work naturally creates pressure for better global payment infrastructure.

This is one reason cryptocurrencies, stablecoins, programmable payments and machine-to-machine payment protocols continue attracting developer attention.

The larger question isn't whether one particular payment technology wins.

It's whether internet-native work eventually produces internet-native settlement infrastructure.

Digital Nomadism Is Really an Infrastructure Story

The beach photos are the visible part.

The infrastructure underneath is much more interesting.

Digital nomadism became practical because multiple technologies converged:

distributed source control and open source;
cloud computing;
global communication;
collaborative documentation;
digital payments;
online developer communities;
increasingly, AI assistants and agents.

Remove those layers and the modern digital nomad becomes much harder to imagine.

That's why I think developers provide an interesting way to understand the movement.

We're not simply working remotely.

We're becoming network-native workers.

The Network Is Becoming the Workplace

For a network-native developer, professional identity doesn't have to be attached to a particular building.

Your code exists in repositories.

Your infrastructure exists in the cloud.

Your documentation exists online.

Your collaborators exist across time zones.

Your community exists across platforms.

Your AI tools can travel with you.

Your customers may exist anywhere.

The laptop is important, but it's not really the workplace.

It's the terminal connecting you to it.

The network is the workplace.

And AI agents could push this model even further.

The future digital nomad may not simply be someone who can work from anywhere.

It may be someone who participates in a persistent global network of humans, software agents, services and autonomous infrastructure — regardless of where they happen to open their laptop that morning.

That's a much more interesting future than working from the beach.

For developers working remotely: what part of your stack makes location independence possible today — Git, cloud infrastructure, AI, asynchronous collaboration, or something else?

Keep README charts in sync with a simple GitHub Action

Fri, 28 Aug 2026 13:44:33 +0000

I got tired of updating chart screenshots in READMEs by hand.

Either the numbers were stale, or I’d regenerate an image, commit it, and forget the next week. For docs and GitHub READMEs I don’t need a full chart library on the page — I need a vector file that still looks sharp.

So I wired ProvChart’s SVG API into a GitHub Action.

What it does

You describe charts in .provchart/charts.json
On schedule or workflow_dispatch, the Action calls the API
It writes .svg files into the repo (e.g. docs/charts/)
A commit step pushes them if anything changed

README stays simple:

![API traffic](./docs/charts/demo.svg)

No Chart.js in the README. No screenshot pipeline.

Minimal setup

Secret: PROVCHART_API_KEY (from the ProvChart dashboard)

Config (array of payloads):

[
  {
    "file": "demo.svg",
    "type": "area",
    "theme": "midnight",
    "width": 640,
    "height": 320,
    "axisX": ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
    "series": [
      {
        "name": "Requests",
        "color": "#8b7bff",
        "points": [20, 85, 40, 60, 10, 40, 95]
      }
    ]
  }
]

Workflow sketch:

- uses: fscss-ttr/provchart-readme-action@v1.0.4
  with:
    api-key: ${{ secrets.PROVCHART_API_KEY }}
    config: .provchart/charts.json
    output-dir: docs/charts

Then auto-commit the docs/charts/*.svg files if you want.

Why this shape

SVG fits Markdown and docs better than a heavy client chart stack
CI owns refresh; the README only references files
Same JSON model as the rest of ProvChart (line, area, bar, gauge, …)

Gauges at about 220×220 work well in a README.

Try without starting from zero

Sample repo (fork → add the secret → run the workflow):

github.com/Figsh/provchart-charts

Action:

github.com/fscss-ttr/provchart-readme-action

Not a replacement for interactive dashboards. Just a practical way to keep docs charts honest without babysitting PNGs.

CI is green. Your release may still be risky.

Mon, 24 Aug 2026 15:29:44 +0000

Every team has a moment like this: CI passes, the PR gets merged, the deploy goes out — and two hours later someone's asking why checkout is throwing 500s in production.

Nobody skipped a step. The pipeline was green the whole time.

The false comfort of green CI
Green CI feels like permission. It's a checkmark, it's fast, and it's automated — so it's easy to treat it as the final word on whether a release is safe. For a lot of teams, "tests passed" and "safe to ship" have quietly become the same sentence.

They're not.

What CI actually checks
Most CI pipelines are built to catch a specific, narrow slice of problems:

Does the code compile / build?
Do unit tests pass?
Does lint pass?
Maybe: does a small integration suite pass?

That's genuinely useful. It catches typos, broken imports, obvious logic errors, regressions in covered code paths. It's necessary.

It's just not the same thing as "this release is safe to put in front of users."

What CI doesn't tell you
CI has no opinion on:

Downstream dependencies — does the third-party API you call still behave the way your integration test mocked it to?
Manual steps — did someone actually run the DB migration on staging before merging, or is that still "to do"?
Deploy-time risk — blue-green cutover, cache invalidation, feature flag state — none of that is exercised by a test suite that runs against a branch.
Human process gaps — did the person who approved this PR actually understand the blast radius, or did they approve because the CI badge was green?

None of this shows up as a failing check. It shows up as an incident.

Release risk is a different question than test pass/fail
"Did the tests pass" is a yes/no question about code. "Is this release safe to ship" is a probabilistic question about a system: what changed, how big is the diff, does it touch a critical path, is there a rollback plan, has this kind of change caused problems before.

Most teams answer that second question with vibes — a Slack message, a shrug, "looks fine to me." That works fine until it doesn't, and by the time it doesn't, you're writing a postmortem instead of a checklist.

What a release risk gate actually looks like
The teams that don't get burned by this usually have some version of the same thing, whether they call it that or not:

A policy layer that blocks release on concrete conditions (required approvals, coverage thresholds, freeze windows) — not vibes, actual enforced rules.
A signal aggregator that pulls test results, error rates, and coverage into one release health view instead of five open tabs.
An audit trail — an immutable record of what was actually in a release, so when something breaks you're debugging from evidence, not memory.

None of this requires an enterprise platform. Small teams can build a lightweight version of this with GitHub Actions, a policy file, and some discipline. The point isn't the tooling — it's separating "code compiles" from "release is safe" as two distinct questions with two distinct answers.

Where to start if you don't have this yet
You don't need to build a whole release control system this week. Start smaller:

Write down the 3–5 things that, if skipped, have caused an incident before. Turn them into a checklist that's actually enforced, not just documented.
Add one non-negotiable gate to your PR template — coverage on touched files, or a manual QA sign-off for anything touching payments/auth.
Capture a snapshot of what shipped in each release (commit list, who approved, what tests ran) so your next postmortem starts with facts instead of "let me check Slack."

If you want a starting point instead of building it from scratch, I put together a Release Checklist Pack and a GitHub QA Gates Pack — practical templates for exactly this, no platform lock-in required.

I'm building Dulvarn, a release control system for GitHub-first teams, plus a set of standalone QA/release tools and templates. This post reflects my own experience shipping software, not any employer's views or confidential information.

Auto-close GitHub pull requests

Mon, 24 Aug 2026 08:24:30 +0000

You might be like me. You open the dishwasher and there's no order or discipline to how it's been loaded. If you leave it that way, half of your cups will come out gritty. The baking tray is going to stop the spinning water blade. The bowl is going to be filled with water. It's a mess.

If you're the person who re-loads the whole dishwasher, and if you're using GitHub Pull Requests... this post is for you.

Just like the dishwasher, I sometimes open GitHub to find the Pull Requests tab on a repository has been loaded badly. It's a mess.

The good news is, the fix is automated and easy.

Stale PRs

There's a GitHub-authored Action that tackles this problem, so you don't have to. Sadly, it doesn't work on dishwashers but let's take whatever wins we can get.

You add a new Action to the .github/workflows folder called stale-pull-requests.yml, then add the following:

A schedule to run the Action. Once a week is usually sufficient
A reference to actions/stale with a dusting of configuration

For scheduling, once a week is enough and you can set it up as a mittwoch maintenance activity. The syntax for schedules takes some getting used to, but 0 1 * * 3 fills the slots minute hour day-of-month month day-of-week. If you don't need to supply a value (like day-of-month, because we're doing it every week) you just use a *.

To help my friends, I always add a comment to explain the schedule.

name: Mark stale PRs
on:
  schedule:
    - cron: '0 1 * * 3'  # Every Wednesday at 1am UTC

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          stale-pr-message: 'Things seem to have gone quiet on this PR. There has been no activity for 60 days, so it will be closed in 14 days if there is still no movement.'
          close-pr-message: 'Closing due to inactivity.'
          days-before-pr-stale: 60
          days-before-pr-close: 14
          stale-pr-label: 'stale'

On the actions/stale front, you add a couple of messages, some timings, and a label.

stale-pr-message tells people what's about to happen; the PR seems to have wilted and it's going to get crushed
close-pr-message explains why the PR got crushed when it gets auto-closed
days-before-pr-stale is how long you wait before adding the stale-pr-message
days-before-pr-close is how much longer you wait before crushing it
stale-pr-label is the label that will be applied to stale PRs

There are two doors

Two things will happen when you add this. People will realize they forgot all about the PR and will move it on and get it approved, merged, and closed. Or they won't, and it will be kicked out of the pub by Peggy Mitchell.

Either way, the dishwasher is neat and tidy, and all your plates and cups get clean.

Your CI Pipeline Is the Most Privileged Machine You Own. You Have Never Scanned It.

Fri, 21 Aug 2026 20:17:57 +0000

You scan your application code. You scan your dependencies. You scan your containers.

You have never scanned the thing that has access to all of them.

Your CI pipeline holds your deploy keys. Your registry credentials. Your cloud tokens. Your signing secrets. It runs on every push, it runs third-party code you did not write, and it runs with more privilege than any developer on your team.

It is the most privileged machine you own. And for most projects, it is completely unreviewed.

Why Attackers Target The Pipeline

An attacker who compromises your laptop gets your laptop.

An attacker who compromises your pipeline gets production.

They do not need to find a vulnerability in your code. They do not need to phish a developer. They need one workflow file that trusts something it should not. The pipeline then does the work for them, with credentials you handed it, inside a network you allowed.

This is not theoretical. Supply chain attacks moved to CI years ago because that is where the credentials live. The Codecov bash uploader compromise in 2021 exposed secrets from thousands of CI environments. In March 2025, the widely used tj-actions/changed-files action was compromised and began leaking secrets into build logs of every repository that referenced it by tag.

Both attacks worked the same way. Trusted third-party code, running with pipeline privileges, on somebody else's push.

1. Actions Pinned To Tags Instead Of Commits

The mistake: Your workflow says uses: some-org/some-action@v3.

A tag is a pointer. Whoever controls the repository controls where it points. If that account is compromised, v3 silently becomes attacker code on your next run. You changed nothing. You approved nothing. You pulled it anyway.

The fix: Pin every third-party action to a full commit SHA.

# Do not do this
uses: some-org/some-action@v3

# Do this
uses: some-org/some-action@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

A SHA cannot be moved. Add a comment with the version so future you knows what it was.

How to catch it: grep -rn "uses:.*@v" .github/workflows/ lists every unpinned action you have. Do it now. The result is usually worse than expected.

2. Secrets Available To Every Job

The mistake: Your secrets are repository-wide. Every workflow can read them. That includes the lint job. That includes the job that runs a third-party formatter on a fork's pull request.

A secret is exposed to everything that can read it, not just to the step you were thinking about when you added it.

The fix: Scope secrets to environments, not to the repository, and require approval for the environments that hold production credentials. A test job does not need a deploy key. Give it nothing.

How to catch it: List your repository secrets. For each one, name the single job that needs it. Anything you cannot assign to a specific job is over-shared.

3. Workflows That Run On Untrusted Pull Requests

The mistake: You use pull_request_target because you needed a token that pull_request does not have, and then you check out the pull request head.

That combination runs attacker-controlled code with your secrets in scope. It is the single most reliable way to leak credentials from a public repository.

The fix: Use pull_request for anything that touches untrusted code. If you genuinely need privileged work on a fork's contribution, split it: an unprivileged job builds and uploads an artifact, a separate privileged job consumes the artifact without ever checking out the fork's code.

How to catch it: grep -rn "pull_request_target" .github/workflows/. Every hit needs a written justification. If nobody remembers why it is there, it should not be there.

4. Default Write Permissions On The Job Token

The mistake: You never set permissions:, so the automatic token gets whatever the repository default is. On older repositories, that default is write. Any compromised step in that job can push commits, edit releases, or open pull requests as your CI.

The fix: Default to nothing and grant upward per job.

permissions:
  contents: read

jobs:
  build:
    permissions:
      contents: read
  release:
    permissions:
      contents: write

How to catch it: Any workflow file with no permissions: block is running on defaults. Search for the files that lack it, not the ones that have it.

5. Secrets Printed Into Logs

The mistake: Someone added set -x while debugging, or a step echoes a config object, or a failing command dumps its environment. Masking catches exact string matches. It does not catch a secret that has been base64 encoded, JSON wrapped, or split across a variable expansion.

Build logs on public repositories are public. Artifacts are downloadable.

The fix: Never echo configuration. Remove debug tracing before merge. Treat log output as published, because it is.

How to catch it: Run a secret scanner across your own build logs and artifacts, not just your source tree. Gitleaks and TruffleHog work on any text. Most people never point them at the one place secrets actually get printed.

The Ten Minute Audit

You do not need a new tool for this. Open a terminal in your repository:

# Unpinned third-party actions
grep -rn "uses:.*@v" .github/workflows/

# Workflows that run untrusted code with privileges
grep -rn "pull_request_target" .github/workflows/

# Workflows with no explicit permissions block
grep -rLn "permissions:" .github/workflows/*.yml

# Debug tracing left behind
grep -rn "set -x" .github/workflows/

Four commands. Ten minutes. Fix the SHAs first, then the permissions blocks. That covers most of the realistic attack surface.

Why This Stays Broken

Pipeline security falls between two teams. Application security scanners read your source code, not your workflow files. Infrastructure scanners read your Terraform, not your build steps. The pipeline sits in the gap, and the gap is where the credentials are.

The tools that do read workflow files exist. Checkov covers CI configuration, Semgrep has rules for GitHub Actions, and actionlint catches the structural problems. None of them is the default in a new repository, which is exactly why this keeps working for attackers.

The Bottom Line

Your pipeline has more privilege than you do. Scan it like it does.

Pin your actions to SHAs. Scope your secrets. Never run untrusted code with credentials in reach. Then go look at what your build logs have been printing this whole time.

Discussion Question

Go run grep -rn "uses:.*@v" .github/workflows/ right now. How many unpinned actions did you find? I want to know if anyone is actually at zero.

Developer Weekly Briefing — August 21, 2026

Fri, 21 Aug 2026 12:36:02 +0000

A busy week across tooling, supply chain security, and governance. Two stories have immediate action items attached. Here's what mattered.

GitHub Copilot bets on model choice, not model loyalty

GitHub's latest Copilot update, covering the week of August 10, adds two new models — Kimi K3 across all plan tiers and MAI-Code-1.1-Flash with native image understanding — and enables per-turn model switching in VS Code 1.133. Developers can now move between Claude BYOK and built-in Copilot models mid-session without restarting or losing context.

The direction is clear: GitHub is building Copilot as a multi-model orchestration layer, not a tool that wins by having the best single model. Agent Plugins 1.0 is now GA and works the same way across VS Code, Copilot CLI, the Copilot app, and the SDK — meaning internal tooling built for one surface no longer has to be rebuilt for another. JetBrains adds Copilot Memory for cross-session context retention and Ollama support for local model access.

Copilot CLI got the most substantial updates: a /tasks command for subagent management, prompt queuing while agents are mid-task, headless autopilot combining --plan and --mode flags, and /rewind for undoing Copilot changes without touching git.

The governance gap worth flagging: Copilot doesn't record which model contributed to which line of code. Per-turn model switching makes that gap wider, not smaller. By the time something breaks in production, the decision about which model wrote the relevant code is invisible in the build record. That's an audit and incident-response problem waiting to happen for any team that needs to reconstruct what happened and why.

VS Code decouples AI agents from the editor window

Microsoft separated AI agent sessions from the VS Code editor itself in the latest release, meaning agent workloads can run independently of whatever the developer has open in the editor. For teams running parallel agent tasks or background automation, this is a meaningful architectural change — agents no longer compete with active editing sessions for the same window context.

Claude Code's temporary usage boost expires tonight

If you're a Claude Code user on the temporary expanded usage tier, the boost ends tonight. This is worth checking before you kick off anything long-running this evening. Anthropic hasn't announced what the new baseline looks like post-expiry, so it's worth knowing where you stand before the session caps reset.

npm v12 shuts down a popular malware trick — the threat isn't gone

npm v12 is now generally available, and the install script changes from July are in effect. The specific malware technique it blocks: postinstall scripts that run automatically on package installation, which have been a primary vector for supply chain attacks across the JavaScript ecosystem. That particular trick is now off by default.

But it's worth being clear about what v12 doesn't fix. Attackers will adapt. The next wave of npm-based attacks will use whatever path npm v12 left open. The value of the upgrade is closing a well-documented, heavily exploited vector — not ending the supply chain threat category.

LangChain's dcode isn't new — its governance play for sensitive code is

LangChain has been shipping dcode for a while. What's new is a governance layer that lets organizations enforce policies around what happens when AI agents interact with sensitive code — access controls, audit trails, and restrictions on what can be passed to external models. For teams that've held back on agentic coding tools specifically because of sensitive IP concerns, this addresses the gap more directly than most tools in the space.

GitHub sharpens CodeQL for Actions workflows and modern JavaScript

CodeQL now covers GitHub Actions workflow files and modern JavaScript patterns that the previous ruleset wasn't catching. If you run CodeQL as part of your CI/CD security scanning, the coverage improvements apply automatically. Worth a scan run after the update to see what surfaces.

Tessl is betting on standards to close the AI code review gap

AI agents write code faster than anyone can review it — that's the established problem. Tessl's argument is that the solution isn't better tooling, it's standards: a shared specification layer that defines what AI-generated code is expected to do, so review can be partially automated against a known target rather than always requiring a human to reconstruct intent from the output. An interesting architectural bet worth tracking.

One retiring developer nearly broke a retailer's core system. Hypercubic built AI to catch that kind of undocumented institutional knowledge before it walks out the door. Read more
Harness GM Rahul Sood: most "AI remediation" claims don't actually work. A candid breakdown of where vendor promises outrun what the tools can actually deliver — and what real remediation looks like in production. Read more
Crogl's Monzy Merza: the SOC agent that refuses to say it can replace you. An honest conversation about where AI agents belong in security operations and where they don't. Read more
Blumira's Hearth turns security investigations from hours into minutes. AI reasoning applied to the investigation workflow, not just the alert triage layer. Read more
Detectify's Rickard Carlsson: attackers don't have new tricks, they have a faster clock. A grounded take on why the threat landscape feels more urgent even when the techniques haven't fundamentally changed. Read more
AWS is betting $500M that students will learn cloud by building. The payoff is still unproven, but the investment signals where Amazon thinks developer education is heading. Read more
Windows Server still has gravity. Kubernetes hasn't escaped its pull. A look at why the migration away from Windows Server in enterprise environments keeps moving slower than the cloud-native narrative suggests. Read more

The through-line this week: the tooling is getting faster and more capable across the board — model switching, agent decoupling, automated code standards — and the governance layer is still catching up. The Copilot model attribution gap and the LangChain sensitive code controls are both responses to the same underlying tension: moving fast with AI tools is getting easier, and knowing exactly what happened and why is getting harder.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Coder Legion - Recent posts tagged github

The Maintainer Who Wrote "Sorry, I Missed the Request!"

The world's least dramatic pull request

The strange psychology of an unanswered PR

Thirty-five minutes

We talk a lot about automation. We talk less about attention.

A reminder doesn't have to be a demand

Small contributions are still real contributions

The other side of the notification

One more thing before I close GitHub

Developer Weekly Briefing — October 30, 2026

Two GitHub campaigns, one weak point: your config files

AI coding tools can read your SSH keys — two are still unpatched

Flint runs 40B parameters locally — and keeps your code off someone else's server

SAP's CTO says building the agent is now the easy part

Oracle gives each agent its own identity

Also from this week

Developer Spotlight this week

My github acount has been suspended

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

What we're building

AI agents are beginning to participate in the conversation

How we want collaboration to work

Join us

OpenSource #AI #AIAgents #GitHub #Decentralization #Marketplace #Community

From GitHub to Codeberg: Rethinking Repository Management and Personal Website Hosting

I’m back, and this time we’re coming out of the casino, not the mine! 😎

Here I am again, this time with a buddy of mine who’s a Monero miner.

--- KOZMO TITAN HIGH-SPEED SETTINGS ---

Güvenli ve stabil çalışan resmi XMRig C++ derlemesi

# 🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

🧠 We need your ideas, not just your code!

🔗 Join the discussion

OpenSource #GitHub #Blockchain #Monero #Bitcoin #Ethereum #Marketplace #WebDevelopment #Freelancing #Decentralization #MyZubster

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

🔧 What We Built and Tested

🐛 What Still Needs Work

🌍 Beyond a Traditional Marketplace

🤝 Looking for Contributors

Let's collaborate

OpenSource #AI #GitHub #NodeJS #Decentralization #DeveloperCommunity

REA GitHub Tutorial: Reverse Engineer Anything with Claude Code (Full Setup + Fi

What is REA?

Hype vs reality

How to install REA

Mac & Linux (guided)

Windows (manual — this is what worked for me)

Demo: reverse engineering VS Code

1. What Code.exe really is

2. Nine Electron security fuses

3. Who VS Code talks to

4. Seven processes

Troubleshooting: every error I hit

My verdict

Use it responsibly

Why Git Blob IDs Mismatch Your File Checksums

Why Does Hashing Raw File Bytes Produce Another Value?

How Is UTF-8 Byte Length Different from String Length?

When Must Application Integrity Use a Separate Digest?

Additional Scenarios and Failure Modes

Execution and Verification Checklist

Conclusion

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