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.

Reply to this note

Please Login to reply.

Discussion

Why on nostr, and not http?

There are many things you'll learn along the way when building an online marketplace, and starting with nostr means your product pages will be immutable. That could be a nice-to-have for tracking previous prices, but online marketing employs more psychological tactics than you can imagine, in a cutthroat landscape where second place is always just the first loser. Over-informing your customers is counter-intuitively bad for business.

With e-commerce, you're not trying to solve problems of censorship; you're trying to make a sale, and nothing else matters.

That said, I very much agree that the timing is right for an online marketplace transacting in BTC over LN, and which avoids complications that come from selling illicit substances

Well I'm actually more interested in a marketplace for certain types of *labor* of the variety where the tasks are highly commoditized, repeatable, legible, predictable, and most importantly, discretizable -- if you have a series of labor transactions where you need each thing to work such as paying a developer to build an app, there is risk at the size of the entire project, but for a delivery of a physical item, risk is bounded, acceptable, and low enough that it can more easily be overcome through costliness of breech of contract.

Why not http? Nostr is better for real time, dynamic interactions that combine encrypted DMs, the critical relational aspect that allows trust, easy payment integration, and mutability resistant and Sybil resistant transaction history. Also eliminates single point of failure.

That's a great answer RE "why nostr". Developing a long reputation of trust from the same supplier is a fundamental challenge. I believe this is one of the key features of marketplaces like Uber, Airbnb, and eBay. It's all about those five star reviews having meaning. How do we convince the customer that the reviews aren't spam? 🤔

Some sort of proof of *real* transaction history. I mentioned that the use of receipt images and the timestamps could ensure real contracts, especially if that is coupled to receipt images.

My other idea, which brings in the revenue model, is to have some sort of fee on the transaction that is paid to a relay. Then there is also the challenge of trusting the relay.

Good idea.

In my view the buyer needs to pay for the food in advance. If the delivery person is trolled multiple times, this could get expensive and time consuming.

The first time you hire a runner, you might ask them to buy, let's say, a pack of eggs. As they fulfill the order and deliver it satisfactorily you can then slowly increase the order magnitude.

Pament for the shopping + delivery (let's say $10) could be done when they arrive at your doorstep.

Another option is to have 2x the delivery fee paid up front, which is enough to disincentivize trolling. Even 1x fee may suffice. The buyer would lose money in a breach of contract AND damage their reputation. Sending money up front massively increases what we might call the Relational Threshold for lack of a better word, which is the sometimes quantifiable damage in terms of discounted future opportunity cost from the change in the reputational state of their key following a breach.

Do you have a way to bootstrap a $500 relational threshold? There could also be a paid relay that has an admission fee that exceeds the fees you want to be able to initially collect as a costly signal. Let's say you want to be able to get $25 order fees. You pay $5 entry to a relay, start with dozens of smaller orders, and organically grow the threshold. The pay to relay, and possibly some payment to relay as a fee on the fee gets Sybil resistant bootstrapping without social graph WoT.

This is exactly why delivery makes sense. The ratio of counterparty risk to transaction value is about 3-20x and final delivery is as close as you can get to a trustless swap. The Relational Threshold is higher in e-commerce.

I might use cash more, but I also like PayWithMoon, and I think they will come back.

I think normie adoption of Nostr will grow faster than many people expect. I am trying to think about how to enable coöperation stability in two-sided marketplaces where there must be some level of trust / counterparty risk for a contract to take place.

If I come up with a good approach or spark someone else's curiosity, it might get built sooner (I'm a materials engineer, not a developer). I don't see any reason there cannot be a million+ people making a living doing gig work on Nostr within a couple years.

#[4]