RIVET: CKB-native GitHub backup using IPFS, RGB++, and CCC

Hello everyone, :waving_hand:

I am building RIVET, a decentralized developer platform that backs up, timestamps, and restores your entire GitHub history using CKB, IPFS, and RGB++.

Developers currently build their entire careers and reputations on platforms they do not actually control. This is not just about suspensions. It is about hacks, lost passwords, losing access to an old email, or sudden policy changes. Rivet ensures that no matter what happens, your code, commit history, and proof of authorship are permanently secured, cryptographically provable, and fully restorable.

The Problem

Developers rent their reputation on Web2 platforms:

· GitHub can suspend your account overnight, deleting years of open source contributions with no appeal process.

· There is no native cryptographic proof of authorship. Git commits and timestamps are trivially easy to forge.

· If you lose your account for any reason, you lose your contribution graph and your proof of work.

Rivet fixes this by providing an insurance policy for your code, built natively on CKB.

What Rivet Is

A decentralized backup and identity platform that:

· Mirrors your entire GitHub history (every branch, tag, and commit) to IPFS and Arweave.

· Anchors a cryptographic proof (Merkle root) to a CKB Cell for immutable timestamping.

· Issues a Sovereign Passport (an RGB++ Spore DOB) that proves your developer identity and history on chain.

· Allows you to restore all your repositories to a brand new GitHub account, perfectly preserving your original commit timestamps and authorship.

How It Works

· Data Layer: git clone --mirror creates full backup bundles.

· Storage Layer: Bundles are uploaded to IPFS (via Helia) for hot access, and eventually Arweave for permanent cold storage.

· Proof Layer: A Merkle tree is computed from your commit hashes.

· Anchor Layer: The Merkle root is submitted to CKB as a Timestamp Cell.

· Application Layer: A Next.js UI allows you to browse your backed up code, diffs, and commits seamlessly.

Why CKB Shapes the Design

Everything in Rivet relies on CKB’s unique architecture:

· Timestamp Cells: We use CKB’s Cell model to store Merkle roots. Because Cells are immutable once confirmed, they provide absolute proof that a specific codebase existed at a specific time.

· Spore DOBs (RGB++): Your Sovereign Passport is implemented as a Spore DOB. It is an on chain resume containing your total commits, languages, and backup history that you actually own.

· CCC Integration: We use @ckb-cccckb-cccckb-cccckb-ccc/co@ckb-cccckb-ccce and @ckb-ccc/connector-react for passwordless authentication and transaction signing. Your wallet is your developer account.

Current Status (POC Phase)

What is Working:

· Next.js Web Platform.

What is Not Yet Done:

· CCC Wallet connection and passwordless authentication.

· GitHub OAuth integration to fetch repositories.

· Native file tree browser and commit history viewer (reading original timestamps)

· PostgreSQL database schema mapping users to CKB addresses

· Git bundle generation and IPFS uploading

· Merkle root computation and CKB transaction building

· RGB++ Spore DOB minting

· CLI Restore tool (for pushing back to GitHub)

Tech Stack

Layer Technology

Runtime Node.js + Fastify

Frontend Next.js 14 + React 1@ckb-cccckb-ccc

Blockchain @ckb-ccc/core + RGB++ Spore Protocol

Storage IPFS (Helia) + Arweave

Database PostgreSQL

Git Engine isomorphic-git

Key Design Decisions

Decision Reasoning

CCC Wallet Auth No passwords. Your CKB address is your permanent identity.

Next.js (SSR) Public developer profiles need to be SEO friendly so recruiters and auditors can index them.

IPFS + Arweave IPFS provides fast retrieval for the web UI. Arweave acts as a permanent insurance layer.

Merkle Trees Instead of storing thousands of commit hashes on chain (too expensive), we anchor a single Merkle root.

Features Planned for v1

The Sovereign Passport

Mint an RGB++ Spore DOB that updates with every backup. It acts as an on chain, verifiable resume that third parties can cryptographically verify.

The Restore Wizard

If you lose access to your GitHub for any reason, the Restore Wizard downloads your IPFS bundle, uses git-filter-repo to remap your old emails to a new one, and pushes everything to a new GitHub account. Your contribution graph lights up exactly as it was, with historical dates intact.

Public Verifier

A dedicated page where auditors or employers can paste a CKB transaction hash and cryptographically verify that a developer’s claimed code history is mathematically genuine.

Fiber Payments (Future)

Once the identity layer is established, Fiber Network will route bounty and sponsorship payments directly to the developer’s new account, using their RGB++ Passport as the escrow proof.

Build Order

· Phase 1: Foundation (Current): Web UI, CCC auth, GitHub repo viewer.

· Phase 2: Backup Engine: Git mirroring, IPFS storage, CKB Merkle anchoring.

· Phase 3: Sovereign Passport: Spore DOB minting and public profiles.

· Phase 4: Restore CLI: Email remapping and GitHub push automation.

· Phase 5: Social Features: Stars, forks, code search, and discovery.

Questions for the Community

1. As a developer, would a decentralized backup for your GitHub history give you peace of mind?

2. What features would you consider essential for the v1 Restore process?

3. CKB Capacity: I plan to batch multiple repositories into a single Merkle tree to save on CKB capacity when anchoring. Has anyone established best practices for batching proofs in Timestamp Cells?

4. Spore DOBs: Any concerns with constantly updating a Spore DOB with new backup stats? Is it better to mint a new DOB per year, or continually mutate one?

Links

Temporary Live Demo (Vercel): DEMO

Architecture Doc: Rivet/docs/ARCHITECTURE.md at main · jedi-dtechmaker/Rivet · GitHub

Looking for feedback. Thanks for reading!

7 Likes

very impressive !

1 Like

Good Idea!
I think that besides Git, there are many other areas where similar functionality is needed.

Do you think the current on-chain script fully meets your needs, or does the ideal scenario require developing an new on-chain script?

2 Likes

Thank you!

And good question. The current POC uses a standard CKB Cell with a basic lock to store the Merkle root. It works for testing, but for production I do think we need a custom Type Script for two reasons: a standard cell can be spent by the owner, so the proof is not truly immutable unless it is burned to an unspendable lock. And without a custom script, there is no standard data format, which makes independent verification harder.

That said, I do not want to over engineer it too early. My plan is to ship the Mainnet version with the simple cell first, prove the end to end flow works, and then build the custom script once the verifier requirements are clearer.

Would love to hear if you have a specific use case in mind beyond Git. That would help me decide how general purpose the script should be from the start.

1 Like

For instance, in the case of certain commercial contracts, it serves to prove that the contract actually became effective (or was signed) at specific points in time.
Of course, there are other methods—such as email—but the cost of forging something placed on-chain is prohibitively high.

1 Like

That makes sense. It’s the same core primitive: prove something existed at a specific time. Email can’t do that reliably, but an on chain anchor can.

Do you think a general purpose version should support revocation, or is immutability the whole point for contracts too?