The Forked SDK
How a devtools company made it obvious which package was actually theirs.
This story sits inside our mission to make digital provenance effortless, universal, and trustworthy for the people and systems who depend on it. See Mission & Vision
Problem … When your SDK shows up with someone else's name
RelayKit publishes official SDKs on GitHub, npm, PyPI, etc. Time passes: copies appear with minor refactors, their original comments and structure, new branding.
Issues:
- Devs ask: "Which one is the official client?"
- Marketplace teams have limited bandwidth to adjudicate "they copied us" claims.
Summary:
- Git history alone isn't always persuasive for marketplaces/legal.
- Attribution can be stripped.
- Code similarity is clear to engineers, but not to non-technical reviewers.
Solution … Mirror turns each SDK release into an anchored, reference package
Step 1: Connect repo to Mirror
RelayKit connects their SDK repos to Mirror.
Step 2: Register releases
On each official release, Mirror hashes repository state or release tarball, generates a manifest containing authorship (RelayKit), version, repo URL, license, publish targets (npm package name, etc.), anchors the manifest externally (OTS / IPFS). A public provenance URL is available for each version.
Step 3: Embed provenance in docs & package metadata
RelayKit links the official SDK provenance page in docs, README files, marketplace descriptions where possible, optionally embeds a short provenance signature / link into package metadata.
Flow … When a forked package tries to pass as the original
Step 1: Discovery
A forked package appears on a registry with nearly identical code, new branding.
Step 2: Analysis
RelayKit diff-checks the package locally, then opens Mirror: finds the closest matching release manifest, exports a provenance bundle including original SDK manifest, hash of the canonical release, timestamps, anchors.
Step 3: Contact
They contact the registry attaching the bundle attached, a brief summary of code similarity.
Step 4: Review
Registry reviewers don't have to parse Git drama. They can see neutral, time-stamped origin information.
Step 5: Resolution
The registry may mark the fork as derivative or de-list if it violates policy, but in any case: there is a clear reference for "official" vs "fork."
"Instead of pointing to a repo and saying 'trust us,' they send a provenance link."
Outcomes … Clear authority in developer ecosystems
- For developers: it is easy to see which library is the official client.
- For RelayKit: their SDKs become more trustworthy, easier to defend.
- For partners: they can reference "provenance-backed official SDK" in integration docs.
"We always knew which SDK was ours. With Mirror, registries and partners know too."
Product tie-in … Why this is Mirror, not just "use Git properly"
Mirror goes beyond Git commit history, conventional tags. Mirror provides release-level manifests and hashes, external anchors, public provenance pages, a stable reference for marketplaces, legal teams, and developers. It's a trust layer on top of standard dev workflows.
If your SDK is your handshake with the world, Mirror makes sure that handshake is verifiable.
Make your official SDK cryptographically official.
Mirror turns every release into a verifiable reference package.
Why this matters now
Cases like this are emerging because AI, synthetic media, and global information flows have made provenance a necessity rather than a luxury. When it's no longer obvious who made what, when, or why, stories like this become the norm.
The Genesis Moment explains the broader context for this kind of provenance work. Read Genesis.
Work like this, when implemented on the SOVEREIGN\PROVENANCE platform, is governed by The Covenant of Restraint, our ethical framework for how we build and deploy provenance systems.
Governed by The Covenant of Restraint, aligned with our Mission & Vision, and grounded in the Genesis Moment.