Dirac Delta on Nostr: A delivery app for anything is probably a good marketplace app for nostr. Rather than ...
A delivery app for anything is probably a good marketplace app for nostr. Rather than selecting different items, the requests are placed in text format: e.g. [2 lbs ribeyes, 1 lb butter, 1 gallon raw milk, and a Makita impact driver]. Zero collaboration with stores, no browsing for cleaner UI, just know what you want. The note includes geolocation, order parameters, and allows runners to filter for their area. Different bid/ask approaches are possible.
When a contract is agreed upon, the buyer zaps the runner the fee amount (say $10). The runner then purchases the items and physically delivers the items. An image of the receipt could then be posted to Nostr on a thread for the contract. Then upon physical hand-off, the buyer zaps the receipt note with the stated amount (and can include a tip).
In the event the buyer breaches the contract, the runner retains possession of the goods, and may even be able to return the goods, while also keeping the fee that was paid up front. In the event the runner fails to deliver the goods, their reputation will prevent them from continuing in this line of work with that ID, and bootstrapping a new one will require taking a number of much lower profit orders.
Rather than relying on a 3rd party to decide platform or deplatform in a binary way, everyone can chose who to interact with, and it can be done in a ranked way. For instance, you might choose to bid more for people with higher ratings, which then incentivizes people do things continuously better rather than merely acceptably. The images of receipts and some heuristics around those may suffice to have very high Sybil resistance.
The client could have a tool for filtering notes such that it is easy to verify a history of transactions, and you could even have parameters for degrees of trust in a single click. The client would also have a price conversion showing the dollar amount matching the sats sent at that time, and you could even have it hooked up to an image recognition AI service that extracts the total on the receipt to auto-generate an LN invoice.
Since the threshold of trust is lower than the transaction size, and only needs to exceed the value of the fee, it seems relatively easier to bootstrap, and perhaps could be bootstrapped fairly easily with a vouching system that does not need to be overly complex since after a few weeks of history, it no longer needs the vouching of others to remain trustworthy. I think this might fulfill the concept of a fully transferable relational contracting capability.
This allows delivery of restaurant or grocery food or any other IRL item. It also is structured in such a way that it allows the purchase of bitcoin by runners at a negative rate since they can use a credit card when buying. One challenge however is that runners may need to quickly turn their bitcoin back into dollars since the sort of people doing deliveries might not have enough liquidity to cover a day's worth of shopping.
Am I thinking about this correctly, or do I have something off? Is there a good way to monetize this with any amount of defensibility? Maybe a highly reliable client that charges a very small rake on fees? Perhaps partnering with LSPs? Of course, does have some privacy challenges, though you would use a separate keypair from your primary ID as a starting point.
My general view is there is a sweet spot of latency for a good first marketplace product: e-commerce, craigslist, UpWork, or Airbnb and you don't actually need Nostr quite as much; ride-share, and it's hard to have good UX without critical mass and more precision around mapping and dispatching probably harder; it also seems easier to bootstrap than plumbing, painting, electrical, auto repair, or the like, but that would likely be a good follow on.
When a contract is agreed upon, the buyer zaps the runner the fee amount (say $10). The runner then purchases the items and physically delivers the items. An image of the receipt could then be posted to Nostr on a thread for the contract. Then upon physical hand-off, the buyer zaps the receipt note with the stated amount (and can include a tip).
In the event the buyer breaches the contract, the runner retains possession of the goods, and may even be able to return the goods, while also keeping the fee that was paid up front. In the event the runner fails to deliver the goods, their reputation will prevent them from continuing in this line of work with that ID, and bootstrapping a new one will require taking a number of much lower profit orders.
Rather than relying on a 3rd party to decide platform or deplatform in a binary way, everyone can chose who to interact with, and it can be done in a ranked way. For instance, you might choose to bid more for people with higher ratings, which then incentivizes people do things continuously better rather than merely acceptably. The images of receipts and some heuristics around those may suffice to have very high Sybil resistance.
The client could have a tool for filtering notes such that it is easy to verify a history of transactions, and you could even have parameters for degrees of trust in a single click. The client would also have a price conversion showing the dollar amount matching the sats sent at that time, and you could even have it hooked up to an image recognition AI service that extracts the total on the receipt to auto-generate an LN invoice.
Since the threshold of trust is lower than the transaction size, and only needs to exceed the value of the fee, it seems relatively easier to bootstrap, and perhaps could be bootstrapped fairly easily with a vouching system that does not need to be overly complex since after a few weeks of history, it no longer needs the vouching of others to remain trustworthy. I think this might fulfill the concept of a fully transferable relational contracting capability.
This allows delivery of restaurant or grocery food or any other IRL item. It also is structured in such a way that it allows the purchase of bitcoin by runners at a negative rate since they can use a credit card when buying. One challenge however is that runners may need to quickly turn their bitcoin back into dollars since the sort of people doing deliveries might not have enough liquidity to cover a day's worth of shopping.
Am I thinking about this correctly, or do I have something off? Is there a good way to monetize this with any amount of defensibility? Maybe a highly reliable client that charges a very small rake on fees? Perhaps partnering with LSPs? Of course, does have some privacy challenges, though you would use a separate keypair from your primary ID as a starting point.
My general view is there is a sweet spot of latency for a good first marketplace product: e-commerce, craigslist, UpWork, or Airbnb and you don't actually need Nostr quite as much; ride-share, and it's hard to have good UX without critical mass and more precision around mapping and dispatching probably harder; it also seems easier to bootstrap than plumbing, painting, electrical, auto repair, or the like, but that would likely be a good follow on.