Update Repo Ownership Flow

[brandonhaslegs]

I have this project I used as a test on Mainnet (hehe i'm dumb) and would like to unlink it from me but there's no way to do that?

I deleted the FUNDING.json file from my repo and it's still there and associated with me. I even deleted the repo from GitHub and the project is still there and linked to me, now with a dead link. (Is this bad?)

[brandonhaslegs]

I guess we need some sort of state for the project on Drips when this happens. The project has to stay there, because if it ever received funds, it'd need to have a page in the app. But if the repo is deleted or the FUNDING.json is removed or the repo is transferred to another GitHub user, we need some kind of note on the project page that says this.

[jtourkos]

The moment you finish the claiming process, the project is claimed on-chain. So, deleting the FUNDING.json or the repo doesn't change the state on-chain. This is why you still see it as claimed.

Currently, users cannot re-claim a project, but this is at the app level. We could allow it, allowing the user to change its owner.

Completely removing the ownership, after at least one assigned owner, I'm not sure this can even be done. As far as I know, the contract always sets an owner -- after verifying them via the FUNDING.json file. (it can, see @CodeSandwich reply below)

Somehow related: We do have a project status but it doesn't have a Deleted value because of the above.

export enum ProjectVerificationStatus {
  Claimed = 'Claimed',
  OwnerUpdateRequested = 'OwnerUpdateRequested',
  OwnerUpdated = 'OwnerUpdated',
  Unclaimed = 'Unclaimed',
  PendingOwner = 'PendingOwner',
  PendingMetadata = 'PendingMetadata',
}

I wonder if we could add logic to the app to somehow communicate this, though. For example, just verifying that the FUNDING.json is still there 🤔 (Nothing would change on chain of course).

[efstajas]

Yeah, we need a process for this. I think one option could be a new "disassociate / delete project" flow in the app that asks you to commit a new FUNDING.json with a null address, and then re-verifies. That would effectively undo the link. Then we just start interpreting 0-address-owned projects as "unclaimed", and effectively we get this functionality. The 0-address FUNDING.json could be deleted after the process is done.

I think for now what's more important though would be a proper flow for updating the owner address of a repo without resetting splits etc.

[CodeSandwich]

From the on-chain perspective, as long as the oracle can't find the repo, the JSON or the proper field, the field value isn't an address, or is zero address, the owner of the account is set to zero address. This change in the repo will only be noticed by the smart contract when somebody requests it to update the owner of the repo account.

In order to delete the project or disconnect it, the app must ask the user to do one of the above, and then request the contract to do the ownership update.

[evvvritt]

Could we not simply mark as deleted/hidden in our backend and our app will hide it everywhere? (So not requiring the user to submit a tx / reverify... I think it's expected a user might delete a repo)

[gh0stwheel]

Hey - interesting conversation! It's good to start thinking about these edge cases.

I want to add a couple of additional considerations:

• Whatever solution we should come up with should enable some kind of historical view, so that it's clear to users what happened in the past. This doesn't necessarily have to happen on the main project page. A couple examples of why this matters:
  • If a funder streams funds to a project and then the project maintainer later deletes that repo, or chooses to associate it with a different address, it should still be easy for everyone to understand what happened... so that, from a positive perspective, they can still see that the funds were donated. But also, in case the repo was originally claimed by someone else on the team (perhaps someone with commit rights, but not the repo owner), there is some kind of way to understand how much of the funds went to the first address and how much went to the 2nd address.
  • All of this also matters for taxes, both for the funders (in case the recipient is a 501.3c and they are looking to deduct their donation) and for recipients (in case there are multiple different recipient wallets associated with the repo over time, and the owners of those different wallets want to be able to easily show how much they actually received).

[brandonhaslegs]

Idea from Jason: 1) Your project keeps appearing with the old name in your projects (already the case) 2) funds split to the old project continue being split according to its split config (already the case) 3) it's still possible to visit the old project (not the case anymore since we're now calling the GitHub API to auto-correct the name) 4) You can re-claim the project under the new name (already the case) 5) Anyone entering either the old or new GitHub url into splits going forward gets auto-corrected to the new project (already the case)

[efstajas]

@brandonhaslegs that's about what happens when you rename your repo or transfer ownership on github, not unliking a project on Drips

[efstajas]

Using this task to track the general ability to update a repo's ownership via the Drips app. Needs design. We need high-level:

• A button (accessible for anyone with a connected wallet) on Project Profiles for kicking off a repo ownership update. Maybe hidden behind an overflow [...] button?
• The repo ownership update flow with new steps:
  1. Instructions for updating ownership (edit funding.json with new address)
  2. Check if ownership has changed by looking at the current funding.json on GitHub and display who will be the new owner (or that the repo will be unclaimed again), make the user confirm
  3. Call repo owner update (gasless)
  4. Success

[brandonhaslegs]

A button […] on Project Profiles

This wouldn't solve this because you can't view a deleted project profile