chiaki-ng

My first contribution to someone else's open-source project. I was a Java developer who had never written C++ in my life. I picked it up as I went. Some of what I wrote got merged and later rewritten, some of it got rejected during review. The library I extracted from the work still ships with the project today.

TL;DR

The project: chiaki-ng (originally chiaki4deck) is the most popular fork of Chiaki, the open-source PlayStation Remote Play client. ~2.3k stars, maintained by @streetpea. On a Steam Deck it's the way you play your PS5 away from the living room.

The itch: I was using it on my Deck. Launching it felt like a second-class citizen compared to games launched through Steam itself: no custom artwork, no proper library entry, no SteamOS gamepad context. It felt like it should be one click to "add Chiaki as a Steam shortcut with PlayStation-shaped artwork."

The contribution: three threads of work, an "Add to Steam" GUI, a PSN Account ID collector, and a CLI autoconnect mode, merged into a fork I ran, then submitted upstream as a series of PRs in late 2023 / early 2024.

The outcome: a mixed, instructive first-OSS-contribution outcome.

What I set out to build

PS Remote Play on a Steam Deck should feel like launching any other game. That means:

• A Steam shortcut pointing at chiaki4deck with the right launch flags for a specific console.
• Proper library artwork (grid poster, landscape, hero image, logo).
• The SteamOS gamepad context, so the Deck's controller behaves as controller-shaped and not mouse-shaped.

The existing project had a CLI and a settings GUI but no path to any of that. The Deck experience was: boot to Desktop, launch chiaki, remember your settings, launch your console. I wanted: press Steam button → PS5 → go.

The Add-to-Steam GUI (PR #109)

A Qt 6 dialog added under the main Chiaki settings. It:

1. Let the user pick a registered console.
2. Pulled artwork from the Steam Grid DB API, grid / landscape / hero / logo, with a thumbnail selector per artwork type, so you could flick through covers before committing.
3. Also accepted custom uploaded images per artwork type.
4. Wrote a new entry into Steam's shortcuts.vdf with the correct launch flags (specifically chiaki4deck plus --console and the selected console's nickname).
5. Set the Neptune (Deck) controller profile for the new shortcut by editing configset_controller_neptune.vdf so the controller behaved on first launch.

The tricky bits were the VDF file formats, a pair of bespoke binary-ish text formats Valve uses for shortcut and controller config. I leaned on TinyTinni's ValveFileVDF for parsing and wrote the shortcut-writing layer myself.

Learning C++ in public

Before this I was a Java developer who hadn't touched C in a decade and had never written C++. I said this in the PR thread, then taught myself as I went, pushed code, took review feedback, and rewrote. The early commits used std::cout for logging; a review comment nudged me to CHIAKI_LOGE / CHIAKI_LOGI. I'd initially made the VDF parser an entirely static namespace because I didn't understand how to pass a logger reference around cleanly; I redid it when streetpea pointed it out. I pulled CURL in; a review suggested using Qt's QNetworkAccessManager instead and I swapped it out. That's roughly the texture of the whole PR: paired review with a stranger, in a language I was learning, over a month.

This is the bit I'd recommend to anyone: you do not need to know the language before you contribute, but you do need to be willing to rewrite what you wrote the week before.

What happened to the PR

The PR got ~25 comments of productive review with streetpea, who was supportive and collaborative throughout. Then two other project contributors weighed in with more fundamental scope feedback, "a lot of code for a tiny feature", the artwork flow was too much, the launch-script approach had UX issues on cold start. I agreed to clean up and gate the artwork flow behind a CMake flag. The PR was then closed; the feature landed later in a leaner form that the project rebuilt themselves against a new Qt UI.

Being wrong in public about how much a feature is worth is the OSS lifecycle working exactly as it's supposed to. I don't think that's a clever reframing of a disappointment, I think it's just true. A maintainer's job is to hold scope; mine was to propose something and accept the outcome.

The part that did survive: cpp-steam-tools

After the PR closed I extracted the VDF / shortcut / controller-config work into a standalone C++ library:

• Repo: Nikorag/cpp-steam-tools
• Dependencies: Qt 6, TinyTinni's ValveFileVDF (vendored)
• Install: CMake FetchContent

include(FetchContent)
FetchContent_Declare(
    cpp-steam-tools
    GIT_REPOSITORY https://github.com/nikorag/cpp-steam-tools.git
    GIT_TAG main
)
FetchContent_MakeAvailable(cpp-steam-tools)
target_link_libraries(<YOUR PROJECT> PUBLIC cpp-steam-tools)

The public API is narrow and on purpose:

SteamTools* steamTools = new SteamTools(infoLambda, errorLambda);
 
steamTools->steamExists();
steamTools->parseShortcuts();
steamTools->buildShortcutEntry("appName", "/path/to/exe", "launchOptions", artworkMap);
steamTools->updateShortcuts(shortcuts);
steamTools->updateControllerConfig("AppName", "ControllerConfigId");

chiaki-ng's build still depends on cpp-steam-tools today, it's listed as a submodule, referenced in the CMake config, and pulled by the AppImage build scripts. The feature PR didn't land, but the engine behind it did, and it's the durable piece of the contribution.

Credit inside the library README for the original use-case and reviews goes to streetpea, jbaiter, and nowrep.

The other thread: PSN Account ID (PRs #114, #135)

Chiaki needs a user's PSN Account ID (not their public ID, the internal numeric account ID) to register with a console. Getting it was a known pain: users had to follow external instructions to extract it manually.

I added an embedded Qt WebView that logs a user into my.account.sony.com, intercepts the authenticated session, calls the PSN API for the current user's account ID, and hands it back to the registration flow. One click instead of a copy-paste-from-a-tutorial walkthrough.

Both PRs were merged. Later, a maintainer rewrote the flow in a way that didn't use the WebView approach at all, I assume for reasons like binary size, platform portability, or not wanting an embedded browser for this one purpose. That's fine. The problem I was solving got solved, and the solution I wrote was the one standing in the gap while they worked out a better one.

The Discord

The project didn't have a community chat when I was contributing. I suggested one. Streetpea set it up, and it grew into the project's main development and user community, "fairly active" was my last read. Not a line of code, but a small piece of infrastructure that I think mattered.

What contributing to somebody else's OSS project taught me

1. You learn a language faster by being reviewed in it than by reading books about it. A month of PR comments from strangers who cared about the quality of the codebase did more for my C++ than any amount of self-study would have.
2. Your code is not your contribution. The code gets rewritten. The library gets extracted. The Discord turns into a community. The durable artefacts of a contribution are rarely the diffs.
3. "Your PR got closed" is an OSS outcome, not an OSS failure. A well-run project holds scope. If that scope doesn't include what you proposed, the project is doing its job, not rejecting you. I found this much easier to say with a year of hindsight than I did at the time.
4. Infrastructure suggestions count. Suggesting the Discord was probably the single most consequential thing I did for the project's day-to-day life, and it was a one-sentence suggestion.

Links

• chiaki-ng: github.com/streetpea/chiaki-ng
• cpp-steam-tools: github.com/Nikorag/cpp-steam-tools
• Merged PSN Account ID PR: #114 · #135
• Add-to-Steam PR (closed, for reference): #109