Allow CRUD of badges icons

[joelamouche]

Store badges in the backend and create api endpoints to CRUD badges and add badge ownership to know who has the right to edit a badge icon

For now this needs a bit more reflexion because badges are not owned yet so we would need to make them ownable in the blockchain, which is a bit complex because we don't want someone to monopolize an important badge skill. Kris suggested we make a token curated registry for this but this is also complex

[V-Vaal]

Reading the recent discussions around badges (#53, #64, #69, #145), I'm trying to step back and sanity-check how we're thinking about them.

With duplicate attestations being discussed (#145) and the idea of importing external EAS attestations (#53) I wonder if badges might eventually be less about a single "ownable" fact and more about a way to interpret and group multiple proofs of contribution.

If thats the direction we're exploring, then attestations would stay as the factual layer, while badges would sit more at an interpretation / UX level. In that case, editing badge icons could potentially be seen as an editorial or stewardship concern rather than a strict ownership problem (even though the monopolization concerns still matter).

I'm not proposing a solution here but just raising a framing question that might help connect a few open threads :

Are badges things we own, or things we compute and display based on attestations ?

Happy to hear other takes. I might be completely off here. ^^'

[joelamouche]

Very interesting proposition @V-Vaal !

Originally the idea was that people were gonna give each other badges. I was thinking typically you onboard your dev friends and you give them badges. So badges were not necessarily tied to contributions.

Also one advantage of giving people badges related to skills is that we could use that later as a CV/browser for skills.

But so far I have seen very little engagement on p2p badges and it seems what attracts members to the guild is the opportunity to contribute. That means that most of the badges were distributed by The Guild for contributions.

So you're right, maybe we should refactor or rethink the concept of badges. I'm gonna think about your proposal.

So for you if we separate attestations and badges, could you give example of what an attestation could represent and what a badge could represent? Attestations would be contributions and badges would be skills? Or attestations would be skills and badges would be contributions? Or badges could be events?

[V-Vaal]

That's where my thinking is currently going :

If I zoom out a bit, it feels like badges could evolve from a more "scout-style" model (pure human attribution) toward something more grounded in observable facts and proven skills without losing the original peer-recognition idea.

If we try to clearly separate attestations and badges, here's 1 way I"d see it :

• Attestations would represent atomic, factual statements. Things that happened or can be reasonably verified. For example : contributing to a PR, reviewing code, participating in an event or hackathon, claiming or being endorsed for a skill…,
  In that sense, attestations could cover contributions, skills or events, as long as they remain low level and factual.

• Badges would be higher level representations built on top of one or more attestations. They could be interpreted as skills, contribution profiles or event-related badges, depending on the use case.,

A natural extension of this would be to use attestations as criteria to unlock or evolve badges.
For instance, based on the number of contributions, their scope, reviews or activity over time.
Github already exposes a lot of useful signals (PRs, labels, reviews, activity) which could serve as a pragmatic starting point (even if the exact sources of truth would need to be defined carefully)

Badges themselves wouldn't necessarily be binary.
They could evolve through levels (aka beginner/intermediate/expert or bronze/silver/gold/platinum) reflecting progression and demonstrated competence rather than a one-off reward.

In my mind this would lead to 2 complementary kinds of badges :

• Fact-based/computed badges : Derived from verifiable signals such as PRs, reviews, scopes, labels and activity over time.,
• Peer-attributed badges : This would preserve the original vision : people voluntarily giving badges to others based on judgment, trust or recognition. That keeps the social and cooptation aspect that makes The Guild unique I guess.,

The key point, to me, would be to clearly distinguish these two types in the UX and semantics.

I think this separation could strengthen the credibility of badges overall, especially when used as a CV or skill-discovery surface, while still leaving room for trust-based attribution.