Marketplaces have two conversations that matter: the public one, where sellers post updates and buyers react, and the private one, where a buyer asks the seller whether the jacket runs small. One tool rarely handles both well. Most marketplaces duct-tape a forum to an email relay and call it community.
A public feed per seller
Sellers want to announce new drops, share behind-the-scenes photos, and reply to comments. Feeds gives you posts, replies, reactions, mentions, and unread badges in one component — scoped per seller via uid.
<wy-feed uid="seller-<%= seller.id %>"></wy-feed>Drop that on the seller's public page. Buyers following the seller see new posts in their feed. Reactions are real-time. Comments thread. The data is on your domain, searchable and moderatable with the tools your trust-and-safety team already uses.
Direct messaging, without running a chat product
A buyer clicks "message seller" and opens a DM thread. That's wy-messenger — the full messenger surface with DMs, group conversations, attachments, and unread tracking. No uid plumbing per thread; the messenger manages conversations as first-class entities.
<wy-messenger></wy-messenger>Auth is yours. Users are your marketplace users. Moderation, receipts, and block-lists sit on your side. What you don't ship is the real-time stack, the attachment pipeline, or the notification plumbing.
Unread counts everywhere they belong
A buyer gets three DMs and follows two sellers. They want a badge on the header telling them something's new. Drop the badge component anywhere you want that number — it reads from the same data as the messenger.
<wy-messenger-badge></wy-messenger-badge>What you don't have to build
- Two separate real-time tiers — one for the public feed, one for DMs.
- A notification system that's consistent across both.
- An unread badge that updates without a page refresh and stays consistent across devices.
Public feed, private DMs, unread state — three components on your marketplace, same backend, same auth, same data.