Replying to Avatar Delta, Dirac

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.

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.

Reply to this note

Please Login to reply.

Discussion

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.