[DIS] RIVET: Decentralized GitHub Backup, Timestamping and Restore on CKB

https://dao.ckb.community/thread/vot-rivet-decentralized-github-backup-timestamping-and-restore-on-ckb-80044

2. Summary

Rivet is a decentralized developer platform that backs up, timestamps, and restores GitHub history using CKB, IPFS, and Arweave. V1 is live on testnet with CCC wallet onboarding, a functional backup engine, 1 click restore, and public developer profiles. The testnet currently runs on free tier hosting.

This proposal requests a grant of $5,000 for Phase 1 of development, covering CoTA frictionless onboarding, the Sovereign Passport (RGB++ Spore DOB), and the production release of the Rivet CLI restore tooling. A follow up proposal will be submitted later for Phase 2, which covers CKB Mainnet deployment, migration to a dedicated domain and VPS hosting, production infrastructure, and audit preparation.

Grant Amount Requested (Phase 1): $5,000
ETA to Completion of Phase 1: 8 weeks from grant approval
CKB Wallet or Funding Address: ckb1qyqvx63t4e0zjk56lldkre9w0225dmuthneq7texcs
Live Demo: https://rivet-web-ten.vercel.app

3. Project Introduction

What problem are you solving?

Developers build their careers, reputations, and open source contributions on platforms they do not control. GitHub can suspend an account overnight with no real appeal process, erasing years of work. If a developer loses access to their account for any reason (suspension, hack, forgotten password, or loss of an old email), they also lose their contribution graph and their proof of authorship. Git commit timestamps are trivially easy to forge, and there is no native cryptographic proof that a specific developer wrote a specific piece of code at a specific time.

What ecosystem or user need does this address?

There are millions of developers worldwide who depend on GitHub as the primary record of their professional work. Every one of them is exposed to the risk of losing that record without warning. Rivet gives developers a decentralized insurance policy. It mirrors their entire repository history to IPFS and Arweave, anchors a cryptographic proof of that history to a CKB Cell, and issues a Sovereign Passport (RGB++ Spore DOB) that proves their developer identity on chain. If anything happens to their account, they can restore everything to a new account with the original history intact.

Why now?

Centralized platforms are becoming less reliable and more censorious. At the same time, CKB’s tooling has matured to the point where this product can be built properly. CCC provides seamless wallet authentication, RGB++ enables Bitcoin bound asset ownership, CoTA enables account abstraction for frictionless onboarding, and Spore DOBs allow for flexible on chain identity. This is the right moment to give developers a real, practical, decentralized alternative for preserving their work.

4. Team and Roles

Name / Handle: Jedi Dtechmaker (jedi_dtechmaker)

Role: Lead Developer, Product Designer, and Project Manager

Experience / Relevant Background:

I am a full stack and Web3 developer with hands on experience across TypeScript, Solidity, JavaScript, Node.js, Go, Rust, Python, and PHP. I have worked extensively with the CKB ecosystem, including CCC for wallet integration and transaction signing, RGB++ for Bitcoin bound assets, and Fiber Network for Layer 2 payments. I am building Rivet because I have personally experienced the frustration of platform dependence and want to give developers a permanent, cryptographically verifiable home for their work.

Links:
GitHub: jedi-dtechmaker (Jedi Dtechmaker) · GitHub
Twitter/X: @jedi_dtechmaker

5. Current Status

Research completed:
Studied existing backup tools (Octarchive, GitPreserver, Vector migrate) and identified their limitations. Researched CKB Cell capacity costs, RGB++ Spore DOB mechanics, CoTA account abstraction, and CCC integration patterns. Defined the two mode restore architecture (Exact Restore versus Attribution Restore) after community feedback.

Prototype and MVP status:

V1 is live on testnet and functional. The web platform is deployed on Vercel and uses GitHub Actions as the backup worker. The CKB anchoring logic is running on testnet with a public verifier page.

What is live and working in V1 (testnet):
GitHub OAuth sign in with one click repo import.
Wallet connect via CCC (JoyID, MetaMask, UniSat). Optional, not required for backups.
Full mirror backup: every branch, tag and commit, dispatched to a GitHub Actions worker.
Merkle root computed over the entire commit history and anchored in a CKB testnet cell, verifiable on chain.
Git bundle pinned to IPFS via Pinata.
Proof panel on every repo with a direct CKB Explorer link.
1 Click Restore on the web: rehydrate a repo with full commit attribution intact.
Auto sync: every git push triggers a fresh backup via GitHub webhook.
Public verify page to look up any proof by CKB tx hash, IPFS CID, or GitHub repo ID.
Public developer profiles, file tree browser, commit history, and README badge generator.
Fully responsive UI with dark mode.

Privacy note for testnet:
Because Rivet is currently serverless, backups run through a public GitHub Actions queue. Private repo names and their IPFS CIDs appear in public logs. AES 256 encryption for private repos is in development. For now, users are advised to back up only public repositories. This is a temporary testnet constraint and will not exist on Mainnet.

Hosting note for testnet:
The platform is currently deployed on Vercel free tier and depends on GitHub Actions for the backup worker. Phase 2 will migrate Rivet to its own dedicated domain and a production VPS, removing the public GitHub Actions dependency entirely and enabling private repository support.

What Phase 1 of this grant will fund:
CoTA frictionless onboarding, the Sovereign Passport, and the production release of the Rivet CLI. A separate Phase 2 proposal will cover CKB Mainnet deployment, dedicated domain and VPS hosting, and production infrastructure.

Community discussion:
I posted the project on CKBuilders Review group and Talknervos and received detailed technical feedback. The key points raised were: separating Exact Restore from Attribution Restore, rewording the timestamp claim to prove repository state existed by a certain block height rather than proving git timestamps themselves, and using CoTA for frictionless onboarding so users never buy CKB. All of these have been incorporated into the design.

6. Application Design

6.1 Functional Overview

Rivet has two interfaces that share the same core engine: a web dashboard for easy onboarding and profile management, and a CLI for developers who want to automate, script, or run restores directly from their terminal.

Web dashboard flow:
A developer signs in with GitHub OAuth. No wallet is required to start. On first backup, a JoyID burner wallet is created silently in the background using WebAuthn and passkeys. Rivet subsidizes the approximately 150 CKB needed to create the user CoTA cell. The developer’s identity and backup proof are stored in a single CoTA Sparse Merkle Tree, compressed into one 32 byte hash on chain.

Rivet then clones the repositories using git clone --mirror, generates a Merkle Tree from the commit hashes, pins the bundle to IPFS via Pinata, and anchors the Merkle root to a CKB Cell. The developer receives a Sovereign Passport (RGB++ Spore DOB) that represents their on chain developer identity.

CLI flow:
The Rivet CLI is a cross platform binary for Linux, macOS, and Windows. Developers can run it locally or inside a CI/CD pipeline.

  • rivet backup <repo> triggers a mirror backup and prints the CKB tx hash and IPFS CID.
  • rivet status <repo> shows the latest anchored proof and block height.
  • rivet verify <tx_hash> independently verifies a proof against CKB and IPFS.
  • rivet restore <repo> --mode exact or --mode attribution performs a full local restore, using git-filter-repo for attribution mode and anchoring a signed hash mapping proof on CKB.
  • rivet watch <dir> monitors a local repository and triggers a backup on every push.

If the developer ever loses access to their GitHub account, they run the Rivet CLI restore command. They choose between Exact Restore (which preserves original commit hashes and the Merkle proof) or Attribution Restore (which remaps old emails to a new email so the contribution graph lights up). Their repositories are pushed to the new account with full history intact, entirely from the terminal.

On chain: CKB Cell storing Merkle roots, RGB++ Spore DOB for identity, CoTA Sparse Merkle Tree for compressed identity storage.
Off chain: Git bundles, IPFS and Arweave storage, PostgreSQL metadata, Next.js frontend, GitHub Actions worker, Rivet CLI.

6.2 Architecture and Design

Smart Contracts and Scripts:
CKB Timestamp Cell script for anchoring Merkle roots.
RGB++ Spore DOB script for the Sovereign Passport.
CoTA Sparse Merkle Tree for compressed identity storage.

Key CKB Features Used:
CCC (@ckb-ccc/core and @ckb-ccc/connector-react) for wallet auth and transaction signing.
CKB Cell model for immutable, decentralized storage of Merkle proofs.
RGB++ for Bitcoin bound asset ownership of the Sovereign Passport.
CoTA for account abstraction and frictionless onboarding.
Spore Protocol for flexible on chain developer identity.

External Dependencies:
IPFS (Pinata) for hot storage.
Arweave for permanent cold storage.
GitHub Actions for backup worker (testnet only, to be replaced in Phase 2).
GitHub OAuth for repository access.

CLI Stack:
Rust or Node.js single binary distribution. git2 or isomorphic-git for local git operations. @ckb-ccc/core for CKB transaction signing.

All core scripts will be open sourced. The full codebase will be publicly available on GitHub.

6.3 Design Rationale

Trade offs considered:
Storing every commit hash on chain would be prohibitively expensive. I use Merkle trees to anchor a single root that represents thousands of commits. This keeps CKB capacity costs low while preserving cryptographic verifiability. For restore, I separate Exact Restore from Attribution Restore because rewriting Git history changes commit hashes, which would break the link to the anchored Merkle root. Exact Restore preserves cryptographic integrity. Attribution Restore offers a signed mapping proof anchored on CKB so the proof chain remains verifiable even after email remapping. For onboarding, I use CoTA because it compresses an entire user dataset into a single 32 byte hash on chain, which makes it viable to subsidize user onboarding and give Web2 developers a seamless experience. The CLI exists because developers need a local, scriptable tool, not just a web UI.

Security considerations:
The Merkle root anchored on CKB proves that a specific repository state existed by a certain CKB block height. It does not prove that the internal git commit timestamps are truthful. I am transparent about this distinction in all UI messaging, CLI output, and documentation.

Alignment with CKB philosophy:
CKB is designed for decentralized state verification and true ownership. Rivet uses CKB exactly as intended: as a permanent, uncensorable notary for developer owned data.

6.4 Fee Model and Sustainability

Rivet will be free for individual developers for basic backup and restore. A premium tier will offer larger storage quotas, private repository backups, priority IPFS pinning, and team features. A small fee will be charged for Arweave permanent storage. Sovereign Passport minting will carry a nominal CKB fee.

Additional revenue streams include B2B API access for credential verification by recruiters and HR platforms, protocol level fees on on chain bounty payments using a Sovereign Passport as escrow, and cryptoeconomic storage staking where node operators stake CKB to guarantee long term repository pinning.

As the user base grows, the platform can sustain itself through these premium features without compromising the free core.

7. Key Benefits for CKB

Network growth: Every backup anchors a transaction on CKB, driving real on chain activity from developers who would not otherwise interact with the network.
Addressing a need: Provides a concrete, practical use case for CKB that solves a real problem for developers worldwide.
Developer tooling: Demonstrates the power of CCC, RGB++, CoTA, and Spore in a production grade application, and ships a cross platform CLI that any developer can install and use immediately.
Community engagement: Onboards Web2 developers into the CKB ecosystem through a tool they actually need.
Interoperability: Uses RGB++ to bind developer identity to Bitcoin, showcasing CKB’s unique position as a Bitcoin Layer 2.

8. Detailed Deliverables and Milestones (Phase 1)

This proposal funds Phase 1 only. Phase 2 will be proposed separately.

Milestone Deliverable(s) Timeline Budget
Milestone 1: CoTA Onboarding and Sovereign Passport CoTA account abstraction integration, JoyID burner wallet creation flow, Rivet subsidized CoTA cell creation, RGB++ Spore DOB minting, public profile integration. Acceptance: end to end onboarding and passport minting live on testnet. Weeks 1 to 4 $2,500
Milestone 2: CLI Restore Tooling and Hardening Cross platform CLI for Linux, macOS, and Windows. Exact and Attribution restore modes, git-filter-repo integration, rivet backup, rivet status, rivet verify, and rivet restore commands. Robust RPC error handling, Auto Sync reliability. Acceptance: CLI published and restore flow verifiable on testnet. Weeks 5 to 8 $2,500

Total Budget for Phase 1: $5,000

9. Budget Breakdown (Phase 1)

Deliverable Budget
Milestone 1: CoTA Onboarding and Sovereign Passport $2,500
Milestone 2: CLI Restore Tooling and Hardening $2,500
Total $5,000

What each milestone covers:

Milestone 1 ($2,500): CoTA Onboarding and Sovereign Passport

  • CoTA account abstraction integration
  • JoyID burner wallet creation flow using WebAuthn and passkeys
  • Rivet subsidized CoTA cell creation (approx. 150 CKB per user)
  • RGB++ Spore DOB minting for the Sovereign Passport
  • Public profile integration to display the passport
  • End to end testing on testnet

Milestone 2 ($2,500): CLI Restore Tooling and Hardening

  • Cross platform CLI binary for Linux, macOS, and Windows
  • Exact and Attribution restore modes
  • git-filter-repo integration for email remapping
  • rivet backup, rivet status, rivet verify, and rivet restore commands
  • Robust RPC error handling and retry logic
  • Auto Sync reliability improvements
  • CLI documentation and usage guide

Infrastructure costs (premium IPFS pinning, production VPS) and audit costs are excluded. They belong to Phase 2.

Payment Schedule:

  • Upfront (50%): $2,500 released upon proposal approval.
  • Upon Completion (50%): $2,500 released after both Phase 1 milestones are delivered and verifiable on testnet.

10. Out of Scope and Future Funding Needs

This proposal covers Phase 1 only. The following items will be addressed in a separate Phase 2 funding request once Phase 1 milestones are delivered:

  • CKB Mainnet deployment: Migrating the anchor layer from testnet to Mainnet.
  • Dedicated domain and VPS hosting: Moving Rivet off Vercel free tier onto its own domain and a production VPS. This removes the dependency on public GitHub Actions for the backup worker and enables private repository support with AES 256 encryption before IPFS upload.
  • Production infrastructure: Premium IPFS pinning, production VPS for cron jobs and the verifier indexer.
  • Security review: Formal third party audit of the CKB scripts and CoTA integration.
  • Long term maintenance: Ongoing IPFS pinning costs and infrastructure scaling.

The Phase 2 proposal will be submitted only after Phase 1 deliverables are complete and verifiable on testnet.

11. Risk and Mitigation

Risk Mitigation
Technical complexity of Merkle proof and restore flow Phased approach with working V1 already live on testnet, open source code, and community feedback at every milestone
Solo developer resource constraints Clear milestones, realistic scope for Phase 1, and active community support
Dependencies on external protocols (IPFS, Arweave) Redundant storage, fallback to local downloads, and monitoring
Community adoption challenges Free tier, CoTA frictionless onboarding so no CKB purchase is required, cross platform CLI for power users, README badge, GitHub Action, and a public demo showing backup, delete, restore, and verify
CoTA subsidy economics Monitor user acquisition cost per onboarded developer. Premium tier revenue must cover subsidy before scaling
Phase 2 funding not approved Phase 1 deliverables are self contained and usable on testnet. If Phase 2 is delayed, the project still functions for testing and community use

12. Closing and Call to Action

Rivet is a practical, developer first tool that brings real utility to CKB. This proposal funds Phase 1, which covers the CoTA onboarding and Sovereign Passport that make the product accessible to non crypto developers, plus the production release of the Rivet CLI that makes the core promise of backup, verify, and restore real for developers who work in the terminal. A Phase 2 proposal will follow for Mainnet deployment, dedicated domain and VPS hosting, and audit preparation. I appreciate your consideration and welcome any feedback or questions from the community.

13. Supporting Links

GitHub Repo: GitHub - jedi-dtechmaker/Rivet · GitHub
Live Demo: https://rivet-web-ten.vercel.app
Architecture Doc: Rivet/docs/ARCHITECTURE.md at main · jedi-dtechmaker/Rivet · GitHub

33 Likes

This is a really amazing application of CKB.

Well done, Ma’am

3 Likes

This is great.

2 Likes

There’s a real problem underneath it, but the blockchain-heavy execution adds more complexity than value.

A few questions before I’d feel good about Phase 1 funding:

  1. Given git is already distributed, the core new value here seems to be the on-chain notarization + one-command restore/reputation portability. Have you looked at how this compares to something like OpenTimestamps, and what CKB specifically buys you over that?
  2. The testnet privacy note is a bit concerning — private repo names and IPFS CIDs leaking into public GitHub Actions logs. Is there a stopgap before Phase 2 (e.g. warning users more prominently, or gating private repo backup entirely) so this doesn’t bite an early adopter?
  3. For the Sovereign Passport/identity angle to matter, someone (recruiters, other devs, platforms) needs to actually check it. Is there a plan for that adoption path?
3 Likes

Thank you chief.

1 Like

Thank you boss :upside_down_face::upside_down_face:

2 Likes

Thanks for the questions. Let me answer each quickly and as best as I can.

1. OpenTimestamps vs Rivet

OTS is a timestamping tool. It proves a hash existed at a certain time, but it does not back up your code, restore your repository, or give you an identity. Rivet stores the full Git bundle on IPFS, anchors a Merkle root of the entire commit history on CKB, and provides a one-command restore to a new account with original timestamps and authorship intact. CKB adds a stateful cell model, so the proof can be composed with other scripts, like the RGB++ Spore DOB that acts as your Sovereign Passport. OTS proofs cannot do that.

2. Testnet privacy stopgap

You are right to flag it. Tho like I stated earlier This is temporary,

but here are things I will do during Phase 1, not wait for Phase 2:

· Gate private repo backups entirely on testnet. The option will be disabled with a clear explanation.

· Add a prominent warning on the backup screen if a private repo is selected.

· Update the docs to state the limitation clearly.

Phase 2 fixes it properly with AES 256 encryption and a dedicated VPS worker, removing the public GitHub Actions dependency.

3. Passport adoption path

Start with developers, not recruiters. The CLI and verifier page give developers a shareable proof link and a README badge they can put on their repos. That drives organic exposure. Recruiters and HR platforms come later via the B2B API once there is a critical mass. The first people who will actually check a passport are other CKB developers, and that is fine. It proves the mechanism works in a community that already understands on-chain verification.

I would rather hear pushback now than after Phase 1. The privacy fix happens regardless of funding.

7 Likes

:counterclockwise_arrows_button: DAO Proposal Sync (Discussion Phase)

This proposal reached 33 likes within the 7-day discussion window and is eligible to proceed to the Metaforo voting stage.

During the window, some community members raised a concern about these likes, so I reviewed them on the final data at the close of the window. No duplicate accounts were found, and all 33 likes stand. Seven of the likes came from accounts created during the window whose only activity has been liking the author’s posts. The full review note follows.


Like Audit: Proposal at [DIS] RIVET: Decentralized GitHub Backup, Timestamping and Restore on CKB

Prepared by: @zz_tovarishch DAO Coordinator
Date: 2026-09-30
Subject: Verification of the 33 likes on the first post of the proposal


1. Background

Some community members raised a concern about the likes on this proposal while its discussion window was still open. As the DAO coordinator, I reviewed the likes using forum administrative data, following the same method as the earlier audit of t/10453. The window closed on 2026-09-29 at 15:53 UTC, and this note uses the final data at that point.

Accounts are identified by their numeric forum user ID. Usernames, email addresses, IP addresses and device details are withheld to avoid exposing personal data and to keep the assessment free of identity bias.

2. Headline finding

The first post had 33 likes when the discussion window closed, and none were added afterward. The review found no evidence that any two of the liking accounts are operated by the same person. It did find 7 accounts that were created after the proposal was published and whose only activity on the forum is liking the author’s posts. Whether these 7 accounts belong to one person or to several people invited by the author cannot be established from forum data.

The remaining 26 likes show no signs of concern. They include long-standing community members.

3. Method and data sources

The review used the same administrative records as t/10453: account creation time, registration IP, last-seen IP, trust level and activity metrics. Two sources were added. The first is the IP address of every recorded login session, which gives a fuller network history than the registration and last-seen snapshots. Because Discourse overwrites a session’s IP address when it refreshes the session, these were collected twice, on 2026-09-28 and again after the window closed, and both sets were compared. The second is each account’s complete like history with timestamps. Discourse’s own similar-user count, which flags accounts sharing an IP address, was also checked. User IDs are issued strictly in registration order.

4. Evidence

4.1 No shared network identity

Across all 33 liking accounts and the author’s account, and across every recorded login session in both collections (117 distinct IP addresses), no IP address is shared by any two accounts. Discourse’s similar-user count links none of them to one another. The author’s IP addresses carry no other forum account. This is the decisive difference from t/10453, where the proposal author’s own account shared an IP address with eight of the liking accounts.

4.2 Seven single-purpose accounts

All seven registered between 2026-09-23 and 2026-09-26, after the proposal was published on 2026-09-22. Each liked the proposal within minutes of registering, and every like any of them has given on the forum went to the author’s posts. None has posted, and total reading time ranges from 7 seconds to about 3 minutes.

User ID Registered (UTC) Registration to like Likes given in total Of which on the author’s posts Total read time Days visited
4472 2026-09-23 12:30 41 min 2 2 ~3 min 1
4478 2026-09-23 20:15 19 s 1 1 7 s 1
4482 2026-09-24 17:00 ~2 min 1 1 13 s 1
4483 2026-09-24 18:19 ~6 min 4 4 ~2 min 3
4485 2026-09-25 17:29 ~6 min 2 2 ~2 min 1
4489 2026-09-26 08:34 51 s 1 1 ~2 min 1
4490 2026-09-26 08:40 ~2 min 1 1 40 s 2

Account 4472’s first like, 29 seconds after it registered, went to the author’s earlier topic on the same project.

4.3 What the evidence does not show

The seven accounts use a different IP address in every session, spread across three mobile carriers and four days. The author also switches between carriers, so this spread fits either one person using several SIM cards or several different people. One of the seven (4478) uses the same uncommon desktop configuration as one of the author’s sessions, but a device type is not an identifier and the IP addresses differ. Some of the seven fall in the same carrier address blocks as the author. On shared mobile networks this indicates at most that they are in the same area.

4.4 Context

The same behavior appears elsewhere in the same registration window. Among accounts created between 2026-09-21 and 2026-09-27, several others registered and then liked a single proposal, and those proposals belong to other authors. Registering in order to support one proposal is therefore not specific to this proposal. This observation is context only and is not a review of those proposals (see Section 7).

5. Assessment against prior practice

The prior practice this DAO relies on comes from Growing the Italian ecosystem (talk.nervos.org/t/growing-the-italian-ecosystem/7707).

The element that justified removal there was one person liking through several accounts. That element is not established here.

In the audit of t/10453, seven accounts without a direct IP link were also excluded. They were excluded because their user IDs sat inside an unbroken registration run together with accounts already tied to the author by shared IP, so they belonged to an operation whose single operator had been shown. Here no operator has been shown, and the seven accounts are interleaved with unrelated new accounts that liked other proposals. The inference that supported the earlier exclusion is not available.

Excluding these seven likes would therefore mean treating newly created, single-purpose accounts as ineligible to like. That would be a new standard rather than an application of prior practice.

6. Conclusion

The DAO’s metarules contain no provision on who may like a proposal during the discussion phase, the coordinator holds no authority to invalidate support by fiat, and the prior practice does not reach these accounts. The seven likes are therefore not removed. The count for the discussion-phase threshold remains 33, and the proposal is eligible to proceed to the Metaforo voting stage.

Whether likes from accounts created only to support a proposal should count toward the threshold is a question the metarules do not currently answer. If the DAO wants such a rule, for example a minimum account age or level of activity for a like to count, it should be adopted through the normal process and applied to all proposals going forward rather than to this proposal alone.

7. Scope of this review

As with the audit of t/10453, this review was triggered only because a specific concern was raised while the proposal was live. It creates no standing audit, places no obligation on the coordinator to review other proposals, and does not reopen proposals whose discussion windows have already closed.

8. Availability of the evidence

The complete underlying records are held by the coordinator and are independently visible to forum administrators through the forum’s admin tools. Any DAO member may request to review the basis for this note and will receive the pseudonymized evidence record in the same form as this note. Raw personal data such as email addresses, IP addresses and device details is not redistributed. Where a member wants those values confirmed, forum administrators can do so directly.

5 Likes

Please if you are a DAO member please Vote for me https://dao.ckb.community/thread/vot-rivet-decentralized-github-backup-timestamping-and-restore-on-ckb-80044 :folded_hands: :folded_hands:

1 Like