Trust

I'm Anchit. I built Dhaga and I run it, and I am the only person with credentials to the production database. So the honest answer to “can you read my notes?” is yes, technically I can — and any product that lets a server answer questions about your notes has someone in my position, whether or not they say so.

What I can tell you is what I actually do. I have never opened anyone's graph out of curiosity, and I don't open one to see how the product is being used, to build a case study, or to find something to sell. The only reason I would look is a specific problem you have reported to me, for as long as that takes and no longer. If that ever needs to happen, I would rather ask you first.

I would rather you didn't have to take my word for any of it, which is what the rest of this page is about.

One. Not a team, not a support desk, not an outsourced tier-one, and not a contractor with a read-only replica “for debugging”.

Every personal CRM has this number and almost none of them publish it. At a funded competitor it is some quantity of employees, support agents and vendors that nobody will tell you, and it grows every time they hire. Ours is on this page, and it changes here in the same commit that grants anybody else access — which is the only version of this promise worth making, because it is the one you can check later.

Every visit to an administrative screen is written to an append-only access log: who, when, which screen, and which account. That log holds identifiers and timestamps only, never the contents of anyone's graph, and removing an entry would be a deliberate, visible act rather than a quiet one.

Now the limit, because a control you have misunderstood is worse than one you know the edge of. That log covers the admin panel, and the admin panel has no screen anywhere in it that displays a contact, a note or a fact — it shows accounts, plans and credit balances. Reaching the actual contents of your graph means going to the database directly, and that route is not covered by the log above. I would rather say so plainly than let a real control imply a wider promise than it makes.

Closing that gap is the next piece of work on this page: production credentials that live behind a separate break-glass step rather than in a daily shell, and a named database role whose sessions are logged the way the admin panel already is. When it ships, this paragraph changes.

Dhaga is not end-to-end encrypted, and it cannot be while it does what it does. If a server extracts facts from your notes, searches them by meaning and answers questions about them, that server sees the notes. Anyone selling you both zero-knowledge encryption and an AI that reads your writing is describing something they have not built.

Dhaga holds no SOC 2 report, no ISO 27001 certificate and no HIPAA attestation — do not store protected health information here. When one of those exists it will be named on this page with the date and the auditor, and until then nothing on this site will imply otherwise. The privacy page goes through the same ground in more detail.

Running Dhaga Cloud means a handful of companies necessarily process some of your data. Each gets the minimum it needs: the payment processors never see your graph, and the email service only ever sees your own address. Locations are where the data actually rests, not where the vendor is incorporated.

Adding one is a 30-day-notice event — this table changes before the data moves, not after. Worth stating plainly: your graph rests in Sydney, not in India, so an Indian data-residency requirement is not met by Dhaga Cloud as it stands and needs the single-tenant deployment enterprise customers arrange with us instead.

The whole list. Every row is either strictly necessary to run a service you asked for, or a preference you set yourself — which is precisely why there is no consent banner on this site. There is no advertising pixel, no cross-site tracker, no session replay, and no third-party analytics beyond the two cookieless scripts described below.

Two scripts from our cloud host measure the site itself: one counts page views, the other records how slowly pages loaded for real visitors. Neither sets a cookie — a visit is counted by hashing the request, and that hash is discarded after 24 hours, so nothing accumulates into a profile of you. Before either sends an address, Dhaga strips the query string and replaces every record id with [id], so what leaves your browser is /app/people/[id] — never who, and never what you typed into a filter.

Because they store nothing on your device, they need no consent. They do need an off switch, which is this one:

It takes effect immediately and covers the in-app performance beacon too. It is remembered on this device rather than on your account, deliberately: the person most likely to want it is reading this page without an account, and should not have to make one to refuse.

Export your whole graph as CSV, vCard or JSON whenever you want, without asking anyone — no ticket, no retention call, no export fee. Try that button before you commit to any CRM, this one included.

Deleting a contact cascades through everything derived from it: notes, facts, graph edges and search index entries, rather than leaving orphaned copies behind. Deleting a note removes the facts extracted from it. Deleting your account removes the lot.

The honest footnote is backups. Dhaga Cloud keeps daily database backups and does not run point-in-time recovery, so a deleted record is gone from the live database immediately and persists in a backup only until that backup rotates. We are confirming the exact rotation window with our database host and will state it here rather than estimate it. Backups are encrypted, are never browsed, and exist only to restore the service after a failure.

Relationship graphs are exactly the asset an acquirer would want, and that is the reason to rule it out in advance rather than when there is money on the table. If Dhaga is ever sold, no acquirer receives your graph as an asset of the sale: you would be told before anything moved, and you could export everything and delete your account first. A privacy promise that does not survive its author is a promise with a hole in it.

Small products end sometimes, and the failure people fear is not the shutdown — it is finding out on the day the site stops loading. If Dhaga Cloud closes, you get notice by email well before it happens, export keeps working until the last day, and the data is deleted afterwards rather than parked on a disused server. Nobody plans for this and that is precisely why it belongs on this page while things are going fine.

If you have found a vulnerability, write to contact@ekasmi.com with enough detail to reproduce it. You get a human reply within 2 working days.

Report in good faith and we will not pursue you — that means giving us 90 days before publishing, not accessing or altering data belonging to anyone but yourself, and not running attacks that degrade the service for other people. There is no paid bounty yet; there is credit on this page if you want it. The machine-readable version of this lives at /.well-known/security.txt.

Anything about your own account, a data request, a deletion you want verified, or a security review for your company: contact us. Enterprise teams with a data-residency requirement should ask about a single-tenant deployment on infrastructure you control — it is provisioned under an agreement rather than downloaded, and it is the one arrangement that takes every company in the subprocessor table out of the picture.