Terms of Service

1. Operator and scope

The operator responsible for providing PrivateChat is Thomas Firas. Contact: support@privatechat.tv. This is a provisional identification that must be replaced with the real operator's appropriate identifying and contact information.

PrivateChat provides temporary one-to-one rooms, creator accounts and invitation-based guest access. These terms concern that service. The Privacy Policy separately explains processing of personal data.

The service is in private beta. V2 is a separate development and release state; local implementation or testing does not establish deployment to the public service. Descriptions of features apply only where those features are actually available in the version you use.

2. Acceptance and eligibility

The new registration flow requires an affirmative, initially unchecked acceptance of the linked Terms of Service before a creator account can be created. The flow records the terms version, the privacy-notice version supplied with registration and a server-generated time. It does not retrospectively record acceptance for older accounts.

Use the service only where you can validly agree to the applicable terms and comply with the law. If applicable law requires parental or other authorisation, that requirement still applies. This draft does not introduce age verification or settle the operator's final minimum-age policy.

Invited guests do not have to register a creator account. The current guest-entry flow does not collect the registration checkbox. The operator should not represent guest entry as a recorded registration acceptance. Any binding application of contractual conditions to guests must have a suitable notice and formation process.

3. Accounts and access credentials

A creator account requires a valid voucher, an available username and a password meeting the current requirements. An email address or telephone number is not required for standard registration. Choose a username that does not unnecessarily identify you if that matters for your intended use.

Keep passwords, authenticated sessions, room credentials and invitation material secure. Do not use credentials you are not authorised to use. Review sessions you do not recognise and use the available password and session controls where appropriate.

PrivateChat does not provide password recovery through an email address or phone number. Support cannot reveal a password or restore browser keys it does not hold. Losing credentials, clearing site data or losing a device can permanently remove your ability to access an account or conversation.

A creator account or session may be restricted when necessary to prevent misuse, protect service security or comply with applicable law. Such action remains subject to any mandatory legal requirements.

4. Vouchers and paid offers

A creator voucher grants the access described with that voucher, subject to validity, expiry and successful redemption. A redeemed one-time voucher cannot be used to create another account. A voucher does not by itself promise indefinite availability, unlimited rooms or functionality beyond the applicable offer.

Registration creates the account, redeems the voucher, grants creator access and establishes its session in a single database transaction. If the connection fails after submission, the outcome can be uncertain. Try signing in with the selected credentials before submitting the voucher again.

These draft terms do not establish a subscription, price, renewal arrangement or no-refund policy. Before any paid offer is made, the seller, total price, taxes, supplied service, duration, payment process and applicable withdrawal or refund rights must be clearly provided. Mandatory consumer rights cannot be removed by a general checkbox.

5. Rooms, invitations and participants

The creator chooses an available room lifetime and shares an invitation through a channel of their choice. Keep the invitation confidential. Anyone who obtains invitation material may be able to request entry, subject to the service's checks and the creator's approval.

The creator must review the requested access before admitting the guest. Approval controls the room's guest position; it does not independently establish the real-world identity of the person using a browser. Verify the intended participant by a suitable separate method when necessary.

Where V2 invitation codes are available, a room's link and code can coexist. A short code is protected by the implemented access and rate controls and the creator's approval; its length is not a promise against every possible guessing attack.

In the implemented V2 flow, a change of invitation method or replacement guest requires the creator's explicit decision. Pending or rejected requests do not by themselves revoke the existing guest. Approved replacement follows the protocol's membership and history boundaries. These controls do not recall plaintext already obtained by a participant.

An optional link between a guest and an account depends on the entry flow and explicit actions. Anonymous code entry does not require creating an account. Each participant remains responsible for what they choose to share.

6. Acceptable use

Use PrivateChat lawfully and respect other people's rights. Do not use the service to threaten, exploit or harass people, distribute unlawful material, impersonate another person fraudulently or access accounts and rooms without authorisation.

Do not intentionally disrupt the service, conduct credential or invitation guessing, evade rate limits, introduce malicious code or attempt unauthorised access to infrastructure. Security research must remain within a clearly authorised scope; report a suspected issue through support without exposing another person's information.

These terms do not grant the operator access to decrypt messages, and do not promise that encrypted content is routinely inspected. Technical and legal responses to misuse depend on information and capabilities the operator actually has.

7. Security and confidentiality

PrivateChat is designed to encrypt conversation content in participant browsers. The service still handles connection and delivery metadata. Content encryption is different from anonymity, concealment of traffic or verification of the identity of an interlocutor.

Security depends on your device, browser, extensions, credentials and the authenticity of the application code delivered to you. Another participant can copy, photograph or disclose messages. No guarantee of absolute security, complete anonymity, forensic invisibility or immunity from lawful requests is made.

The development test reports describe the cases and versions tested. They are not an independent security certification and do not prove that all implementation or operational weaknesses have been excluded. Assess the service against the needs and consequences of your intended use.

8. Expiry, destruction and local deletion

A room has a defined expiry and can be destroyed earlier through the controls available to authorised participants. Expiry or confirmed destruction ends access and invokes deletion of active server records through the application's storage and cleanup paths.

Destroying a room does not destroy the creator account, undo disclosures or erase copies already held elsewhere. Local room cleanup depends on the relevant browser being able to complete it. Clearing site data or using the local-wipe control affects that browser profile and can permanently remove its keys.

A local wipe does not itself delete server rooms or the account, revoke an unreachable server session, erase another device or remove older backups. Application deletion is not guaranteed physical overwrite across storage layers.

The current interface does not provide self-service account deletion. Contact support to request deletion of information, subject to proportionate verification and applicable legal requirements. Do not use PrivateChat as the sole archive for information you must retain.

9. Availability and service changes

A beta service can be interrupted for maintenance, security work, faults or release changes. Continuous uptime, delivery by a specific time, compatibility with every browser and recovery of every interrupted conversation are not guaranteed. Do not rely on PrivateChat as an emergency service.

Feature availability, quotas and supported versions may change. Changes affecting a paid commitment or mandatory user rights must comply with the applicable offer and law. A beta label does not remove those obligations.

10. Content, responsibility and legal rights

You keep the rights you have in the content you send. Using the service does not grant the operator a general right to publish or commercially reuse your private messages. Processing and relaying encrypted payloads is limited to the service and applicable legal purposes described in the privacy notice.

Participants are responsible for their own use, disclosures and authorisations. The operator remains responsible for obligations that applicable law places on the service provider and data controller. These terms do not exclude liability that cannot lawfully be excluded or limit mandatory consumer or data-protection rights.

No compulsory arbitration or exclusive foreign court is introduced by this draft. Applicable law and any mandatory jurisdiction protections continue to determine legal rights and remedies.

11. Updates to these terms

A revised document must identify its version and date. A recorded registration acceptance refers to the version presented at that time, not to an unlimited advance acceptance of future terms. Material changes must be communicated and a renewed agreement obtained where required.

12. Contact and unresolved draft details

Contact support@privatechat.tv for service questions or reports. Never include a password, private key, session token or confidential invitation in a support message.

Before this draft is used publicly, the operator identity and management arrangement, eligibility policy, deployment information and conditions of any paid voucher offer must be completed. The identity placeholder and local acceptance tests do not resolve those requirements.

13. Technical service boundaries

The technical reference in the Privacy Policy explains the implemented browser, relay, invitation and local-storage model. Its distinctions form part of the service description; they are not an independent audit or a promise that every development feature is already available in production.

Admission is deliberate

A valid invitation is one part of entry, alongside the implemented access checks and creator approval. V2 binds admission to reviewed guest material. Short codes remain finite secrets: the VOPRF-based flow, encrypted envelope and rate controls do not justify a claim that all guessing is impossible.

Encryption has an endpoint and delivery boundary

The intended content-encryption boundary is between the participant browsers. The relay still handles operational metadata. A trusted browser, device and correctly delivered client remain necessary; a server-delivered web client is not independent of its distributor. Non-exportable local keys do not stop malicious origin code from using accessible keys, and an admitted participant can retain readable copies.

Local and server state have different lifecycles

V2 uses MLS-based protocol state and encrypted browser persistence. A server-room deletion, a local browser wipe and an account-deletion request are distinct operations. None of these actions is a promise to erase another participant's device or every backup. Do not treat encrypted storage, pseudonymous identifiers or a short room lifetime as proof of absolute anonymity.

Assessment and reporting

The implemented checks and development test results concern identified versions and scenarios. No independent security audit or post-quantum protection is claimed. Technical questions and responsible reports can be sent to support without sharing real secrets or another person's private content.

14. Hosting and logging scope

The primary application servers are located in Germany, within the European Union. The location of every backup, support operation and provider processing activity must be documented separately. Hosting location alone does not determine all applicable law or replace the operator's obligations.

No plaintext message-transcript logger is implemented in the reviewed chat application. Functional records still exist, including accounts and sessions, room access and delivery metadata, encrypted payloads and the registration acceptance record. The statement does not mean that no data are processed or stored.

Operational diagnostics and reverse-proxy, operating-system or provider logs are separate from a plaintext chat transcript. Their actual fields, settings and retention must be verified for the deployed service. These terms do not offer an infrastructure-wide zero-log guarantee or promise immunity from lawful requests. See the logging reference and retention information for the relevant boundaries.