SMF·SYNC-COM
Can a prompt replace Sync.com?
Cloud storage & backup — zero-knowledge storage with audit
Exhibit tracking slip
Verdict
Sync.com sells to people who have to answer questions — accountants, clinics, lawyers — and what they are buying is a jurisdiction, a compliance claim and an audit trail somebody else stands behind. Encryption and a share link are a sitting. The record of who opened what, when, from where, kept in a form you would show a regulator, is the buildable half and it is genuinely worth having; the institutional half is not something a personal build produces.
Exhibit A — The prompt
Received on31.07.2026Build encrypted file sharing whose distinguishing feature is an access log you would be willing to hand to a client.
Stack: your choice, Postgres, object storage, Docker Compose, a domain with TLS. Encrypt client-side with the Web Crypto API; the server stores ciphertext.
Sharing model, per recipient rather than per file:
- A share targets one named recipient with their own link and its own key wrapping, so revoking one recipient does not affect the others and the log can attribute every access to a person.
- Controls, enforced server-side: expiry date, maximum downloads, optional passphrase mixed into key derivation in the browser, and instant revocation.
- A revoked link returns a clear "this link was revoked on <date>" rather than a 404, because the recipient needs to know it was deliberate.
The access log is the build:
- Every event — share created, link opened, download started, download completed, download failed, share revoked, share expired — with timestamp, recipient, share id, IP address and user agent.
- Append-only. No update or delete path exists in the code, and each row carries a hash chain over the previous row so tampering is detectable. Write the test that verifies the chain and detects a modified row.
- A per-share timeline view, and a per-recipient view across all shares.
- Export a signed PDF or CSV report for a date range, which is the artefact somebody actually asks you for.
- Retention: configurable, with deletion of expired log rows recorded as its own log entry.
Privacy balance, and state it in the README: you are logging IP addresses and access times about your recipients, which is personal data. Say what you keep, for how long, and why, and make the retention short enough to justify.
Notifications: optionally alert the sender on first open and on download, which is the feature people actually notice.
Write tests for the hash chain detecting tampering, for revocation taking effect immediately including for an in-flight download, and for per-recipient key wrapping meaning one revocation does not break the others.
Do not build sync clients or a mobile app.
Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 a compliance posture somebody else certifies
- B.2 the sync clients and mobile apps
- B.3 a chosen jurisdiction and its data-residency guarantees
- B.4 support when a client asks a question you cannot answer
- B.5 the durability guarantee behind the storage
Prior art
Exhibit C — Why people still pay: compliance posture
Because the product is an answer to a question from a client or a regulator, and a self-hosted server with a good log is not the same as a vendor attestation.
Questions
Why per-recipient links instead of one link per file?
Because a single link forwarded to four people produces four indistinguishable log entries, and the log is the whole point. Per-recipient wrapping also means revoking one person is a real operation rather than invalidating everyone.
Is a hash-chained log overkill for a personal tool?
It is about thirty lines and it converts "here is my log" into "here is my log and it has not been edited". If the reason you are building this is to answer a client's question, that difference is the whole value.
Am I allowed to log my recipients' IP addresses?
Generally yes for a legitimate security purpose, but it is personal data: say so, keep it briefly, and delete it on schedule. A log kept forever "just in case" is the part that turns a compliance feature into a compliance problem.
What does Sync.com actually sell that I cannot build?
A jurisdiction, third-party attestations, and somebody else's name on the answer. When a client asks who can read their files, "a vendor with published compliance documentation" and "my own server" are different answers, regardless of which is technically better.
Related tools
Receipt