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?

As computer ownership grew, developers needed reliable ways to deliver software and games.

Physical media made distribution possible. Floppy disks allowed users to install software locally and keep control. Later CD-ROMs made it possible for larger software distribution. But updates were slow and expensive, because fixes often required shipping new media.

The internet made distribution faster and broader, but also increased security risk. Malware, tampering, and phishing became part of the normal threat model.

In crypto contexts, where users may store wallets on their machines, compromise can be especially costly.

Browser-based software reduced OS and architecture friction, but introduced its own costs: heavy resource usage, weaker ownership, and increasing dependence on remote services.

The Hidden Cost of “Convenient” Distribution

Over the last decade, more software has shifted to cloud delivery and cloud execution.

That convenience often comes with a tradeoff: users lose ownership and control over software they rely on.

From Ownership to Rental Models

The shift is not only about software subscriptions. There is now pressure toward renting compute itself.

Jeff Bezos has argued that companies will increasingly “buy compute off the grid” from cloud providers (DealBook transcript excerpt).

That model is now being discussed for consumer workloads, including gaming example discussion.

Why Software Updates Still Feel Risky

Web-based software distribution still creates trust problems. Most users cannot independently verify what code they are running after an update.

Binary signing and reproducible verification help, but they are not simple workflows for everyday users.

Why Games Make the Problem Obvious

Games are a clear example because performance is sensitive and latency matters. In competitive games, every millisecond counts.

This is one reason many players still prefer local hardware over cloud execution.

Browser-based and cloud-heavy gaming can work for some use cases, but scale and performance limits remain real.

What a Better System Should Do

In a better model, users should own their software, keep control of their data, and still get safe, usable updates.

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-style 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 already have a TUI that can browse, install, run, verify, and uninstall games.

On the trust side, metadata distribution is connected to Bison Relay, 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.