Nostr Web Client

Help me see what I’m missing…

Wouldn’t it be a massive negative freeroll for a service provider to participate in this? They are expected to complete work that is usually prepaid prior to being paid with no guarantee that their result will even be “accepted” let alone compensated. And the result is available publicly for anyone else to use for free in perpetuity?

PABLOF7z 2y ago 💬 2

yes

service providers will assess/price risk or go bankrupt

Service providers would choose whom to serve, and at what price.

Companies have been managing risk for centuries, it's not new, and reputation analysis is trivial with a public history of npub's behavior (a service like nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy 's Trust rank would be very valuable)

and the "data compute is publicly available" is an incredibly GOOD thing! why process the same data a dozen times? Once a podcast has been transcribed I can check for existing transcriptions instead of having to transcribe it each time.

This is a feature, not a bug

Reply to this note

Please Login to reply.

Discussion

Mazin 2y ago

It’s a feature for the end users certainly.

I think most service providers will simply not participate. Perhaps ones where the cost of completing the job is 0 or extremely close to 0 will, but service providers with actual job costs can’t operate in this maybe you’ll get paid maybe you won’t environment. You need both sides of the transaction to benefit from the system for them to participate…

738ea36e... 2y ago 💬 1

I understand nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz point. High-cost services will only be available to a select few users who pass the stringent reputation test, which is acceptable. But why not implement both options? Why not allow users to pay upfront (a concept I'll call "zapfront" 😄) to specific service providers (based on reputation), and also signal a permission for a delivery of results via an encrypted DM?

PABLOF7z 2y ago 💬 2

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 💬 1

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.

Mazin 2y ago 💬 1

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.