Proposal: A Commerce Lexicon for AT Protocol #4862
Replies: 3 comments 9 replies
|
As far as I know, Open Market is similar to this. It is different that it has a higher affinity with the existing marketplace than your proposal, but it seems to have a concept that is close in that it focuses on discovery rather than payment. |
|
@auadix would be the maintainer of open market. It seems to be a good start, if they would be interested in joining in. Was looking at implementing some of this myself (in a bit, still trying to get another semi-related project working). I might base it off openmarket, but it's missing a few aspects I'd add in. Some notes:
|
|
Hey, glad @kayakyakr tagged me. I'm the maintainer of Open Market (openmkt.app) and I do agree that what I have is probably the closest thing to what you're describing that currently exists in production on AT Protocol. The core record type I use is app.openmkt.marketplace.listing, and it covers most of what you have in your listing schema: title, description, price, currency, condition, category, images, location, and createdAt. A few things I've arrived at differently through building the app that might be useful for the draft: The "External URL" vs. "Checkout URL" distinction. I noticed your draft leans toward a native checkout model, which is a great direction for a protocol-native economy. In building Open Market, I started with an externalUrl approach to act as a discovery bridge for existing Etsy and Shopify stores. The goal was to avoid payment processing at all costs while allowing sellers to index their current inventory without changing their workflow. I can see how a dedicated checkoutUrl would be the foundation for a more integrated transaction layer, but perhaps the lexicon could support both: a primary checkout endpoint and a fallback discovery link. Service and commission listings. Your schema is currently goods-oriented. I added fields like slotsAvailable and turnaroundTime to accommodate the large community of digital artists on the network. Right now, I have these in a loose metadata object, but I believe there is demand for a "service" extension that a goods-only schema doesn't naturally cover. The hideFromFriends privacy toggle. One thing I implemented to keep privacy in mind is a way for sellers to hide listings from their direct followers. This is almost a self-serving feature to create a bit of separation between our social profile and our marketplace activity, although this only works when we also hide it from logged-out users. Category taxonomy. I’ve already built out a taxonomy with ~25 top-level categories and subcategories. I’m happy to share that as a starting point if you want to standardize the category field. On the social trust piece: I currently use a "follows-of-bot" mechanism as a verified seller signal. It's a manual bootstrapping process for now, but it aligns with your idea of using social graph distance to provide accountability. The biggest thing I'm missing that you've thought about more carefully is reviews. I have no review record type yet. Your design, where the buyer publishes to their own PDS linked via AT URI, is architecturally spot on. I hesitated because the "verified purchase" problem felt like a blocker since I can't track it, but your point about DID-anchored reviews being valuable regardless of a "verified" badge is a great way to handle it. I'd be genuinely interested in collaborating toward a shared Lexicon. If we use the Open Market schema as a draft, we can all iterate on it together. Moving toward lexicon-community makes a lot of sense to me, and I would be open to moving Open Market to a standardized namespace. If you want to look at the full lexicon (github.com/openmkt-app/marketplace) or feel free to poke at the live implementation, let's talk! :) Best, |
|
Hey Niizuki! Sorry for the delay in responding. I’ve been away dealing with some health recovery and am still not quite back to full screen time. I appreciate you keeping the conversation moving; I'll be back to contribute to the commerce lexicon as soon as I’m cleared to sit at the desk again. This is a project that excites me but please, if I delay your plans, go ahead! Open Market will be happy to adopt whatever the final form this lexicon takes, but if you have time and want to ping pong a bit more, I will be able to answer you soon! Thanks, |
|
Hi Al, no need to apologize. Get well, that should be the highest priority. I am more than happy to wait until you are fully ready. Niizuki |
|
Hey @Niizuki! Wow, it took longer than I thought, so now I will bombard this conversation with a lot of ideas :) I loved the first draft, you got everything we talked here before and put it together really nicely, we are moving towards a very well designed Lexicon. I took time to not only analyze what other platforms are doing but to also compare with open source softwares that already solved the problems that we are trying to solve. So with the use of the AI magic to compile things and a lot of back and forth with it, here are the promised review, there are changes proposed and things that we need to decide together. I will also be sending a PR to the codebase later today, so you don't need to figure it out what I'm proposing here to convert it into JSON, I will be sending it all on your way and we can update it accordingly as the conversation continues. I want to thank you for taking your time to work this out! Please review it when you can and we continue with this when it's possible, there is a lot to digest here but those are interesting point and I can't wait to outfit Open Market to be more dynamic, now reading all this I see how much corners I cut to get the project out in the world. Proposed changes to the draft lexiconFeedback on the Where a gap is one that established commerce platforms already solved, we say so. Not to copy them, but because a problem several independent teams hit is usually real. The test we applied throughout: could a real shop describe its full catalogue in this schema without losing anything? The core design holds up. The productGroup and variant records, the type discriminator, and the review snapshot are all sound, and schema.org arrived at the same variant model independently. These are gaps to fill, not a redesign. The one field being replaced rather than extended is Pricing1. One price field is doing three jobsNow "price": { "amount": 2500, "currency": "EUR" }Three problems in one field. Problem A: it does not say whether tax is in the number. A seller in Germany must show prices with VAT already in them. A seller in the US shows prices without tax and adds it at checkout. Both write A single shop can set this once in its settings. A federated marketplace has no shared settings, so the record has to say it. schema.org puts Problem B: there is no sale price. Sale state drives "on sale" filters, price-drop alerts, and badges on cards. With one price field a discount can only be faked in the title. Every shop system stores the normal price and the sale price separately, plus the dates the sale runs. Problem C: "minor units" will be read as "divide by 100". That is wrong for Japanese yen (no decimals) and Kuwaiti dinar (three). Those bugs are silent and they corrupt data. Change: replace the single price with one "pricing": {
"regularPrice": 3000,
"salePrice": 2400,
"currency": "USD",
"taxInclusive": false,
"saleStartsAt": "2026-08-01T00:00:00Z",
"saleEndsAt": "2026-08-14T00:00:00Z"
}One currency covers both amounts, so a USD regular price with a EUR sale price is impossible to write. The current effective price is something the app works out, not something stored. Keep For problem C, say in the description that the number of decimals comes from ISO 4217 per currency, and name yen and dinar as the cases to watch. Platforms that use one global decimal setting for the whole shop get this wrong on multi-currency stores. Integers in minor units are the better call, they just need spelling out. Finding things2. No standard product IDProblem: two sellers list the same book on two different apps. Nothing connects those records. For a protocol whose whole point is that data is shared, that is a real loss. Change: add a Why: this is the join key between marketplaces. It is also what product feeds run on, so it opens the door to sellers pushing their catalogue into Google Shopping and similar. Platforms that care about feed interop have all added a field like this. 3. Classification is four jobs and the draft does one and a halfNow: 21 fixed category slugs, plus a free-text Problem: a marketplace needs four different things and they get confused with each other constantly. Every large marketplace has all four:
The draft has the first layer and a free-text stand-in for the second. It has nothing for the third or fourth. Note what eBay and Etsy do that is easy to miss: their structured attributes are separate from the category tree, and Etsy runs free tags as well as a full taxonomy. These are not alternatives to each other. A seller picks one category, fills in the attributes that category asks for, and then adds tags for the words buyers actually type. The trap to avoid: the obvious fix is to grow the slug list until it looks like Amazon's. That fails for a reason specific to our situation. Amazon can run tens of thousands of category nodes because Amazon owns the catalogue. One company, one database, and they reshuffle the tree whenever they want. A Worth knowing: some self-hosted platforms ship no predefined categories at all and let every store build its own tree. They reached the same conclusion from the other direction. One catalogue can have a canonical tree; many independent catalogues cannot share one everybody is happy with. Change: cover all four layers, and let only the first one live inside the Lexicon.
"taxonomy": { "scheme": "google", "version": "2021-09-21", "id": "499954" }Google publishes a versioned product taxonomy of a few thousand categories that the whole product-feed industry already maps to. A seller who has a deep category can carry it, an app that wants deep browse can use it, and an app that does not can ignore it and fall back to the slug. The point of doing it this way: adding a category stops being a Lexicon change. The tree lives outside, versioned, maintained by people whose job it is.
4. A few small display and control fields
One field to keep out: average rating and review count. If the seller writes their own rating into their own record, it means nothing. The app has to count those. Variants5. A variant cannot say "any size"Now: Problem: a real product, "Red, any size, £20" next to "Blue, XL, £25". There is no way to write the first one. Change: make Platforms that support this leave the value empty to mean the same thing, and it comes up constantly. 6. No way to tell a copied field from a deliberate overrideNow: a variant must repeat Problem: if a variant's title differs from its group's title, nobody can tell whether the seller meant to override it or whether the copy went stale. That is the exact worry raised in the README's own open question about copied fields. Change: let a field hold the literal string
Why: this is a solved problem elsewhere. Platforms with variant products use a literal This is what the README's Denormalized field consistency invariant is currently asking apps to police by hand. With an explicit inherit value the drift cannot happen in the first place, so the rule only has to cover records that chose to copy instead. 7. Nowhere to put product specsProblem: Material, Model, Fabric, Compatible With, Screen Size. None of these vary between variants, so they are not option axes, but buyers filter on them constantly. Right now they can only go in the description as prose, where no app can read them. Change: add a Why: platforms typically model one attribute type with two flags, one marking it as driving variant choice, the other as showing in the spec table. The draft only modelled the first. This adds the second. 8. productGroup: two small things
Stock9. Cannot tell "unlimited" from "unknown"Now: Problem: a missing quantity might mean the seller does not track stock (print on demand, digital, services) or it might mean they just did not fill it in. Those need different handling. Change: add 10. Backorder missingNow:
Change: add Optional extra: Shipping and taxThe rule both of these follow: the record describes the item, not the cost. A shipping rate depends on where the buyer is. A tax rate depends on their country and state and changes without warning. Neither can sit in a record the seller wrote once and strangers read from anywhere. Platforms keep rates in separate configuration and store only the item's classification on the product. We should do the same and say so. 11. Shipping facts are thinNow: Change: add
12. No tax classificationChange: add two fields to the listing:
Then say clearly in the README that rate tables and tax calculation are out of scope, same as payments. 13. Location is only on the shopNow: Problem: Open Market's current model puts location on the listing, and it needs to. A seller with one shop can have a pickup-only sofa in one city and ship everything else. Local pickup is a first-class shipping method in every shop system. Change: add an optional Digital goods14. The terms of sale are missingNow: Change
Do not add the file URL. The record is public, so publishing the file gives the product away. Shop record15. Nothing about policiesNow: name, description, logo, website, location. Problem: a buyer lands on a shop they have never heard of, on a server they have never heard of. Returns policy and shipping policy are the only things they have to go on. Right now the record cannot carry them. Change: add Reviews16.
|
| Record | Add |
|---|---|
listing |
replace price with a pricing object: regularPrice, salePrice, currency, taxInclusive, saleStartsAt, saleEndsAt |
defs#price |
keep as a standalone amount type for shipping costs and minimum spends |
defs#variantProperty |
make value optional |
listing |
groupedItems, taxonomy, gtin, brand, tags, shortDescription, specifications, taxStatus, taxCategory, manageStock, lowStockThreshold, soldIndividually, catalogVisibility, reviewsAllowed, location |
listing.availability |
add backorder |
goodsDetails |
dimensions, shippingClass, shippingRequired |
digitalDetails |
downloadLimit, downloadExpiryDays, fileFormats, fileSize |
productGroup |
defaultVariant |
shop |
policies, handlingTime, banner, defaultCurrency, shipsTo |
review |
images; resolve verified; document shop as a valid subject |
| all | "parent" as an inherit value on fields a variant copies from its group |
|
Hello, I’m glad to hear you’re doing better / are in a better situation, and I’m very happy you came back to this. Thank you for taking the time to go through the proposal in this much detail. I think I agree with essentially all of your points. I also think your feedback helped clarify something broader about the architecture: several of these concepts probably should not live directly inside the core listing schema at all. My current direction is to keep the commerce core relatively small and extract the parts that have their own lifecycle or are likely to evolve independently: Promotions should become a separate structure/record. The current salePrice + date range approach can then simply become one promotion mechanism among several, instead of being permanently baked into listings. That gives us room for percentage discounts, fixed discounts, bundles, free shipping promotions, etc. later without changing the core listing schema. Inventory also looks like a strong candidate for separation. Stock can change far more frequently than the product/listing itself, and availability for groups can then be derived by AppViews/indexers from the underlying listings rather than duplicated as another source of truth. Policies may be better as separate records as well, especially because they can change over time and historical versions may matter. Taxonomy and structured specifications should have clean extension points rather than trying to define one universal ontology inside the commerce core. For shipping and tax, I think basic facts/classifications can remain on the listing, while actual fulfillment logic, rate calculation, tax calculation, etc. should stay in separate systems. I also agree with your point about type. It currently mixes several different dimensions. I think it would be cleaner to separate the structural form of the listing (simple, variant, grouped), what kind of fulfillment it represents (physical, digital, service), and how it is actually purchased or handed off. The general principle I would like to follow here is that we should not take architectural shortcuts just because they make the first implementation slightly more convenient. We are still early enough that choosing the cleaner boundaries is cheap, while changing them later, once other software starts depending on the schemas, may be considerably harder. So I think the best direction is a smaller, more orthogonal core with clear seams around it for larger subsystems to evolve independently. It is a little more work up front, but I think it gives us a much stronger protocol and avoids accumulating special cases over time. I’ll get to implementing these changes shortly. Thanks again, this was exactly the kind of feedback I was hoping for. |
|
I implemented next version. Please check it out if you think this is the correct direction. As i posted above, i have broken up the schema, so it can be maintained separately. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Status: Early draft — looking for feedback, collaborators, and people who've already thought about this
Author: Niizuki
Date: April 2026
Why I'm posting this
I've been following AT Protocol's development with growing excitement, mostly from the identity and decentralization angle. At some point it occurred to me that the same properties that make AT Protocol compelling for social networking — portable identity, user-owned data, application-agnostic records — are equally compelling for commerce. Nobody seems to be working on this seriously yet, or if they are I haven't found it.
This is not a finished proposal. It's a structured thinking-out-loud that I hope will either surface existing work I've missed, attract people who want to build this together, or at least generate useful criticism of the approach. All three outcomes are good.
The problem worth solving
Online commerce today has a platform tax problem. Whether you sell on Amazon, Etsy, or through a Facebook shop, you are renting access to an audience that you have no genuine relationship with. The platform can change its algorithm, increase its fees, or simply remove you, and you lose everything — your reviews, your reputation, your customer relationships. The customer has the same problem in reverse: their purchase history, their trust signals, their preferences are locked inside walled gardens that don't interoperate.
This isn't just inconvenient. It has structural consequences. Amazon's dominance comes partly from logistics (genuinely hard to replicate) and partly from owning the recommendation and review layer (not hard to replicate — just currently locked up). Facebook Marketplace works as a discovery mechanism but provides essentially zero trust infrastructure, which is why it's full of scams. The people who lose most from this fragmentation are small independent sellers and buyers who don't have the scale to negotiate better terms.
The internet was supposed to make commerce more efficient by removing geographic constraints. Instead it replaced geographic monopolies with platform monopolies. AT Protocol suggests a different path.
What AT Protocol enables for commerce
Applied to the commerce problem specifically:
Portable seller identity. A shop's reputation, reviews, and catalog live in their PDS, not on any platform. A seller who built a reputation on one storefront app carries that reputation to any other app that reads the same Lexicon. No starting from zero on every marketplace.
Portable social trust. Your social graph already exists on AT Protocol. If someone you follow recommends a product, that signal is real — it comes from a person with a verifiable identity and a genuine social relationship with you, not from a gamed review system. This is a higher quality trust signal than anything Amazon or Google currently provides.
Application-layer competition. Multiple storefront apps can read the same underlying commerce records. A minimalist shop, a full-featured marketplace, a niche category-specific browser — they all operate on the same data. Sellers don't have to choose a platform; they publish once and reach any front end that supports the standard.
No mandatory platform tax. A platform can still offer value-added services — better UX, logistics integration, promoted placement — and charge for those. But the underlying relationship between buyer and seller doesn't require the platform's permission to exist.
What a commerce Lexicon would need to define
At minimum, three record types:
commerce.*.shop— seller profile recordA shop's identity record, stored in their PDS. Distinct from their social profile, though linked to it via DID.
{ "lexicon": 1, "id": "app.commerce.shop", "defs": { "main": { "type": "record", "key": "self", "record": { "type": "object", "required": ["name", "createdAt"], "properties": { "name": { "type": "string", "maxLength": 128 }, "description": { "type": "string", "maxLength": 2048 }, "logo": { "type": "blob", "accept": ["image/*"] }, "website": { "type": "string", "format": "uri" }, "location": { "type": "object", "properties": { "country": { "type": "string" }, "region": { "type": "string" }, "city": { "type": "string" } } }, "createdAt": { "type": "string", "format": "datetime" } } } } } }commerce.*.listing— product listing recordThe core commerce record. Intentionally keeps fulfillment details out of scope — the listing describes what is being sold, not how it will be delivered. A
checkoutUrlprovides the escape hatch to wherever the actual transaction happens.{ "lexicon": 1, "id": "app.commerce.listing", "defs": { "main": { "type": "record", "key": "tid", "record": { "type": "object", "required": ["title", "price", "availability", "createdAt"], "properties": { "title": { "type": "string", "maxLength": 256 }, "description": { "type": "string", "maxLength": 8192 }, "images": { "type": "array", "items": { "type": "blob", "accept": ["image/*"] }, "maxLength": 16 }, "price": { "type": "object", "required": ["amount", "currency"], "properties": { "amount": { "type": "integer", "description": "Amount in minor units (cents, haléře, etc.)" }, "currency": { "type": "string", "description": "ISO 4217 currency code" } } }, "availability": { "type": "string", "knownValues": ["in_stock", "out_of_stock", "pre_order", "discontinued"] }, "condition": { "type": "string", "knownValues": ["new", "used_like_new", "used_good", "used_fair", "refurbished"] }, "categories": { "type": "array", "items": { "type": "string" }, "maxLength": 8 }, "sku": { "type": "string", "maxLength": 128, "description": "Seller's internal product identifier" }, "checkoutUrl": { "type": "string", "format": "uri", "description": "Where to actually purchase this item" }, "createdAt": { "type": "string", "format": "datetime" }, "updatedAt": { "type": "string", "format": "datetime" } } } } } }commerce.*.review— review recordReviews are published by buyers into their own PDS — not stored by the seller. This is the key difference from Amazon's model. A review is a first-class social object with a verifiable author, linked to a specific listing or shop via AT URI.
{ "lexicon": 1, "id": "app.commerce.review", "defs": { "main": { "type": "record", "key": "tid", "record": { "type": "object", "required": ["subject", "rating", "createdAt"], "properties": { "subject": { "type": "string", "format": "at-uri", "description": "AT URI of the listing or shop being reviewed" }, "rating": { "type": "integer", "minimum": 1, "maximum": 5 }, "title": { "type": "string", "maxLength": 256 }, "body": { "type": "string", "maxLength": 4096 }, "verified": { "type": "boolean", "description": "Whether the reviewing DID is linked to a confirmed purchase — to be defined" }, "createdAt": { "type": "string", "format": "datetime" } } } } } }What this deliberately leaves out of scope
Some things belong at a layer above or below the Lexicon:
Transactions and payments. The protocol shouldn't try to own payment flows.
checkoutUrlis the bridge to whatever payment infrastructure the seller uses — their own shop, Stripe, an existing marketplace. Trying to standardize payments at the Lexicon level would create unnecessary complexity and legal exposure.Fulfillment and logistics. Same reasoning. Who ships the item, how, and when is an operational concern between buyer and seller. The Lexicon describes the product and establishes the relationship; the logistics layer is pluggable.
Dispute resolution. This requires legal jurisdiction and human judgment. It can't be protocolized cleanly. My suggestion is that trust here comes from identity accountability (your DID is persistent and your review history is public) combined with external mechanisms — regional consumer law, voluntary insurance, logistics provider guarantees.
Verified purchase linking. The
verifiedfield in the review record is a placeholder. How you cryptographically prove a purchase happened without leaking transaction data is an unsolved problem worth a separate discussion.Review integrity and the fake review problem
This deserves its own section because it's the obvious attack vector and "reviews live in the buyer's PDS" doesn't automatically solve it.
The core problem: nothing in the schema prevents a seller from creating sock puppet accounts, having them purchase products, and writing glowing verified reviews. This is the same problem Amazon has, and they've spent billions failing to fully solve it.
A few structural properties of AT Protocol make this harder than on Amazon, though not impossible:
All PDS data is public and auditable. Unlike Amazon's opaque review system, every account's full history — posts, follows, interactions, review patterns — is publicly visible. A network of sock puppets created in the same week with no social graph and no other activity is visibly suspicious. Any app consuming the Lexicon can implement basic heuristic scoring on this data without any special protocol support.
Social graph distance as a trust signal. A review from someone two hops away in your follow graph carries fundamentally more weight than a review from a stranger with no connection to you. This is computable from public AT Protocol data. Fake review networks would tend to cluster at infinite social distance from real buyers in your network — making them easy to deprioritize in any well-designed storefront UI.
Labeler services as fraud detection. An independent labeler specializing in commerce fraud detection — flagging suspicious review patterns, newly-created accounts with concentrated review activity, coordinated behavior across accounts — would be visible to any app consuming the Lexicon. This doesn't require protocol changes, just someone building it.
The verified purchase problem specifically. The
verifiedfield in the review record is a placeholder. The cleanest practical solution I can think of is a logistics receipt token: when a package is delivered, the logistics provider issues a signed cryptographic receipt to the buyer. The buyer can optionally attach this receipt reference to their review, providing unforgeable proof of purchase without leaking transaction details. This requires logistics provider participation — it's an adoption dependency — but it's architecturally clean and doesn't require solving zero-knowledge proofs at the protocol layer.None of this fully eliminates fake reviews. But it shifts the problem from "undetectable inside an opaque platform" to "visible and auditable in a public graph" — which is a meaningful improvement in the underlying threat model.
Ecosystem implications if this works
A working commerce Lexicon would make a few interesting things possible:
The shop-as-PDS model. A small independent seller could run their entire public catalog in their PDS, visible to any storefront app that reads the Lexicon. No Shopify subscription required for basic presence, though value-added frontends could still charge for features.
Portable reputation across marketplaces. A seller who builds a review history in one app carries it to every other app. This directly attacks the cold start problem that currently keeps small sellers locked into established platforms.
Social commerce without surveillance. Recommendations flowing through the AT Protocol social graph are attached to real verifiable identities. No fake reviews, no algorithmic amplification of sponsored content disguised as organic recommendation. Just your actual follows telling you what they actually bought.
Logistics providers as commodity services. If the social and identity layer is open and standardized, logistics becomes genuinely pluggable. A Maersk or a regional carrier could offer fulfillment APIs that any storefront consuming the Lexicon could integrate with. The platform tax disappears because there's no platform owning the audience — there's just infrastructure.
The namespace question
The schemas above use
app.commerce.*as a placeholder. The real namespace needs to be anchored to a domain someone controls. Options:commerce.example→example.commerce.*)lexicon-communityGitHub organization, which already maintains a collection of community Lexicons (awesome-lexicons) and has an established process for community schema development — this seems like the most natural home for a shared commerce standardOn the question of experimenting before committing: the AT Protocol team has documented a convention for exactly this situation — using
.temp.in the name hierarchy (e.g.,app.temp.commerce.listing) to signal that a schema is in active development in the live network without implying stability. This seems like the right approach while this proposal is being discussed. Builds against a.temp.namespace can be treated as prototypes; once the schema stabilizes through community discussion, it migrates to a permanent namespace.This is worth discussing before anyone builds anything serious against a stable namespace.
Open questions I don't have good answers to
Category taxonomy. The listing schema has free-text categories right now. Should there be a standardized taxonomy Lexicon, or is free-text plus convention sufficient? A standard taxonomy enables better cross-app discovery but is hard to get right and slow to evolve.
Verified purchase. The logistics receipt token approach described above seems promising — a signed delivery confirmation issued by a logistics provider, optionally attached to a review. But it requires logistics provider buy-in. Is there a simpler intermediate approach? Is unverified-but-DID-anchored review data valuable enough to build on first, with verified purchase as a later addition?
Seller verification. The shop record has no identity verification mechanism beyond the DID itself. In practice buyers want to know a seller is a real business with legal accountability. Does this need to be in the Lexicon, or is it a layer above (labelers, verification services, regulatory compliance)?
Pricing complexity. The current price field is a single amount. Real commerce needs variants (size, color), tiered pricing, sale prices, VAT handling. How much complexity belongs in the base Lexicon versus application-level extensions?
Is this the right layer? The most fundamental question. AT Protocol might not be the right place for commerce records at all — maybe the right answer is AT Protocol for identity and social graph, with commerce living at a higher layer that just uses DIDs as identifiers. Genuinely uncertain and would value opinions from people with more protocol design experience.
Prior art and community
Before posting this I searched for existing commerce Lexicon work and found nothing substantial. If you know of something I've missed, please say so immediately — I'd genuinely rather join an existing effort.
The Bluesky team has confirmed that using Lexicons outside the
app.bsky.*namespace is intended and supported. The main dependency is the Lexicon Resolution system, which is designed but not yet fully shipped — meaning now is actually a good time to be drafting this, before the resolution mechanism locks in conventions.What I'm hoping for from this discussion
The goal isn't to own a standard. It's to have this exist. If this discussion produces a better proposal that someone else runs with, that's the best possible outcome.
All reactions