Nice work getting a working demo on testnet. Backup with a restore path is a real gap, and splitting restore into Exact and Attribution modes is the right call. Two technical points:
1. Anchoring for the deletion case. If GitHub deletes the repo, the anchor is the only independent reference left. What matters then is: does the restored copy match what was backed up? Anchoring a hash of the sorted refs and their tip commits answers that directly. After restore, anyone can recompute it from the bundle with plain git and compare it to the cell, with no GitHub and no Rivet server involved. Most repos are still SHA-1, so I’d also anchor a SHA-256 of the bundle itself. That lets the copy retrieved from IPFS or Arweave be checked byte for byte before restoring.
2. Cell lifecycle and cost per push. With auto-sync on every push, do you consume the previous anchor cell into the new one, or create a fresh cell each time? Consuming and replacing keeps locked capacity flat, and the transaction chain becomes the version history for free. Creating new cells makes the subsidy grow with activity. This is the model I use in VeriCell.net (disclosure: I build it). Each new version consumes the previous live cell, so the live cell always shows the current state and older versions stay verifiable as consumed cells. Happy to compare notes if a shared manifest or verification format makes sense.
Good luck with the vote.