Nostr Web Client

because a prepayment system is trivial to implement and doesn't require a NIP.

look at strike; they've built an entire business around allowing you to buy a bit of bitcoin, they measure the risk of default (ACH fucking sucks) and if you are not an asshole and revert they slowly increase your limit

the world works like this, it's just natural; you don't treat your siblings with the same level of risk as you do a stranger. We are inference machines and we are evaluating/computing risk at every pivotal point.

A service provider is in a great position to measure/price risk.

But again, a prepayment system does not require a NIP, you just pay them and then consume the credit.

Mazin 2y ago

I actually think requiring npub balances doesn’t solve the issue as the user still needs to accept your job. If your job is only accepted 25% for example (based on competition, forgetting to pickup result, whatever) you’re price is going to be 4x higher to provide that service. The service provider is going to need to be compensated for “wasted” jobs.

Reply to this note

Please Login to reply.

Discussion

Mazin 2y ago

If the service provider actually requires prepayment instead of a balance deducted when the job result is accepted, then doesn’t it become just a 1:1 relationship?

Mazin 2y ago

I talked to nostr:npub1qlkwmzmrhzpuak7c2g9akvcrh7wzkd7zc7fpefw9najwpau662nqealf5y about this and we had an idea. What if we added “bid” and “accept bid” kinds to the flow?

1. User posts a job request (without a price) and includes whether they want the result to be public or private

2. Service providers bid on the job

3. User selects one of the bids and pays the service provider

4. Service provider delivers job result privately or publicly as agreed to in the request/bid.

No wasted work, more price competition, and reputation of the service provider is easier to manage than pseudo-anonymous or fully anonymous npubs.