# The Commerce Commons

Amazon has a lot of gravity because:
- Commerce search (which is a huge chunk of all search) is generally terrible
and unreliable, and at least Amazon isn't worse and they are likely to have
the goods anyway.
- There is a lot of friction involved in using a new online store (creating an
account, entering delivery and payment details).
- Most online stores have a terrible UI and worse performance, and you have to
brace yourself for an onslaught of email after the purchase.
- They have a lot of scale for delivery, notably fast delivery.

The gist of this proposal is that these advantages can be eliminated with
convergent commons infrastructure and standard primitives.

## Architecture Overview

The search infrastructure from [The Search Commons](/fn-UilBZR2GyYMEx96t1QA)
can index products just as well. Using existing universal identifiers that
cover a lot of products (GTINs) and URLs for more bespoke items, the system
can benefit from a unified key that can jointly index vendor catalogs,
product review sites, and sellers. Pick the reviewers *you* trust (who can
be any rando on the Internet), have results sorted by and rendered with reviews,
etc. (See [The Search Commons](/fn-UilBZR2GyYMEx96t1QA) for indexer remuneration
questions that could well apply to reviews.)

Shopping carts should be maintained by the browser. They are common enough and
have sufficiently stable semantics that this should be feasible. They need a
way to refresh prices and availability. The UI can only be better than what
sites offer.

When you check out, the browser assembles all the required information to
send it to the merchant in one single operation, providing:

- The shopping cart itself.
- The delivery and billing addresses which it knows.
- Any applicable coupon, which it can also manage in your wallet.
- Payment, because your agent also has that.

There should be no need to create an account with a merchant, unless you want
to join a frequent buyer programme. The merchant gets a single-use contact
method for you which you can turn off at any point.

Submitting the order provides you with a UCAN which you can use to hit an
endpoint that gives you updates on order status.

Taking this system to its next step, we can imagine a delivery company
marketplace. For any given tuple of GTINs (or equivalent) + sourcing address +
delivery address, they can bid on delivery times and price. It's likely that
this could lead to a few large long-range delivery competitors and a wealth
of small local ones. (This can support restaurant food delivery too.)

## Questions

- What is the MVP here?
- How much of sold products are covered by GTINs?
- How do you ensure delivery trustworthiness, to the point that it's required?
- What is the bad bits equivalent such that you don't have a local kid with a
bike unknowingly delivering heroin as a summer job?
- How does this relate to https://www.w3.org/TR/secure-payment-confirmation/?

## Capture Threat Model

- [ ] Which decisions does each component make?
- [ ] Who is affected by that decision?
- [ ] How can those who are affected have voice in the process?

## Todo
- [ ] See if we could collaborate with [this movement](https://news.techworkerscoalition.org/2023/05/30/issue-8/)

---
<small>This work is part of [The Web Commons](/dFpEb1jeSrKp0Fx8IrdZAg).</small>