Terms of Service (ToS): Nawame

Version 1.2.2 of 5 October 2026

Article 1: Publisher of the service

The Nawame service (hereinafter "the Service") is published by:

HTTP5000, a SAS (French simplified joint-stock company) with a share capital of €15,024,
SIRET (company registration number) 43190337600033, intra-EU VAT number FR48431903376,
Registered office: 3 rue Passet, 69007 Lyon, France,
Publishing director: Maximilien HAIBI,
Contact: info@nawame.eu.

Hereinafter "Nawame" or "the Publisher".

Article 2: Purpose

The Service is a platform for portable and shareable project memory, intended to store, version and organize textual content (notes, decisions, reflections) and to make it accessible to artificial intelligences (AI) that the user connects themselves through the MCP protocol (Model Context Protocol).

These Terms of Service define the conditions for accessing and using the Service. They apply to any user, whether they access the Service through the website or through an application connection (MCP).

Article 3: Definitions

User: any natural person holding an account.
Account: a user's personal, name-bearing space, identified by an email address.
Personal space: a user's private reflection space, the content of which belongs to them and remains invisible to third parties (see Article 6).
Organization: a shared legal workspace, holder of the rights over the content produced within its framework (see Articles 6 and 8).
Team: the unit through which access to an organization's content is granted to members.
Memory: the textual content deposited (notes, decisions, versions, associated metadata).
Third-party AI: an artificial intelligence service published by a third party (for example Anthropic/Claude, OpenAI/ChatGPT, Google/Gemini, Mistral) that the user chooses to connect to the Service.
MCP: the standard connection protocol allowing a third-party AI to access the Service on the user's behalf, within the limits of the user's rights.

Article 4: Acceptance of the ToS and proof of consent

Use of the Service implies full and unreserved acceptance of these Terms of Service.

4.1. Acceptance takes place upon first access to the Service, whether through the website or through the authentication flow when establishing an application connection (MCP). This acceptance is time-stamped, dated and retained by the Publisher as proof.

4.2. In the event of changes to the ToS (Article 13), continued use after notice constitutes acceptance of the version in force, subject to any applicable mandatory provisions.

4.3. Two levels of version. The consent version (the first two digits, for example 1.2) is the one to which agreement is given. The displayed version (for example 1.2.1) adds a third digit for information updates, which impose no new obligation: they are published and flagged, without a new agreement, and the proof retains the displayed version the person read. A substantial change alters the consent version and calls for a new agreement. Certain optional features (for example giving Nawa as a gift, Article 8 bis) also require a specific agreement, collected on their first use. The same applies to the age attestation (Article 5.4).

Article 5: Account and security

5.1. The user undertakes to provide an accurate email address and to keep their means of access confidential (login codes, application connection keys).

5.2. The user is responsible for actions carried out from their account, including through a third-party AI they have connected. An application connection key confers at most the rights of its holder, and may be restricted to an organization or to a narrower scope.

5.3. Any suspicious use must be reported to the Publisher without delay.

5.4. Minimum age: 18 years of age or older. The Service, and Nawa in particular (public beta), is reserved for people 18 years of age or older. A user who accesses Nawa attests that they are 18 or older by an explicit, unticked box or button, at the moment they give their agreement to Nawa (app, WhatsApp or Telegram). This attestation is a specific agreement ("majority", version 1.0), time-stamped and retained; it does not modify the general agreement given to these ToS. For an account that predates this rule, it is requested at its next access to Nawa, which stays closed until it is given. It is declarative: the Publisher asks for neither a date of birth nor an identity document. Without the attestation, nothing is opened and nothing more is kept. The Publisher offers no route for minors and no parental agreement. It may close the account of a person it learns is under 18; Article 12.4 then applies.

Article 6: Ownership of content (central provision)

The guiding principle of the Service distinguishes between the reflection (which belongs to the person) and the result (which belongs to the organization within the framework of which it is produced).

6.1. Personal space: ownership by the person. Content deposited by a user in their personal space is private: it remains their property, is invisible to other users and to any organization, including when the user accesses the Service in a professional context. No one may access it without a voluntary act of sharing on the user's part.

6.2. Content produced within an organization: ownership by the organization. Content created, shared or established within the framework of an organization (know-how, decisions, work content, authoritative material) belongs to that organization.

In the context of employment, this attribution follows from the rules applicable to what is produced by an employee in the course of their duties. In particular, Article L113-9 of the French Intellectual Property Code (Code de la propriété intellectuelle) provides that the economic rights in software and its documentation created by one or more employees in the course of their duties, or according to the instructions of their employer, are vested in the employer, who alone is entitled to exercise them, save for statutory provisions or stipulations to the contrary. This text also applies to agents of the State, of public authorities and of public establishments of an administrative nature.

For content not covered by this text (content other than software and its documentation), as well as for relationships other than employment, the attribution of content to the organization results from the rules of the organization that the member accepts upon joining (Article 8.2) and, where applicable, from their contract. The moral rights of the natural-person author, which are inalienable, remain reserved.

6.3. Voluntary sharing. Moving content from the personal space to an organization always results from an explicit act of the user. There is no automatic transfer from private to shared.

6.4. Technical operating license. The user (or the holding organization) grants the Publisher the license strictly necessary for hosting, backing up, displaying and operating the Service. This license is limited to these purposes and confers on the Publisher no right to exploit the content for any other purpose.

Article 7: Content and user responsibility

7.1. The user is solely responsible for the content they deposit: for its legality, its lawfulness, and its respect for the rights of third parties (intellectual property, personal data, trade secrets, etc.).

7.2. The user warrants that they hold all the rights necessary over the content they deposit or share.

7.3. The user shall refrain from depositing any content that is unlawful, infringing, defamatory, or harmful to the rights or dignity of others.

7.4. Nawame does not exercise prior editorial control over user content and is not responsible for it. In this respect, Nawame acts as a technical provider. The Publisher may nevertheless remove manifestly unlawful content reported to it, under the conditions provided by law.

Article 8: Organizations and teams

8.1. An organization is a legal space (ownership of the work produced, billing, framework of use). No person accesses an organization's content merely by being a member of it: access is granted through one or more teams to which rights are assigned.

8.2. Membership. By joining an organization, the member accepts its rules through an explicit act (a click), once, upon entry: ownership of the work produced (Article 6.2), scope of access, and conditions of departure (Article 8.3). This act is time-stamped and retained.

8.3. Departure of a member.

Their personal space remains theirs: they may export it or request its deletion.
What they have produced within the organization remains there; their access is cut off, without any transfer of that content to another account.
The organization's content remains confidential; it is neither made public nor exploited, except upon a duly issued judicial order, subject to Article 11 ter.5 for content placed in sovereign mode (the Publisher can then hand over only ciphertext).
The name-based attribution of contributions may be pseudonymized at the person's request, without altering the retained work.

8.4. Organization restriction. An organization may, where applicable, restrict the removal of content outside its scope. Any such restriction is announced once, upon entry into the organization.

Article 8 bis: Giving Nawa to someone else (rules for the person giving)

8 bis.1. Purpose. The Service lets a user ("the person giving") give Nawa to another person ("the recipient"): to prepare their welcome (a few things told, questions, a message) and then pass on an invitation link themselves, from their own messaging app. Nawa does not send the invitation and does not write to the recipient first.

8 bis.2. Agreement specific to this feature. Use of this feature requires acceptance of these rules and, where there is payment, of the terms of sale of the gift (Terms of Sale, Article 6 bis), at the first preparation of a gift: unticked box, time-stamped agreement retained together with the version of the text. This agreement is specific to the feature; it does not modify the general agreement given to these ToS.

8 bis.3. Obligations of the person giving. They undertake:

to tell only what they know about the person and may legitimately say about them, and to do so accurately;
not to tell anything that reveals the person's health, beliefs, political opinions, sex life or sexual orientation, origin, trade-union membership or convictions. Nawa detects and refuses sensitive topics, but this detection is automatic and guarantees nothing: the person giving remains responsible for what they write;
not to give Nawa to a person who has declined it or objects to it, and not to follow up;
to give Nawa only to a person they know to be 18 years of age or older (Article 5.4): the recipient is informed of this before accepting, and their own attestation is required before any action;
not to use this feature to harass, solicit, deceive or obtain information.

8 bis.4. What the person giving does not receive. They have no access to the recipient's memory or to their actions. They only know that the recipient accepted the invitation, and it is they who then decide to open what they prepared. The recipient's refusal, blocking or account erasure is not reported to them.

8 bis.5. Liability and suspension. The person giving is responsible for the content they write, within the limits provided by law. The Publisher may refuse, suspend or delete a gift that is contrary to these rules or at the recipient's request, and end access to this feature in case of abuse.

8 bis.6. Recipient's data. The recipient's information about the processing of their data is in section 5 ter of the privacy policy. Any payment and its consequences (withdrawal, refund) fall under Article 6 bis and Article 7 of the Terms of Sale.

Article 9: Connection to third-party AIs (specific clause)

9.1. Choice by the user. It is the user who chooses and connects the third-party AI of their choice (for example Anthropic/Claude, OpenAI/ChatGPT, Google/Gemini, Mistral) through the MCP protocol. Nawame provides the means of connection, not the AI. The Service is neutral as to the AI provider.

9.2. AI provider's terms. By connecting a third-party AI, the user is subject to that AI's terms of use and privacy policy, which they accept directly with the relevant provider. These terms are beyond the Publisher's control.

9.3. Control over what is transmitted. The user controls the content they transmit to the third-party AI they have connected. The Service transmits to the AI, on the user's behalf and within the limits of the user's rights, the content that the AI requests to read or write.

9.4. No liability of Nawame. Nawame is not responsible for the processing carried out by the third-party AIs that the user has themselves chosen to connect, nor for the use these AIs make of the data that the user decides to transmit to them.

9.5. What the connected AI can read, and where it goes. A connected AI (ChatGPT, Claude or another) inherits at most the user's rights. For Nawa's personal memory, it can read what is filed and, if the user has turned this option on, what they recently said to Nawa and has not yet been filed, as well as their pending proposals. The content read goes to that AI's provider, which processes it under its own policy, outside the Publisher's control; the Publisher cannot recall what that provider has already received. Reading recent words is off until the user turns it on; they may turn it off at any time in the AI connection settings, or revoke the AI's connection. Details are in section 7 of the privacy policy.

Article 10: Availability and limitation of liability

10.1. Service "as is". The Service is provided "as is", without any guarantee of absolute availability and without a service level agreement (SLA) at launch. The Publisher implements reasonable means to ensure the continuity and security of the Service.

10.2. Hosting by a third party. Nawame is not the host of the Service. Hosting is provided by a third-party provider (Hetzner, Germany, European Union). Nawame is not responsible for incidents arising from the hosting infrastructure of this third party.

10.3. Exclusions. To the extent permitted by law, the Publisher's liability cannot be engaged for:

indirect damages (loss of operations, revenue, opportunity, or harm to reputation);
loss of data attributable to the user, to a third party, or to a third-party AI connected by the user;
non-compliant use of the Service or of these Terms of Service.

10.4. Cap. To the fullest extent permitted by French law, the Publisher's liability, should it be engaged, is limited to the amount of the sums actually paid by the user for the Service during the twelve months preceding the triggering event. For a user of the free plan, since no sum is paid, this amount is nil. These limitations do not apply to damages resulting from gross negligence or willful misconduct of the Publisher, to personal injury, nor to any liability that may not, under the law, be excluded or limited.

10.5. Backup. The user is responsible for backing up and exporting their important data. The Service provides export tools for this purpose.

Article 11: Nature of accepted content

The Service stores text (including Markdown and text-described diagrams). It does not host binary files (images, PDFs, mockups): at most, a link to content hosted elsewhere may be referenced within a note.

Article 11 bis: Secrets and pointers (Nawame does not host passwords)

11 bis.1. Nawame is not a vault. The Service does not host the user's passwords, API keys or other secret values. It is designed to never receive or see the value of a secret: no application connection tool (MCP) accepts a secret value, and the server holds no means of reading the value of a secret in a third-party vault.

11 bis.2. "Pointer" model. When the user chooses to record where a secret is stored, the Service keeps only a pointer: a readable logical name, a readable location, the usage, and, where applicable, the coordinates of the item in the client's external vault (provider, identifier, project or collection, region) together with a direct link to that vault. The secret's value never passes through the Service and stays with the holder.

11 bis.3. External vault. The vault where the secrets actually live (for example a professional secrets manager) is provided and controlled by the user or their organization; it is not a component of the Service. The user remains responsible for that vault and its access.

11 bis.4. Key disclosed by mistake. Should a secret value be transmitted to the Service by mistake, it is treated as compromised: its trace is purged, the incident is logged (never the value), the Service refuses any return of it and recommends rotating (renewing) the secret concerned.

Article 11 ter: Sovereign mode (end-to-end encryption)

11 ter.1. An optional mode, coexisting with the standard mode. The Service offers, as an option, a sovereign mode: the content of memories is encrypted with a key derived from a passphrase held by the user alone. This mode is not enabled by default; it results from an explicit act of the user and applies to the scope they designate. It coexists with the standard mode, in which content is encrypted at rest with a key held by the Publisher (see the privacy policy). The provisions of this Article apply only to content actually placed in sovereign mode; content remaining in standard mode continues to be governed by the rules of that mode.

11 ter.2. What is encrypted, what remains in clear text. Sovereign mode encrypts the content of memories, the change summary attached to each new version, and the map of a space, that is, the orientation note maintained automatically by the Service, whose narrative thread is written freely by the user or by their AI. The following remain in clear text on the Publisher's side, because they are necessary for navigation, organization and operation of the Service:

the titles of memories;
the tags;
the names of spaces, folders, subfolders and sections;
the search keywords used by the user or by their AI, together with the filters and grouping topics accompanying them;
the name, location and usage of secret pointers, together with the coordinates of the external vault they designate (Article 11 bis);
the author (human or AI), the dates and timestamps, the sequence of versions;
the names of organizations, teams and circles;
invitations and shares (recipients, roles, dates);
the audit log (actions and access refusals: who, what, when, never the content), the log of reads by an AI and the technical logs of calls to the Service (tool called, declared AI client, key prefix, duration, outcome; never the arguments or the content);
the account and billing data.

This enumeration is exhaustive as regards the encryption undertaking: anything not listed in it is encrypted. It is, however, indicative as regards sensitivity: the user alone is the judge of what they place in a heading. Sovereign mode protects what you write, not the way you file it nor what you search for.

Sovereign mode therefore makes use of the Service neither anonymous nor invisible: it conceals neither the existence, nor the heading, nor the rhythm of memories. Users are advised not to place sensitive information in a title, a tag, a folder name or a search keyword.

Nawa remains unavailable in sovereign mode, in this version (see the privacy policy, §5 bis): its own content is not yet encrypted to that standard, and the Publisher refuses access to Nawa for a sovereign account rather than writing to it in clear text.

11 ter.3. Passphrase held by the user alone. The passphrase is chosen and kept by the user. The Publisher does not receive it for safekeeping, does not retain it, does not log it, and holds no recovery, escrow, reset or bypass mechanism allowing it to recover that passphrase or the key derived from it.

11 ter.4. Loss of the passphrase: content permanently unreadable. Should the passphrase be lost, forgotten or destroyed, the encrypted content becomes permanently unreadable. There is no remedy, no restitution and no possible recovery, including by the Publisher, which holds no technical means of restoring access. Backups and exports likewise contain only ciphertext. This consequence is the accepted counterpart of sovereign mode: it is recalled upon activation, which requires an explicit confirmation from the user, and upon each export. The user is solely responsible for keeping their passphrase.

11 ter.5. Impossibility of decryption, including upon judicial order. For content placed in sovereign mode, the Publisher does not hold the key and cannot decrypt. When served with a duly issued judicial order, or any other request it is legally bound to answer, the Publisher can hand over only the encrypted content and the metadata remaining in clear text listed in 11 ter.2. It can provide neither the passphrase, nor the key, nor the content in clear text. The Publisher is not responsible for the consequences of this impossibility, whether for the user or towards third parties.

11 ter.6. Access by a connected AI: two arrangements. The encryption being the same in both cases, the user chooses where decryption takes place when a connected AI needs to read or write encrypted content.

In-session arrangement (offer A). The user opens a session themselves from the Service's console, in their browser, where they enter their passphrase. The passphrase is never communicated to the AI and never passes through the application connection channel (MCP): the tool provided for that purpose accepts no passphrase and merely states where the session is to be opened. A passphrase written into a conversation would be seen and retained by the AI provider: the Service is built so that this never needs to happen. The key is then derived in volatile memory for the duration of the session, is never written to disk or logged, and is erased when the session is closed, when it expires, or when the Service restarts. During that session, opened by the user themselves, the server handles the content in clear text in volatile memory, for the time needed to answer the AI's requests. Outside a session opened by the user, and at rest, the Publisher holds no means of reading the content. A user who requires that no content in clear text ever be handled by the Service, even temporarily, must choose the relay arrangement.
Relay arrangement (offer B). Decryption takes place in a relay self-hosted by the user (11 ter.7). Under this arrangement, the passphrase and the key are never transmitted to the Publisher, including during a working session.

11 ter.7. Self-hosted relay: a component of the user. Under the relay arrangement, decryption is performed by a relay that the user deploys and operates themselves, from a guide and code made available by the Publisher for documentation purposes, as is and without warranty.

This relay is a component provided and controlled by the user or their organization; it is not a component of the Service, following the same logic as the external vault of Article 11 bis.
The user freely chooses the host of this relay. That host may be located outside the European Union. The choice of that host, the lawfulness and framing of the resulting transfer of data outside the European Union, and the configuration, security, access, availability and updating of the relay, as well as the safekeeping of the key within it, fall under the sole responsibility of the user, who acts in this respect on their own behalf and not on behalf of the Publisher.
The Publisher does not operate this relay, has no access to it, deposits no key in it, and is not responsible for its operation, its security, the processing carried out in it, the incidents affecting it, or the loss of the key kept within it.

11 ter.8. Accepted functional limitations. By construction, sovereign mode restricts what the Service can do without the key. In particular:

search over content is impossible: it is limited to the elements remaining in clear text, namely the title of the memory and, where applicable, the tag filter, and it returns no excerpt of the content;
features that require reading the content server-side (automatic cross-referencing, grouping by topic, suggestions) are unavailable or degraded;
writes and modifications to an encrypted memory, including partial modifications, require an open session (or the relay): failing that, they are refused rather than performed in a degraded manner;
sharing an encrypted memory with a team and engraving it as an authoritative reference are refused, under either arrangement: the content would either be put back in clear text outside the encrypted perimeter, or served sealed to people who do not have the passphrase, and therefore unreadable by them;
merging an encrypted memory with an unencrypted one is refused, so that encrypted content is never downgraded;
under the relay arrangement (offer B), the following are additionally unavailable: replacing a specific passage of a memory, since the server cannot locate an exact passage within ciphertext (rewriting the memory in full and appending a block at the end remain possible); problem reports and product feedback, which are intended for the Publisher and would therefore be sent in clear text, and which remain available from the console; lastly, any feature the relay does not know is refused by default rather than transmitted;
exports are delivered encrypted and open only with the passphrase or the relay;
the encrypted content of a personal space cannot be transferred to an organization for as long as sovereign mode applies. Such a transfer is not subject to a formality: it is impossible, and the Service refuses it unconditionally. There is no act, no option and no procedure, even armed with the passphrase, that makes it possible. The reason is that neither of the two possible outcomes is acceptable: the copied content would either be put back in clear text outside the encrypted perimeter, which would destroy the very promise of sovereign mode, or copied sealed and therefore unreadable by the team it is intended for, which would be sharing in name only. A user who wishes to bring content to an organization writes a version of it intended to be read by others, outside the encrypted perimeter.

These limitations are inherent to sovereign mode. They constitute neither a lack of conformity nor a breach by the Publisher.

11 ter.9. Prior information and proof of acceptance. Sovereign mode can be enabled only after explicit information about its consequences and the ticking of an acceptance box. That box is checked by the Service's server, and not by the browser alone: without it, the activation does not take place and nothing is written. Disabling the mode follows the same rule and requires an explicit confirmation, likewise checked server-side.

Each activation and each deactivation is recorded in a timestamped log that is appended without rewriting (no line is modified or deleted), bearing the account identifier, the nature of the act, and the version of this text as displayed to the user at the time of the act. The user may request a copy of it from the Publisher. That record stands as proof of the information received and of its acceptance: enabling sovereign mode constitutes informed acceptance of the consequences described in this Article.

11 ter.10. Limitation of liability specific to this mode. In addition to Article 10, and to the extent permitted by law, the Publisher's liability cannot be engaged in respect of: the loss, forgetting or disclosure of the passphrase by the user; the permanent unreadability of the content resulting therefrom (11 ter.4); the impossibility of decrypting and its consequences, including in the face of a request from an authority (11 ter.5); the self-hosted relay and the transfer outside the European Union it may involve (11 ter.7); the functional limitations described in 11 ter.8; nor the effects of deactivation described in 11 ter.11.

The Service is intended both for professional users and for consumers. This Article therefore draws a distinction between two regimes.

a) Professional user. A professional user is a user acting for purposes falling within the scope of their commercial, industrial, craft, professional or agricultural activity. As regards such a user, the exclusions above apply in full, to the extent permitted by law, and the cap in Article 10.4 remains applicable.

b) Consumer user. A consumer user is a user acting for purposes outside the scope of their professional activity. As regards such a user, the Publisher neither excludes nor limits the liabilities that the law permits neither to exclude nor to limit, and no provision of this Article may be read as doing so. In particular, the following are preserved: the legal guarantee of conformity, liability for gross negligence or willful misconduct of the Publisher, and any liability of public policy. As regards a consumer, the Publisher's position therefore rests not on an exclusion of liability, but on two facts:

An impossibility by construction, not a refusal. The Publisher holds neither the passphrase, nor the key, nor any means of reconstituting them (11 ter.3). The key is derived from the user's passphrase alone; it is neither stored nor logged, and the sealed content is opaque without it. When the Publisher does not restore encrypted content, it is not refusing: it cannot do so. That incapacity is not a defect of the Service: it is its exact counterpart, and it is precisely what the user asked for by enabling this mode.
Prior information, and proof of it. Sovereign mode is optional and disabled by default: it never enables itself. Enabling it requires an acceptance box that is not pre-ticked, whose absence is refused by the server and not by the browser alone, so that no activation can take place without it. Each activation and each deactivation is timestamped and retained by the Publisher as evidence, together with the version of this text displayed at that moment (11 ter.9), following the same logic as Article 4 for acceptance of these Terms of Service.

Nor are the features described in 11 ter.8 withdrawn: they do not exist in sovereign mode, and that absence is announced before activation, both here and, for a paid subscription, in the terms of sale.

These limitations do not apply to damages resulting from gross negligence or willful misconduct of the Publisher, nor to any liability that may not, under the law, be excluded or limited.

11 ter.11. Effects of disabling sovereign mode. The user may disable sovereign mode at any time, under the conditions of 11 ter.9. Disabling it applies to future writes only: it decrypts nothing. Content already encrypted remains encrypted, continues to require the passphrase in order to be read, and its loss remains irreversible under the conditions of 11 ter.4. The account's derivation salt and verification fingerprint, which are not secret and allow neither the passphrase to be recovered nor anything to be decrypted, are retained, so that content already encrypted remains openable with the correct passphrase and so that the mode can be re-enabled without rendering it unreadable. Disabling the mode is therefore in no case a means of recovering content whose passphrase has been lost.

Article 12: Termination and suspension

12.1. By the user. The user may stop using the Service and close their account at any time. Closing the account results in the actual erasure of their private content; their presence in common content (shared or established within an organization) is anonymized and not destroyed (see the privacy policy, and Article 6 on ownership of content). The user may at any time export their memory (Markdown and JSON formats). The retention and purge rule is set out in Article 12.4.

12.2. By the Publisher. The Publisher may suspend or close an account in the event of a breach of these Terms of Service, unlawful content, or use that compromises the security or proper functioning of the Service, after notice where possible.

12.3. The effects of termination on paid subscriptions are governed by the terms of sale (see terms-of-sale.md).

12.4. Retention, then purge when the account is closed. For the lifetime of the account, the user's personal memory is kept: that is the service requested. When the account is closed, for whatever reason, their personal content (private memory, content specific to Nawa, messaging channels, contact details) is erased from the live database within 30 days at most, then from backup copies by rotation within the following 30 days, as follows. When the user closes their own account from within the Service (12.1), erasure from the live database is immediate. When closure is requested from the Publisher in writing or decided by it (12.2), the Publisher carries it out without delay and within 30 days at most. Encrypted backup copies of the database are kept 30 days and then destroyed by rotation: they hold nothing of the user's 30 days at the latest after erasure from the live database, and serve only to restore the Service. Only what a legal or accounting obligation requires is kept, without content: billing and payment data (10 years), and the depersonalized audit log for the periods set by section 9 of the privacy policy. Gift envelopes follow their own short period (Article 8 bis and section 5 ter of the privacy policy).

Article 13: Changes to the ToS

The Publisher may amend these Terms of Service. Users are notified of substantial changes by an appropriate means (notification, email or notice upon connection). The applicable version is dated.

Version history.

Update of 5 October 2026 (version 1.2.2). The consent version remains 1.2: no general consent is invalidated. Adds 5.4 (Nawa is reserved for people 18 years of age or older; attestation collected on entering Nawa through a specific "majority" agreement, version 1.0, requested at the next Nawa access of an existing account; no route for minors), a point in Article 8 bis.3 (giving Nawa to an adult) and Article 12.4 (retention for the lifetime of the account, then, on closure, erasure from the live database within 30 days at most and from backups by rotation within the following 30 days, except what a legal or accounting obligation requires).
Information update of 5 October 2026 (version 1.2.1). The consent version remains 1.2: no new consent is requested for the ToS, as this update informs or describes an optional feature without modifying existing undertakings. Adds 9.5 (what the connected AI can read, including recent words if the user turned it on, their going to the AI provider, how to turn it off), Article 8 bis (rules for the person giving Nawa, specific agreement collected on first use of this feature) and 4.3 (consent version and displayed version).
Clarifications of 29 September 2026 (version 1.2 remains applicable; no new consent is required, this clarification restricting use of the Service for a sovereign account rather than introducing new processing): Article 11 ter.2 receives a cross-reference to section 5 bis of the privacy policy, which explains that Nawa remains unavailable to a sovereign account, in this version, for as long as its own content is not encrypted to the same standard.
Version 1.2 of 15 September 2026 (substantial change): alignment of Article 11 ter with the actual state of the Service. The passphrase no longer ever passes through the AI (11 ter.6); the enumeration of what remains in clear text is completed and made exhaustive as regards the encryption undertaking, and the change summary is now encrypted (11 ter.2); the functional limitations are completed (sharing, engraving, sending to an organization, limits specific to the relay arrangement) and the transfer of encrypted content to an organization is stated for what it is, an impossibility rather than a formality (11 ter.8); prior information and proof thereof are given a clause of their own (11 ter.9); the limitation of liability now distinguishes professional users from consumers (11 ter.10); the effects of deactivation are set out (11 ter.11). This change gave rise to a fresh collection of consent.
Version 1.1 of 15 September 2026 (substantial change): addition of Article 11 ter (sovereign mode, end-to-end encryption: passphrase held by the user alone, permanent unreadability upon loss, impossibility of decryption including upon judicial order, self-hosted relay, functional and liability limitations), and alignment of the confidentiality and judicial-order clauses (Articles 8.3 and 11 ter.5). This change gave rise to a fresh collection of consent.
Version 1.0 of 4 September 2026: initial version.

Article 14: Governing law and jurisdiction

These Terms of Service are governed by French law. Failing an amicable resolution, and subject to the mandatory rules protecting consumers, the French courts have jurisdiction.

Terms of Service, version 1.2.2 of 5 October 2026.

This is an English translation for convenience; the French version prevails.