Hey folks,
I‘m not sure if this topic has been brought up before but it seems to me a low hanging fruit which could be implemented easily…
Think about badges like the GH ones for Arctic Vault and others. There could be one for Seed Node operator, Early Adopter, and much more and every badge could be a NFT that could be minted on a ERC721 contract and displayed in Upstream and Web App in the user profile.
Feel free to provide feedback or ideas.
Cheers!
Yeah that’s a cool idea!
Some of us were also thinking of using non-fungibles for proofs of contribution (e.g. I contributed to radicle-upstream). In that scenario when code is anchored, if you contributed to that release, you are sent an ERC721 that is visible on the UI and proves your contribution. cc @Julien @cloudhead
Yep, I like this idea a lot. Made an issue to explore it.
Yeah that sounds great @lftherios! With the anchoring event this should be something that could be implemented fast.
Eventually one thing we would have to discuss is how or better who would mint the ERC721 tokens… we could deploy a ERC721 contract by Radicle or use some of the already known platforms…
IMO I think following the vision of Radicle, I would suggest that this could be something that could play nice with Orgs. Allowing every org to manage their own ERC721 and awarding the contributors or investors, etc.
@brandonhaslegs made some design explorations: User badges · Issue #2234 · radicle-dev/radicle-upstream · GitHub
It’s mixing some upstream specific badges (like shortcut wizard) with ideas around NFT based ones, which would be what you’re describing in the thread here.
Upstream specific badges pose a problem with where to store these since there’s no server. Right now most of these things are stored in your local storage, but then I think others might not be able to see these and also what happens when you wipe your local storage.
NFT based one don’t have the issue of storage since they would live on the blockchain, but how close are we to see when someone has contributed on anchor?
Some easier ones that came to mind were:
Obviously just brainstorming here
@alexgood Wonder if this is something we could use collaborative objects for. Like is there any other way to transfer profile data between peers without using Ethereum? I guess I’m just wondering the extent that collaborative objects can be used for … if it can be used for more than just issues and patches. Can it also be used to store and replicate profile info?
It absolutely is something that we could use collaborative objects for and I’ve been thinking a bit about how we could manage it. Collaborative objects have an associated object ID (derived from the commit which creates the object). Furthermore, collaborative objects live within a particular identity (project or person), that means they are replicated with that identity and logic around who is allowed to make changes to an object is executed based on that identity. For the case of Person identities the logic is that only direct delegates of the Person may make changes i.e. devices belonging to the person.
This gives us most of the ingredients we need. The last bit would be linking a particular collaborative object to the profile of the user, i.e. applications need a way of knowing the ID of the object which contains the profile information. This could probably be accomplished via an extension to the payload of the Person identity.