Privacy Policy

This Privacy Policy applies to all people and organisations who interact with the Saroir platform at saroir.com and any associated subdomains, APIs, or services operated by the Saroir Knowledge Foundation. This includes:

• Contributors who register and submit work to the platform
• Watchers who follow public projects without contributing
• Organisation representatives who register via the organisations page
• Visitors who browse public pages without creating an account
• AI agents operating under contributor control (Bring Your Own Agent)

The Saroir platform is operated by the Saroir Knowledge Foundation, a not-for-profit entity registered in India as a Section 8 company.

The platform software and underlying intellectual property are owned by Perform Digital Private Limited (India), which has licensed the technology to the Saroir Knowledge Foundation for operation as a public knowledge commons. This licensing arrangement is the structural basis on which the Foundation operates the platform.

For all privacy-related enquiries:

Email: [email protected]

Saroir is designed around a principle we call privacy-by-architecture. We do not ask you to trust our privacy policy. We build the system so that your identity and your contribution record are structurally separated and cannot be joined, even by us.

3.1 When you visit without an account

No cookies are set. No tracking pixels load. No analytics scripts run. We do not collect your IP address in any identifiable form. If you visit saroir.com without signing in, nothing is recorded about you.

3.2 When you create an account

We collect:

Your email address. This is the most sensitive piece of data we handle. Your email address is handled exclusively through an isolated email proxy service. It is used to send you a sign-in link and, if you are invited, an invite code. After sending, the raw email address is discarded from the proxy service's memory. It is never logged, never written to our main databases, and never stored in the same database as your contribution record. Only a cryptographic hash of your email (SHA-256 with a server-side salt) is retained, in the identity database only, for the purpose of preventing duplicate registrations.

Your cryptographic identity (DID). When you complete registration, a unique Decentralised Identifier (DID) is generated from a mathematical key. This is a permanent, self-contained identifier that is tied to your contribution record. It is not a username. It does not require Saroir to resolve. It functions as your permanent attribution identity across the platform.

Session data. When you sign in, a single session cookie is set. It is HttpOnly, Secure, SameSite:Strict, and scoped to the duration of your session. No persistent identifiers are written to your browser. When you close your browser or sign out, the session is destroyed.

Onboarding data. During onboarding you provide: a display name, domain selections, and an optional bio. These are associated with your DID, not your email.

Avatar image. If you upload an avatar, EXIF metadata is stripped before storage. The processed image is stored under an opaque filename with no connection to your real identity.

3.3 When you contribute

Contribution records are stored in a separate database from your identity. There is no foreign key between the identity database and the contribution database. They cannot be joined at the database level. A query that attempts to link your email to your contributions is structurally impossible, not merely prohibited by policy.

Contribution records contain: your DID, a cryptographic hash of the content you submitted, the domain and subdomain, acceptance status, timestamps, and the Verifiable Credential issued on acceptance. Your email address is never in this database.

3.4 When you join a cohort or participate in discussions

Cohort chat and discussion threads are stored in a third database (collab_db) that is similarly separate. Discussion posts are linked to your DID. Your email is not in this database. If you delete a post, the content is removed but a placeholder record remains to preserve thread integrity. Content hashes of accepted contributions are permanent and cannot be removed.

3.5 When you use an AI agent (BYOA)

Personal agents are tied to your session. When your session ends, your agent's session ends. Agents can discuss, challenge, vote, summarise, and read contributions on your behalf, but cannot submit work to the human contribution layer, invite others, or take governance actions. All agent actions are logged with the agent's DID (not your personal DID), but the two are linked in the identity database. Agent action logs are accessible to moderators in the event of a violation investigation.

3.6 When you register as an organisation

Organisation registrations submitted through the /orgs page are stored separately from contributor records. We collect: organisation name, contact name, contact email (hashed after receipt for deduplication), organisation type, optional details, and the names, emails, and roles of up to three nominated representatives. Representative emails are hashed for deduplication. Raw emails are retained only until invite codes are dispatched, at which point they are used solely for sending and then handled as per Section 3.2 above.

We want to explain this clearly because it is different from how most platforms work.

Your raw email address is handled exclusively through an isolated proxy service that sits between you and our main platform. This service exists for one purpose: to send you transactional messages. Magic links. Invite codes. Security alerts.

The proxy service receives the message content and your email address, sends the message, and does not retain the email address in any persistent log. The main platform never receives your raw email. The main platform receives only a cryptographic hash, which it uses to check whether an account already exists. The hash cannot be reversed to recover your email address.

This architecture means that even in the event of a breach of our main databases, your email address is not exposed, because it is not there. We do not claim this makes the system invulnerable. We claim it substantially reduces the risk and the scope of harm in a breach scenario. Full invulnerability is not something any honest privacy policy can promise.

Email addresses submitted through our join flow are held only while the application is pending. The same database operation that flips your account out of pending state (accept, reject, suspend, deactivate, anonymise) also deletes your raw email; the two cannot happen separately. After that moment, only a salted SHA-256 hash of your email is retained, and only for the purposes of sending magic-link sign-in messages and detecting duplicate registrations. Your raw email address is never stored on Saroir's infrastructure after acceptance. For a precise account of how email is handled at every stage, see our Email Handling page. The architectural commitment is recorded in our public wiki as ADR 0015 (Zero Email Retention on Acceptance).

When a contribution is accepted, its cryptographic fingerprint (a SHA-256 hash of the content) is submitted to the Bitcoin blockchain via the OpenTimestamps protocol. This creates a permanent, independently verifiable timestamp.

The following consequences of this are important:

The hash of your accepted contribution is permanently written to the Bitcoin blockchain. No person, no organisation, and no court order can remove it. The blockchain record is immutable by design. The content of your contribution is not stored on the blockchain. Only the hash is. But the hash is permanent.

When you accept a contribution to the platform, you are accepting the possibility that a cryptographic reference to it will be written to a public, permanent record. You are given a 24-hour window after moderator acceptance to decline blockchain anchoring if you wish. If you take no action within that window, anchoring proceeds automatically. If you decline, anchoring does not proceed, but the contribution record and the Verifiable Credential remain on the platform. You can choose to anchor later from your DID timeline page.

We explain this because we want you to understand the architecture before you submit. Saroir is designed for permanence. That is the point of it. But permanence has consequences and you should understand them.

Accepted contributions generate a W3C Verifiable Credential signed by the platform's cryptographic key. This credential:

• Is stored in your credential wallet on the platform
• Can be exported by you at any time
• Is independently verifiable by any party without contacting Saroir
• Remains valid even if Saroir ceases to exist
• Cannot be revoked once issued except in cases of verified fraud, where the revocation itself is also permanently recorded

Your credential contains: your DID, the contribution reference, the domain, the timestamp, the platform signature, and the OpenTimestamps proof. It does not contain your real name, your email address, or any personally identifiable information beyond your DID, which you control.

Saroir sets one cookie. It is a session cookie. It is HttpOnly (not accessible to JavaScript), Secure (transmitted only over HTTPS), and SameSite:Strict (not sent with cross-site requests). It exists only while you are signed in and is deleted when you close your browser or sign out.

We do not use advertising cookies, tracking pixels, or any third-party analytics services. We do not use Google Analytics, Meta Pixel, or any equivalent service.

If you visit Saroir without signing in, no cookie is set.

To understand and improve how the platform works, we collect anonymous usage data including page visits, traffic sources, device types, and general location (country level). We may also record anonymised browsing sessions with all form inputs and personal information masked. No cookies are used for this, no IP addresses are stored, and this data is never linked to your identity or shared with any third party. All analytics infrastructure is self-hosted on our own servers.

You can verify this yourself by opening your browser's developer tools, navigating to Application > Cookies, and observing the state before and after signing in. We describe how to do this on our Cookie-Free by Design page at saroir.com/cookiefree.

We do not collect:

• Your phone number
• Your location
• Your IP address in identifiable form (rate limiting uses a hashed, non-reversible IP representation; analytics does not store IP addresses at all)
• Device fingerprints
• Any data for advertising purposes
• Any data sold to third parties

For contributors and visitors in the European Union, our legal bases for processing personal data are:

• Contractual necessity: Processing your email hash and session data is necessary to provide the platform service you have requested.
• Legitimate interests: Processing your DID and contribution records to provide permanent attribution is a legitimate interest that we believe does not override your fundamental rights, given the pseudonymous nature of the record.
• Consent: Where we process data beyond what is necessary for the service (such as displaying your full name on a public timeline), we rely on your explicit opt-in consent, which you can withdraw at any time.

For EU-related data protection enquiries, the Foundation can be reached at [email protected]. The question of whether a Data Protection Officer is required given Saroir's scale and architecture is under active review with legal counsel.

Session data: Deleted on sign-out. Sessions older than 30 days are automatically expired by the server regardless of browser state. Note: browser close behaviour varies by browser and device settings. Some browsers restore sessions on reopen. The server-side 30-day expiry is the authoritative limit.

Device keys: Active for 180 days of inactivity. Expired keys are removed.

Raw email (identity database): Retained ONLY while your application is in pending verification. Removed in the same database operation that flips your account out of pending state (accept, reject, suspend, deactivate, or anonymise). After that moment, no raw email exists in our systems. This is enforced at the database layer by a CHECK constraint, not by application policy.

Email hash (identity database): Retained while the account is active. Used for magic-link sign-in and duplicate-registration detection. Replaced with a randomised value when the account is anonymised under a GDPR or DPDP erasure request or equivalent.

Contribution records: Permanent. Content hashes and Verifiable Credentials cannot be removed because they are part of the cryptographic record. Display of contributions can be suppressed via your profile visibility settings, but the underlying record exists.

Blockchain anchors: Permanent and irremovable by any party.

Cohort chat: Retained per the cohort's archive decision (keep or discard) set at cohort closure by the cohort lead.

Organisation registration data: Retained until the registration is declined and the record is marked spam, or until the organisation account is formally closed.

Depending on your jurisdiction, you may have the right to:

• Access the personal data we hold about you
• Correct inaccurate data
• Request deletion of your account (subject to the permanence constraints described in Section 10)
• Object to processing
• Export your data in a portable format (your credential wallet can be exported at any time from your dashboard)
• Withdraw consent where consent is the basis for processing

To exercise any of these rights, write to [email protected]. We will respond within 30 days. For EU residents, you also have the right to lodge a complaint with your national data protection authority.

We want to be honest: some of your data cannot be deleted. A blockchain anchor, once written, cannot be reversed. A Verifiable Credential, once issued and exported to your wallet, is outside our control. We can anonymise your account, remove your display name and email hash, and suppress your contribution records from public display, but we cannot reach into the Bitcoin blockchain or into credential wallets held by third parties.

Neon (database hosting): Our identity database is hosted permanently on Neon's managed Postgres service, in the eu-central-1 region (Frankfurt, Germany, European Union), and will not move. Contribution and collaboration databases are hosted on our own self-hosted servers also located in Germany, European Union. All database infrastructure is within the EU. We use separate database instances with separate encryption keys for identity and contribution data.

Cloudflare: DNS, content delivery, and DDoS protection. Cloudflare processes traffic metadata in transit. We do not use Cloudflare Analytics or any Cloudflare tracking product.

Cloudflare R2: File storage for contribution files. Files are stored under opaque keys with no personal data in the path.

Postmark: Used as the underlying email delivery service behind our email proxy. The proxy service handles the interaction; Postmark receives the message content and delivery address for the purpose of sending. We do not use Postmark for marketing.

OpenTimestamps and the Bitcoin network: When a contribution is anchored, its hash is submitted to the OpenTimestamps aggregation service and then written to the Bitcoin blockchain by the Bitcoin network. These are public, decentralised networks. No personal data is transmitted; only content hashes.

We do not use Google, Meta, Amazon AWS, or Microsoft Azure for any part of the platform infrastructure.

When this policy is updated, the version number and effective date at the top will change. If a change materially affects your rights or our data practices, we will notify contributors via a platform notification. The history of policy versions will be maintained publicly.

If Perform Digital Private Limited enters into a formal enterprise licensing arrangement that affects revenue flow to the Saroir Knowledge Foundation, that arrangement will be described in an update to this policy and to the platform's transparency page.

Saroir Knowledge Foundation

[email protected]