Standing on Shoulders, Ethically: Crediting Prior Reverse-Engineering Work
The batchexecute rpcids this app relies on were mapped by someone else's open-source project first. No code was copied, but the knowledge came from somewhere — and the README says exactly where.
Nothing in this series so far — not the batchexecute reverse-engineering, not the rejected master-token approach — was worked out from a blank page. I want to be specific about that, because "no code was copied" is a load-bearing claim only if it's paired with an honest account of where the knowledge came from, and burying that in a casual thanks-to line at the bottom of a README undersells how much the project actually depends on it.
The README's Credits section, and specifically what each source contributed — not a generic thanks-to list.
What was actually taken from each project
The README's Credits section names two prior projects precisely, and distinguishes what each one contributed rather than lumping them together:
xob0t/Google-Photos-Toolkit (MIT) worked out the mapping of Google Photos' private web API — which batchexecute rpcids correspond to which operations, and the positional layout of the responses those rpcids return. That's exactly the knowledge the second post in this series describes as unpublished, undocumented, and recoverable only by watching real network traffic. This project didn't independently redo that observation work; it built on the mapping the Toolkit project already published.
xob0t/gpmc (MIT) documents the different, mobile protobuf API — the one behind impersonating the Android app with a master token, described and explicitly rejected in an earlier post. This project evaluated that path using gpmc's documentation and chose not to build on it. Citing it isn't incidental: it's the source that made an informed rejection possible in the first place, rather than a guess.
Why "no code was copied" is the easy half of the claim
The README states plainly: "No code was copied from either; the API knowledge was reimplemented in Kotlin." That's true, and it's also not the part that matters most. Both source projects are MIT-licensed, which would have permitted copying code directly with attribution. Reimplementing from scratch in Kotlin rather than porting or copying was a design choice, not a licensing requirement.
The part that actually needs saying is that the hard-won knowledge — which rpcid means "move to trash," how to read a positional array that has no documented schema — came from someone else's unpaid reverse-engineering effort. That work doesn't show up in a git blame, a dependency manifest, or a license header the way copied code would. It's exactly the kind of contribution that's easiest to quietly benefit from and easiest to forget to credit, because there's no tooling that forces you to.
Why this discipline matters beyond politeness
Crediting prior reverse-engineering work does three concrete things beyond being fair to the original authors:
- It's verifiable. Anyone skeptical of a claim in this series — "is this rpcid mapping actually right?" — has a named, linked source to check it against, rather than having to trust an unsupported assertion.
- It routes people to better primary sources. The README says outright: "Both are worth reading if you want to understand the protocol." Someone who wants to go deeper than this app's specific Kotlin implementation now knows exactly where to look.
- It documents the rejected path honestly. Citing gpmc for the master- token approach means the rejection in an earlier post isn't "I assume that's dangerous" — it's "I read how it actually works, from the project that documented it, and decided against it anyway."
None of this is legally required by an MIT license. It's a judgment call about what responsible reuse of someone else's unpaid research looks like — and it costs one clearly-written paragraph in a README to get right.
Series: Google Photos Cleaner.