Software Distribution Is Still Broken

Introduction

Getting software onto people’s computers has been a challenge since personal computing became mainstream.

We have tried many approaches: floppy disks, CD-ROMs, direct web downloads, torrents, app stores, and cloud platforms.

Each approach brought real benefits, but each introduced new tradeoffs.

In this post, I’ll explain the problem and outline a better path forward.

What Is the Software Distribution Problem?

Software distribution isn’t just “how do I download an installer.” It’s a three-part problem:

• Delivery: getting software onto a user’s machine
• Updates: shipping fixes and new versions reliably
• Trust: ensuring the bytes installed are the bytes the publisher intended

As computer ownership grew, each generation of distribution solved one part and exposed another.

Early on, physical media made delivery straightforward. Floppy disks (and later CD-ROMs) let users install locally and keep control of what they ran. But updates were slow and expensive. Fixes often meant shipping new media.

The internet improved delivery and updates overnight, but expanded the threat model. Malware, tampering, and phishing became normal risks, because distribution now happened over channels that could be imitated, hijacked, or compromised.

In crypto contexts, the stakes are even higher. If your machine holds keys (please, don’t) or wallets, a single compromised update can mean irreversible loss.

Web apps reduced OS and architecture friction, but introduced a different tradeoff: heavier clients, weaker ownership, and growing dependence on remote services. The user gets convenience, but often at the cost of verifiability and control.

The Hidden Cost of “Convenient” Distribution

Over the last decade, “distribution” quietly shifted into something else: not only delivering software, but also moving execution and compute off the user’s machine.

That shift is convenient, but it changes the relationship users have with their tools. When software runs in the cloud (or is locked behind always-online services), users don’t really own what they depend on. They rent access.

From Ownership to Rental Models

This isn’t only about subscriptions. More companies now frame compute as a utility: rent it from cloud providers instead of owning capable local hardware.

You can see this trend gaining traction as AI workloads make high-end hardware harder to access, which could lead to fewer people owning their own machines.

The problem with not owning your tools is that providers control your access. They can lock you out for policy, platform, or political reasons.

Why Software Updates Still Feel Risky

Even when software runs locally, modern updates often require blind trust. Most users can’t verify what code they’re running after an update, or whether the download path was tampered with.

Signing and reproducible builds help, but they’re rarely presented as a normal, easy workflow. So the default experience is: update first, trust later.

Why Games Make the Problem Obvious

Games expose these tradeoffs because performance and latency are non-negotiable. In competitive games, milliseconds matter, and cloud execution adds unavoidable delay and infrastructure dependence.

Browser-based and cloud-heavy gaming can work for some use cases, but the limits show up fast. I believe this is one reason many web3 games did not really catch on: browser games often hit hard platform constraints.

Games are also where physics constraints become obvious. Speed of light is simple too slow

What a Better System Should Do

A better distribution model should preserve the advantages of modern delivery without forcing users to surrender control.

Users should be able to:

• install and run software locally
• keep control of their data
• receive updates that are safe by default
• verify what they run without becoming security experts

What We Propose

I’ve built poker and pong games for Decred, and we now need better distribution for them.

Decred Gaming aims to provide a Steam-like experience focused on ownership and verification.

dcrg is our attempt at a safer distribution system: transport can be untrusted, but releases remain trustworthy through signed metadata and client-side verification.

We use a TUF-based design to improve update safety without making operations harder. Metadata can be delivered over Bison Relay or other channels, then verified locally.

What Is TUF?

TUF (The Update Framework) is a security layer for software updates.

In plain terms: you can download from an untrusted source and still verify whether what you got is authentic.

It does this with signed metadata, version checks, and expiration checks.

Even if a server or mirror is compromised, an attacker cannot easily ship a fake update without signing keys.

That is why TUF fits dcrg: transport can be messy, but verification remains strict on the client.

flowchart LR
      subgraph Build["Publisher Build + Release"]
          A["Game Source"] --> B["Release Artifacts"]
          B --> C["GitHub/CDN Artifact Hosting"]
      end

      subgraph Control["Trusted Control Plane (dcrgd)"]
          D["dcrgd Release Monitor"] --> E["dcrgd TUF Signer"]
          E --> F["dcrgd BR Metadata Bot"]
      end

      subgraph BR["Bison Relay Network"]
          G["Metadata Transport"]
      end

      subgraph Client["End User Machine (dcrg)"]
          H["dcrg Launcher/Updater"]
          I["TUF Verification<br/>(signatures, expiry, rollback)"]
          J["Local Game Install"]
          H --> I --> J
      end

      F -->|signed metadata| G --> H
      C -->|"artifact bytes (untrusted transport)"| H
      I -->|"verify artifact hash vs TUF targets"| J

What dcrg Is (In Plain Language)

dcrg is a game launcher for Decred games focused on fixing the trust problem in software distribution.

It is not cloud gaming. Games install locally, run locally, and remain under user control.

Core idea: even if download infrastructure is untrusted, releases can still be trusted.

dcrg uses TUF metadata and verifies content on the client before install or update.

In practice, it is a lightweight Steam-like launcher built around:

• software ownership
• verified updates
• reduced trust in any single server

How dcrg Builds Trust Without Extra Friction

Users do not need to perform manual security steps for each update.

Install and update flows stay familiar, while dcrg verifies metadata signatures, version, expiration, and file hashes in the background.

If checks fail, the client rejects the update or install.

That means users can know exactly which version they are running, and that the bytes match what was signed.

What We’ve Built So Far

We built a Proof of concept with a Terminal UI (TUI) that can browse, install, run, verify, and uninstall games.

On the trust side, metadata distribution is connected to the Bison Relay network, with client-side verification enforcing integrity.

Conclusion: A Safer Way to Ship Games

Software distribution is still broken when convenience requires users to give up ownership and trust updates blindly.

dcrg is our answer to that tradeoff: local execution, signed metadata, and client-side verification before installation.

Transport can be untrusted; integrity does not have to be.

This is the direction we believe in: own your software, verify what you run, and keep usability simple enough for normal users.

Distribution should be trustworthy by default, not an afterthought.