NIP-43: Bounties

[ChristianChiarulli]

Demo site here: https://resolvr.io

This is a project we are working at over at resolvr.io, you can read more about how we can further improve the trust problems inherent with a bounty board here: https://github.com/Resolvr-io/Resolvr

[staab]

I would add a canceled status, maybe with a timestamp. I also think if you're going to use a replaceable event you might as well explicitly reference the application that was granted.

[nostrband]

Should this be 'a' tag to reference the 30050 Bounty Event?

[ChristianChiarulli]

yea it should be, I'll update this

[AsaiToshiya]

That should also be possible to delete a replaceable.

[ChristianChiarulli]

I guess what I mean to say here is that even if the bounty wasn't replaceable the creator could just delete their bounty.

[AsaiToshiya]

Ah now I understand, thanks.

[nostrband]

I've been thinking about bounties again bcs we plan to show github issues under repos on nostrapp.link and then allow people to pledge sats with one click to someone who would solve the issue. The difference there from the flow in this NIP:

• the 'problem' statement is not in the 'bounty event', it's external and created by users unaware of the bounty system, the 'bounty' is just a promise to pay sats with a reference to the problem
• thus naturally many pledgers might reference the same problem
• and then if someone wants to 'apply' the only reason to do that is to include the pledges inside 'apply' event to make sure those aren't deleted - you don't need permission from (multiple) pledgers bcs the problem wasn't created by them, and the solution will be accepted by maintainers, not pledgers
• the 'apply' event becomes an optional 'I'm working on this' announcement - might also serve as a signal for others to not compete with me
• the resolution of the problem happens out of band (same with this NIP), but in my case pledgers need to be notified about the need to pay, since pledgers aren't the ones accepting the solution - I'm thinking about asking maintainers to publish a 'problem solved' event referencing the original issue, referencing all pledges and their authors and containing a zap-split set up targeting the people who solved the problem
• the pledgers would have to zap the 'problem solved' event which would become the proof that they've sent the sats they promised to send

I'd be happy if I could apply this NIP to my use case of 'pledge sats to github issues', but it seem too incompatible.

Is there a chance we could somehow get this NIP closer to being applicable? Like making a bounty event just a reference to an externally stated problem? Making it non-replaceable - remove the bounty states (no one 'assigns' the problem), add 'solved' event (replaces the 'complete' status)?

WDYT?

[ChristianChiarulli]

@nostrband I think this is a good idea, but one of the core reasons I have it as replaceable tho is so that clients can track which bounties are open and which are assigned. When a bounty is assigned you will now longer find it under ["s", "open"]. So my worry here is that we won't be able to easily display open bounties on the client.

Another reason we have a concept of "assigned" is so that takers don't duplicate work unnecessarily. For instance imagine that the bounty is very hard and time consuming. Maybe 4 people decide to work on this with no prior "assignment" that acknowledges who has been chosen to work on the bounty, I'm not sure this kind of system is what we want when people are putting in hard work and money is on the line. I could be wrong though and I'm open to your feedback with this context.