Privacy and Discretion: How Modern Directories Protect Both Sides

Privacy on an adult-services directory matters more than on most other platforms because the consequences of a leak are higher. A leaked restaurant booking is mild embarrassment; a leaked companion booking can affect relationships, employment, and safety. Both clients and providers have skin in the privacy game, and a modern directory has to design around that asymmetry deliberately.

This article walks through what SilkDots actually does to protect privacy on both sides, and equally importantly, what it does not protect — because dishonesty about privacy is worse than imperfect privacy.

What clients give up — and what they don't

When you create a client account on SilkDots, you provide an email address (verified) and a password. You can browse without an account. Browsing without an account doesn't store any personal data on your row in the database, because there is no row.

When you click a contact button on a profile:

The platform records that an interaction with that profile happened, tied to your account
The provider sees the click count on their dashboard but does not see your account or email
The phone or messaging handle you go to is not given the platform's data

When you message a provider through an off-platform channel (WhatsApp, Telegram), the platform has no insight into the conversation. We never see the content of off-platform messages.

If you choose to leave a review later, your review is signed with your account display name, not your email. The display name can be a pseudonym.

What providers give up — and what they don't

Providers give the platform substantially more — they have to, because the platform vouches for them via verification and their identity is the product they're selling.

What a provider's profile contains:

Public profile data: name (often a working name), photos, description, services, pricing, location
Verification artifacts: the unique-code selfie, ID for age verification (kept internally, never shown publicly)
Contact handles the provider chose to publish

What a client cannot see:

The provider's email address
Real legal name (unless the provider has chosen to use it as their display name)
The verification selfie or ID document
Login history, IP, or any session data

Providers have a setting for blurred-face public photos while still verifying internally. The verification badge applies; the public face does not need to.

Photos and the R2 bucket

Public photos are served from a single object-storage bucket with three logical prefixes — public ad photos, blog covers, and verification selfies. The verification selfies are firewalled: no public URL ever resolves to them. The platform can fetch them through signed URLs only, and only the moderation team has the role to mint those URLs.

A common worry: "if my verification selfie is in the bucket, can someone find it?" The bucket itself is private. Public ad photos have a public-readable prefix. Verification selfies don't. There is no path from "knowing the bucket name" to "viewing a selfie."

Logging: what we keep and for how long

Login events are logged with hashed IP, user-agent metadata (browser, OS, device type), and a fingerprint visitor ID. We keep these for a rolling window — long enough to detect anomalous logins (a sudden new country, for instance), short enough that the data doesn't accrete forever.

Hashing the IP means we can match a known IP to itself but cannot recover the IP from the hash alone. The hash uses a per-platform pepper that stays on the server.

We do not log:

The content of in-platform messages, except to the extent needed to gate reviews (a thread existing is recorded; the messages inside it are not retained beyond what's required for the chat to function)
Your browsing history within the site
External clicks (after you click a phone number, that's between you and your phone)

Data deletion

If you close your account:

Your client account row is deleted
Reviews you left remain, but are anonymised
Login events tied to your account are removed
Wallet history is retained as required for finance/audit reasons

Provider deletion is more involved because of legal retention requirements around verification documents. Verification artifacts (the unique-code selfie, age ID) are retained for the period required by Indian KYC regulations even after the public profile is taken down.

What discretion cannot mean

Privacy isn't anonymity. The platform can identify which account left which review, which account boosted which listing, and which account flagged which provider. Moderators see this data when they need to act on a report. The system is designed so this access is logged and auditable.

We don't promise:

That an extremely targeted legal request couldn't pull data through normal due process
That a provider you choose to share your real name with off-platform won't tell someone
That a phone number you give a provider stays unsearchable

Discretion is layered. We do our part; the rest is what you choose to share.

Frequently asked questions

Can a provider see my email or real name? No. They see your display name (which can be a pseudonym) only when you leave a review. They never see your email.

Can the platform see my off-platform messages? No. Once you've left for WhatsApp/Telegram/SMS, those conversations are not visible to us.

Are my photos searchable on Google? Public ad photos can be reverse-image-searched the same as any internet image. Verification selfies cannot — they're not on the public internet at all.

What happens to my data if I'm banned? Account is closed and most data deleted. Verification artifacts are retained for KYC retention requirements.

The compact version: SilkDots is private but not magic. We protect what we can — selfies stay private, IPs are hashed, off-platform messages are not visible to us, public profiles can be face-blurred. The rest depends on what you choose to share off-platform. Honest privacy beats marketing privacy.