How can I add chat without keeping a message archive?

First separate “not stored in a database” from “never passes through a server.” A live WebSocket service can relay messages without retaining them, but your infrastructure may still expose content through logs, crash reports, backups, or monitoring unless those are deliberately configured too. Document what metadata remains, such as account identifiers, connection times, and IP-related data.

For messages that must be inaccessible to the service operator, use a well-reviewed end-to-end encryption protocol or a mature system that already implements one. Don’t roll your own encryption. Also plan for key changes, multiple devices, account recovery, and what happens when a recipient is offline. Those details can make a supposedly simple chat feature a substantial project.

Direct device-to-device data transfer can avoid routing message content through your application servers once a connection is established. But it doesn’t make the whole system server-free: devices still need a way to discover and connect to each other, and the recipient generally has to be online for a live exchange. Connection setup can reveal metadata, and network conditions may require relay infrastructure.

That can be a fit for live conversations, but it’s a rough default for marketplace messaging if people expect to write now and get a reply later. Test the offline case early rather than treating it as an edge case.

A practical middle ground is encrypted messages with short-lived server storage. That gives recipients a chance to read messages when they return, without keeping an indefinite archive. Set an explicit expiry, avoid putting message bodies in logs, and check that backups and analytics don’t quietly extend retention.

For abuse reports, let a user choose specific messages to submit, with context they approve. That means the service can review reported material without routinely retaining every conversation. Make the limits clear: if message content is unavailable to the service, reports based on that content require the reporting person to provide it.

For an MVP, showing a preferred contact method is a reasonable temporary option, even if it feels less polished. You can also let users opt in to sharing contact details only for a particular listing, rather than exposing a handle on every profile. That keeps the first release simpler while you learn what people actually need.

Before handling real users, especially if minors might use the service or users may be in different jurisdictions, get qualified advice on applicable privacy, safety, and recordkeeping rules. Data minimization is useful, but it doesn’t automatically settle those obligations.