Open ecurrencyhodler opened 12 months ago
ya I think this is a cool idea, I guess just as a v1 lets just add a boost button that opens an invoice with a number we want to set on the bounty itself. Similar to assign to self but with no assignment being done and the bounty amount increases
So the steps we may want to take is 1). on backend create a new route to boost a bounty 2). in that route use the same polling logic for invoices to see if the invoice was paid 3). if paid increase the amount in the db. 3a). if part of an org increase the orgs budget by that same amount 3b). if there is no org then we need to disable being able to boost cause currently there is no where to allocate those funds since they will be paid out of band currently (to this point we shouldn't even let the user generate an invoice that we cannot allocate funds to since we don't want them to pay accidentally) 4). Make frontend changes to create new boost button on bounty 5). Boost button creates a modal with an amount input and next button 6). Takes us to invoice screen where user will scan and pay invoice 7). poll for invoice payment using new endpoint 8). remove modal when invoice is paid and show new amounts
There may be a few things we need to change about this like the invoice may need to have a new type for adding to bounty not sure though
Gets you the invoice (not sure if POST makes sense here)
GET /bounty/fund/{id}
(set the invoice as 2 minutes)
Poll for invoice
GET /bounty/fund/{invoice}
(poll for 3 minutes)
Just leaving a comment. I like the fact that we will have to track boosted payments in a separate DB. It'll make it easier for us to track funds from providers and funds from boosters. Would be an interesting metric to track.
Just leaving a comment. I like the fact that we will have to track boosted payments in a separate DB. It'll make it easier for us to track funds from providers and funds from boosters. Would be an interesting metric to track.
I would make sure the structure of what we want to store is significantly different. if the structure is mostly the same a column identifying what kind of transaction it is might be easier than adding additional complexity of a new table
Good point. But we had talked about there needing to be a separate DB due to how deposits are currently structured for organizations on our call today. I also wanted that documented here.
We might need a locked state in between enabling fundraising boosts and payouts.
We don't want someone to generate an invoice, bounty gets paid, and then they pay the invoice.
Funds could still get deposited to the org after the bounty is paid but the intent of the boost was to fund the work of the bounty.
I was on a call with a potential provider yesterday. One feature he requested was the ability to enable people to contribute bitcoin to a specific bounty. When they do, they see the amount of the bounty increase. They also want to embed our website into the fedi app so people can pay the bounty from inside the app.
He says this is a limitation in replit where individual people can't contribute to specific bounties. HRF had a similar problem.
edit