Notices

From 1 October 2026, version 2026-10-01-v21 of the Terms of Service replaces 2026-09-28-v20. Section 1.2 now says that when you take a one-time pass for an AI agent on nmts.me/ai, you accept these terms there, and that acceptance is recorded for the account the agent makes with the pass. Section 3.2 now says that such an account has no step where you type the key back in: the command-line tool keeps the key in its credentials file on that machine.

From 1 October 2026, version 2026-10-01-v23 of the Privacy Policy replaces 2026-09-28-v22. The Registration row in section 2 now includes the one-time pass for an AI agent: a digest of the pass, when it was issued, expires and was used, the document versions accepted with it, and the account it made. Section 5.2 now names taking such a pass among the uses of the human check you can refuse.

From 28 September 2026, version 2026-09-28-v20 of the Terms of Service replaces 2026-09-27-v19. Section 2.2 now describes both kinds of storage: NMTS Standard on the Walrus network, and NMTS Heavy, where each part is kept whole with Filecoin storage providers chosen from that network's public registry, two run by different operators unless you choose otherwise in the command-line tool. We have no contract with any provider. On Filecoin, data is deleted by each provider, when it chooses, after a removal request.

Section 4.1 now says NMTS Heavy costs half as many credits, rounded up, and 4.3 says the deposit is held only on a credit-paid upload to NMTS Standard. The 28-day term that cannot be extended applies to both. Sections 7.1 and 7.2 now say that deleting a credit-paid file on NMTS Heavy also sends the removal request, and 7.4's daily check covers NMTS Standard. Sections 3.1, 5.1 and 5.2 now include the Filecoin wallet the command-line tool derives from your NMTS key and its deposit-funded storage.

From 28 September 2026, version 2026-09-28-v22 of the Privacy Policy replaces 2026-09-27-v21. Sections 4.2 and 4.5 now name the Filecoin storage providers that hold a file on NMTS Heavy: independent operators we have no contract with, chosen from the network's public registry, which hold the ciphertext, its identifier, its size and the time, and see your IP address when your browser uploads to or downloads from them. The Filecoin chain is read through GLIF, run by GLIF Ltd., by our server and by the command-line tool when it pays from your own wallet, whose transactions are then public on the Filecoin chain.

Sections 5.4 and 5.5 now place the Filecoin providers where the Walrus nodes are for transfers abroad, and you can ask us which countries they declare. The Files row in section 2 now includes the address of your own wallet where you paid a file's storage from it. Section 3.3 now says that deleting a credit-paid file on NMTS Heavy sends a removal request and each provider deletes the bytes when it chooses.

From 27 September 2026, version 2026-09-27-v19 of the Terms of Service replaces 2026-09-26-v18. A new section 7.5 describes public links: anyone who holds a file's public link can download and open that file without an account until the link is cut, reaches the expiry you chose, or the file goes to the trash, and copies already downloaded stay with whoever has them. Section 10.2 adds making a public link to the requests refused until you accept the current version.

Section 8.2 now says we cannot see what you store unless someone gives us a file's public link or a key that opens it, and that anyone can report a public link from its page without an account. Section 8.3 now says a report that a public link holds child sexual abuse material or non-consensual intimate images cuts that link at once, before anyone reads the report and without anyone opening the file. It also names cutting a public link among our measures, reverses a cut link like removed records on a restoration demand under 저작권법 제103조 제3항, and says we tell both sides where we have a way to reach them. The sentence saying we do nothing where we cannot tell whether a right has been infringed is removed.

Section 4.3 no longer says the product shows two ceilings before you confirm, because a file you pick now starts uploading at once. It now says we refuse an upload that would go over the credits one file, or one account in a day, may use. The 28-day term that cannot be extended is unchanged.

From 27 September 2026, version 2026-09-27-v21 of the Privacy Policy replaces 2026-09-26-v20. The table in section 2 has a new row for public links: per link a random token, the file it opens, the account that made it, values your browser encrypted that we cannot open, whether it shows the file's name, when it was made, expires and was cut and who cut it, and a count of the times it was opened, with no time and no reader. It is kept until the file's record or the account is deleted, and a link is cut when its file goes to the trash.

The support row now includes a report about a public link, with a contact if the reporter gives one. Section 2.2 now says a file's public link lets whoever holds it open that file, including us if the link reaches us. Section 2.6 now lists among the decisions taken by machine that a report of child sexual abuse material or non-consensual intimate images in a public link cuts that link at once.

An account can now hold up to three public codes, and you can revoke one and make another. The account row now lists your public codes with the day each was made and the day you revoked one, and the files row records which public code each side of a share used.

When you revoke a public code, we keep a one-way fingerprint of it, with no account and no date, for good — also after the account is deleted — so that nobody can use that code again. Anyone who holds the code can check with the fingerprint that it was revoked. Section 3.2 now counts four things that outlive the account instead of three.

From 26 September 2026, version 2026-09-26-v18 of the Terms of Service replaces 2026-09-23-v17. Sections 1.2, 3.7 and 10.2 now say that a business connects an NMTS Platform key to its account, the name the product's screens use, where they said it registers as a business. What a business can do, and what it must do, is unchanged.

In the Korean text, sections 2.1, 3.1, 6.2, 7.1, 7.3, 10.2 and 12.1 now use the words the product uses: 키 for key where it said 열쇠, 연락처 for contact where it said 창구, CLI where it said 명령줄 도구, and 업로드 and 다운로드 where it said 올리기 and 내려받기. The meaning of these sections is unchanged.

From 26 September 2026, version 2026-09-26-v20 of the Privacy Policy replaces 2026-09-23-v19. Section 8.2 now says the backup store refuses to let a backup be deleted or altered for the first 7 days, where it said 90. Hourly backups still go 91 days after they are written and daily backups 364 days after.

The retention row for sessions and section 8.1 now say that a session with a length of 1 hour to 30 days also ends 30 days after sign-in, even while you use it. A session that lasts until you sign out does not end that way, and still ends once it goes unused for 30 days. Section 8.1 also says operator access runs on credentials the operator alone holds, where it said keys.

In the table in section 2, the business row is now named NMTS Platform and describes a business that connects an NMTS Platform key, the name the product's screens use; the daily count of accounts a business opened is kept 30 days and cleared by the next account the business opens after that, where it said the next registration. The Files row now calls your file list an encrypted list where it said one encrypted blob, because the list is now stored in more than one encrypted part.

The English text says account identifier where it said account id, and encrypted where it said sealed. The Korean text uses the words the product uses: 키 where it said 열쇠, 연락처 where it said 창구, CLI where it said 명령줄 도구, 라벨 and 핸들 where it said 이름표 and 손잡이, and 솔트 where it said 소금. Section 2.3 in Korean now says 요청 한도, request limits, where it said 요금 한도, which read as a limit on charges.

The Support row in section 2 now says a question about the board or a request for your data or its removal is kept 120 days, and a question about a storage loss 12 months, where it said 30 days for every message. The 120 days were already how the service worked; the 12 months are new from this version, so a question about a lost file and our answer stay as long as the record of the loss itself.

From 23 September 2026, version 2026-09-23-v17 of the Terms of Service replaces 2026-09-19-v16. Section 3.2 now says creating an account has one step you cannot skip — typing your NMTS key back in, or saving the recovery file that holds it. The tick box that asked you to confirm what the recovery list is has gone; the screen still explains it, and section 3.2 still says what it is and what the independent recovery tool does with it.

Sections 5.4 and 9.3 now name the auto-approvals separately. The storage-only auto-approval is on unless you turn it off: you approve the total of a spending session before it starts and its first payment yourself, and it signs only within that total. An everything auto-approval, which can also move funds out, signs only if you turn it on, for at most 30 days at a time. The standing share is still 0 until you set it. The liability exclusion in 9.3 is limited to transactions executed within a total you approved, under an everything auto-approval you turned on, or under a standing share you set, and it still does not cover our own error in computing or addressing a total or a share.

From 23 September 2026, version 2026-09-23-v19 of the Privacy Policy replaces 2026-09-19-v18. The retention row for sessions and program keys now reads: a session is kept until you sign out or until it goes unused for the length you chose — 1 hour to 30 days, and 30 days for “until you sign out”. The 30-day end counted from the moment a session was made is gone. Section 8.1 says the same in the security paragraph. Nothing changes for program keys: up to 90 days as you chose, and 30 days more once revoked.

From 19 September 2026, version 2026-09-19-v16 of the Terms of Service replaces 2026-09-07-v15. A new section 3.7 lets an account register as a business with a public signing key, open accounts for the people who use its own product up to a daily limit, and sign for which requests we accept from it for those accounts. Toward us the business is the holder of those accounts and answers for what it signs and what its product does in them; the people it opens accounts for have their agreement with the business. Before opening an account the business shows that person our Privacy Policy and obtains their consent to the transfers abroad it lists, and it confirms that its product is not directed to children. Whoever holds an account's NMTS key can sign in, delete the account and take its files.

Section 1.2 now says a business names the versions it accepts in its registration request, and section 10.2 says registering as a business requires the current version while requests a business signs for an account it opened do not pass the acceptance gate. Nothing changes for an account that is not a business and was not opened by one.

From 19 September 2026, version 2026-09-19-v18 of the Privacy Policy replaces 2026-09-07-v17. One row joins the table in section 2: for a business, its public signing key, the name it chose, its status and the dates it registered and last changed the key; for an account a business opened, which business opened it and when; per business, how many accounts it opened each day (30 days); and for each request a business signs, its time and a hash of the signature (10 minutes).

A new section 2.5 is for a person whose account a business opened: we are the controller only of what the table lists, we hold it on legitimate interests because that person has no agreement with us, the business reads that account's records within the permissions it signs for, and every right in section 6 can be exercised against us. Section 4.1 names that business as the one recipient of those records, section 5.6 describes the transfer when the business is outside the Republic of Korea and the consent it rests on, and section 10.1 notes the business's confirmation about children. The old 2.5 is now 2.6. Nothing changes for an account that was not opened by a business.

From 7 September 2026, version 2026-09-07-v17 of the Privacy Policy replaces 2026-09-07-v16. One row joins the table in section 2: after you create an account you may answer three questions (how you heard of NMTS, what describes you, and what you will keep) or skip them. What is stored is the answers, any free text you typed, and the day; nothing in it points at your account. It is kept as statistics for our own interest. Nothing else changed.

From 7 September 2026, version 2026-09-07-v16 of the Privacy Policy replaces 2026-09-06-v15. One row of the retention table in section 2 changes: a session record was kept for 24 hours after last use for everybody, and is now kept for the sign-in length you choose when you sign in, from 1 hour to 30 days (24 hours if you choose nothing), and in every case ends 30 days after it was made. Nothing else in the policy changed.

From 7 September 2026, version 2026-09-07-v15 of the Terms of Service replaces 2026-09-06-v14. Section 4.1 now says credits are lent to you without charge, give no ownership and have no money value, may be moved between your account and the AI accounts under it and nowhere else, and that a counting or pricing mistake is corrected in credits rather than compensated in money. Section 4.2 counts the weekly trial for your account and its AI accounts together. Section 4.3 describes the deposit as the figure you choose when you upload, up to 64 credits, and what a file without a deposit pays when its storage is released early. Section 7.4 says the credits spent on a file whose storage object goes missing are not returned.

Section 3.5 adds that an AI account is for you alone: it is not made to be handed to another person or used by several people under your account, because it was not developed for that and such use can create risks. Your account and its AI accounts are counted together for the trial, the human check and the daily limits.

From 6 September 2026, version 2026-09-06-v14 of the Terms of Service and version 2026-09-06-v15 of the Privacy Policy replace 2026-09-06-v13 and 2026-09-06-v14. The only change is the name of the secret that opens your account: what the documents and the product called your account code is now your NMTS key, and the wallet made from it is the NMTS key wallet. Nothing about what the key is, what it opens, what we hold or what happens if you lose it has changed, and the secret itself is the same 160-bit value you already have.

The command-line tool keeps every flag, environment variable and file format under its old name, so scripts keep working; only its sentences say NMTS key.

From today you can make AI accounts under your own account: full accounts whose code is made in your browser — up to three, each able to make three of its own, twelve in all, every code derived from the one above it so your own code restores them all, with nine creations and nine deletions a day across them, and a one-time human check plus a short computation when you first turn it on. Terms 2026-09-06-v13 says so in section 3.5 and what a stop on one of them means for the account that made it. Privacy Policy 2026-09-06-v14 adds to the account row that we keep which of your accounts made an AI account and when. Nothing else changed; you are asked to accept the new versions on your next sign-in.

From 6 September 2026, version 2026-09-06-v12 of the Terms of Service and version 2026-09-06-v13 of the Privacy Policy replace 2026-08-24-v10 and 2026-08-24-v11. The versions announced on 3 September for 10 September never take effect; everything true in them is in the new ones. You are asked to accept the new versions on your next sign-in; until you do, the version you last accepted remains your agreement and only the requests that hand us something new are refused.

What changed in the writing. Each document now says only what a statute with a penalty requires and what the product actually does: the privacy policy is a table of what we hold, why, for how long and on what basis, plus who receives it, what leaves the country, your rights, the breach notice and how to complain; the terms are twelve short sections. Sentences that described our own mechanisms, repeated a fact, or promised something no law demands are gone.

Promises we no longer make: a waiting period before a new version applies (a version is posted here with its date and applies to you when you accept it); a free-exit window after a change; a shutdown notice period; response times; the 14-day account-restore after a stop. Your rights under the law where you live are untouched, and a consumer in the EU, EEA or UK keeps the 14-day withdrawal right, which the terms now state in one sentence.

Facts that are new since the last version and now written down: the hall of fame for gifts and the standing share of WAL payments (terms 6); the 64-credit hold on every credit-paid file, in place since 4 September (terms 4.3); questions and account creation from the CLI, with the redacted run log and the daily summary to our mailbox at Proton AG (privacy 2.1 and 5.3); API keys listed and revoked with the account code (terms 3.4); the six breach events Korean law names from 11 September, and that the notice reaches you on this board within 72 hours (privacy 9).

On 10 September 2026, version 2026-09-10-v11 of the Terms of Service and version 2026-09-10-v12 of the Privacy Policy replace 2026-08-24-v10 and 2026-08-24-v11. Most of the changes correct sentences that described the software wrongly, the way the last version did. Some of them are different: they change what the software does, and each of those closes a hole where a measure, a sign-out or a deletion did not hold. You can end the agreement free of charge within 30 days — it is set out at the end of this notice.

Signing a device out from somewhere else now takes the device off the account. Until now it ended that device's session, and a device you had asked us to remember signed itself straight back in on the next page load, because the wrapped account code was still on its disk. The screen said the device had been signed out, and for a remembered device that was not what happened. From this version the server records that a session was ended rather than that it expired, and a remembered device that is told its session was ended forgets what it was remembering. An ordinary expiry still does nothing of the kind — you are not asked to type your account code again every day. Nothing is kept for longer because of this: the session row is removed on the same schedule as before.

A suspension no longer washes off by deleting the account and making it again. If we stop serving an account under sections 12.5 or 12.8, the measure lived in the account row and died with it — and an account identifier is derived from your account code, so the same person could delete and re-create and be back. From this version the measure is recorded on its own and outlives the account, exactly as a board bar already does and for the same stated reason. The row holds which account, which reason, and the day it ends where there is one. It holds nothing you wrote. The Privacy Policy no longer counts what deleting your account does not reach: it names each such record and says why it outlives the account, and this measure is one of them.

What happens to your deletion if we ever restore from a backup. A restore brings the database back as it was when the copy was taken, so an account deleted after that copy would come back alive — and nothing would have deleted it again, because we keep no list of deletions and that is deliberate. From this version we find those accounts a different way, without writing anything new down about anyone: before the service opens again we compare the accounts in the restored copy against the accounts in the newest copy we hold, and an account that is in the older one and not in the newer one is deleted again, through the same code your own deletion runs. What that still cannot reach is a deletion made after the newest copy we hold. Copies are written hourly, so that is the width of what is left, and section 8-A says so rather than rounding it off.

A second Sui node service, and why you are hearing about it before it starts. Your browser reads the blockchain through an RPC service, and the Privacy Policy names the ones we chose and promises to say here, before the change, if any of them changes. From this version there are two: Suiscan, a product of Staketab, which is asked as it is today, and PublicNode, operated by Allnodes Inc., which is asked only for a request Suiscan did not answer — no reply at all, a failure on its side, or a refusal for too many requests. That last one can happen while Suiscan is healthy. Once a request has gone to PublicNode, the part of the app that made it keeps asking PublicNode for as long as that part lives — a part built once for the page lives until you reload it or open NMTS again; a part built for one action, an upload for example, starts again at Suiscan each time — including after Suiscan is healthy, because nothing goes back to check. The second service exists so that reading a balance or paying for an upload does not simply fail while the first is down. What reaches whichever one answers is what reached the first one before: your IP address, your wallet address, and the contents of the transactions you sign or the balances you read. Neither of them can read a file. The command-line tool and the recovery tool carry the same pair.

A daily check on the storage we bought for you, and a record when it is gone. For an upload paid with credits, our treasury buys the storage. From this version our server takes a sample of that storage once a day and asks the chain whether it is still there — and asks again, every day, about each object it has already missed. Where the chain answers that it no longer knows an object, a row pairs your account with that object and the day the check first could not find it, the drive shows it to you, and this board posts the day's finding from that record without naming anyone. A day the chain could not be read writes nothing, and an object the chain knows but we could not recognise is counted for us to look at, not written against you. A row comes off when a later check finds the object, twelve months after the first miss, or with your account; the incident itself stays in a register that names the object and not you. If you would rather not be shown losses on one purchase, or on any of yours, you can say so: we take the line down and write no more of them against you, except where the law itself requires that you be told of a high-risk incident, and the machine makes that judgement before anyone else does. The Privacy Policy describes it in sections 2.8, 5.1, 8, 10.6 and 13.6.

Keys you can issue to a program, which the documents did not list. Since 23 August an account can issue API keys — credentials for a program acting for you, such as an assistant or a script. The Privacy Policy calls its section 2 the complete list of what our server holds, and the keys were not in it. They are now, in full: what a key row holds, what the human check that lifts a key's tighter limits holds, that the short code you type is stored only as a hash, and that the counter of accounts created through a key records how many and not which. So are the retention periods: a key lives at most 90 days and for as long as you chose within that, a revoked or expired key is kept a further 30 days so that a program waking up later is told the key was revoked rather than that it never existed, and all of it goes when you delete your account. The Terms add two paragraphs: what handing your account code to a program actually gives it, and that a key is the way to avoid doing that. A key cannot open your files.

The support inbox, and a protection we had not written down. Since 9 August the text of a support message has been sealed inside the database under a key our server holds. The Privacy Policy listed the places we hold a key — the connection and the backups — and closed that list by saying there was nothing else. The inbox was a third. The new version names it, and says exactly what the sealing does and does not do: a copy of the database on its own does not open it, and the key is on the server, so it protects the message from someone who takes the database and not from someone who takes the server.

The length we store for a piece of a file. The Privacy Policy said we hold the plaintext length of each storage part. Since 18 August we hold the sealed length instead — the number of bytes actually stored — and the plaintext number is not recorded at all. The two differ by an amount that depends only on the size: sealing adds a 72-byte header once per part and a 16-byte authentication tag for every 4 MiB inside it. The document claimed more collection than happens; the new version says what is really there.

The recovery list — its name, and a setting that was missing. What the documents called the recovery map has been called the recovery list in the product since 17 August; the documents now use the product's name. And the account record carries one setting the Privacy Policy did not list: whether you asked for your recovery list to be stored on the storage network alongside your files, so that your account code alone is enough to recover them. It is off unless you turn it on, because turning it on buys storage paid from your own wallet, and we will not put you to an expense through a default you never looked at.

Releasing storage you paid for with credits. The Terms described this as something you email us about. A screen has done it since the button shipped: you ask on the file's own screen and we destroy the storage object and show you the transaction. The new version says so, keeps email as the fallback, and names the fee that request may carry — it is 0 today, and the screen states the figure before you confirm, so the number charged is the number you were shown. It also says plainly that releasing the storage and deleting the file are two separate acts.

Two smaller corrections, and some sentences taken out. The encryption engine's published source moved from the GNU Affero General Public License v3.0 to the Apache License, Version 2.0 on 30 August; both documents name the licence, and the name is what changed — the sentence's job, and what publishing does not prove, are the same. The Terms' account-deletion section said one record is not deleted; there are several, so the section now lists what deletion removes, and the Privacy Policy's retention table names what outlives the account. The European 14-day withdrawal right now says what it does not undo: a gift you already sent, because it is a right to withdraw from a purchase and a gift is not one — what a law you cannot contract out of gives you about a gift is untouched, and a gift made by a minor is the case that clause is written for. We have also removed eleven sentences in which we praised our own honesty rather than saying anything: they were not obligations and not facts, and a document is easier to trust with them gone.

Where our own server reads the chain from this version, and why you are hearing it before it starts. Your browser's calls do not move: Suiscan, PublicNode and the Mysten Labs relay and aggregator stay as named. The calls our server makes that name a storage object of yours — the payment for a credit-paid upload and the release of that storage, the daily check on the storage we bought and a re-check you ask for — go from this version to a Sui RPC service run by Nodeinfra Co., Ltd., a company in Seoul, Korea, answering from servers in Germany; and the read our server makes to measure whether a stored piece is really there goes to a Walrus aggregator run by Bware Labs, a company in Bucharest, Romania, answering from servers in Germany. What our server asks about our own wallet and about public prices — balances, which coins to pay with, the price of storage — still goes to Suiscan, the one Sui RPC service our server is configured with for that; the price of storage is read once more through Nodeinfra while a payment is being built. Our server has no fallback service: when the service a call is made to does not answer, that call fails; the switching between Suiscan and PublicNode is your browser's, not our server's. On the main network our server software refuses to start unless it has been given exactly these services, so the destinations named here are not left to a setting. Privacy Policy 9.4 names each of them and says why: Korea is a country the European Commission has found adequate, and Germany is inside the European Economic Area, so those calls no longer rest on a ground the policy had to hedge. The one leg that carries only our own wallet address and public prices goes to Suiscan, whose operator does not publish the country its infrastructure runs in, so the policy states none for it. The policy promises to say here, before the change, if any of these services changes; this is that telling.

What the last check changed. Before this notice, every citation in both documents was matched against the text of the law it cites, and that check moved some sentences. The United Kingdom is now named wherever the documents spoke of the European Union and meant both — the withdrawal right, the transfer rules, the complaint routes — and the British provisions are cited by their own names, because they stopped matching the European ones this year. A stopped account keeps the way to its files: with your account code and a saved recovery list, the recovery tool retrieves them from the storage network without us; if you saved none, you write to us with your public code and we serve the account again for 14 days so that you can download them, at no charge, and then the stop resumes. The sentences that said the recovery tool did not exist yet are corrected — it has been published since 17 August. A notice of an incident on this board stays up for at least 30 days, not 15, the period the Privacy Policy already gave. A report of material that sexually exploits children needs no contact details. Where a binding legal order requires a measure the Terms do not otherwise take, we follow the order. And the sentence promising the law and the courts of your own country now says where the sources we hold back it — the European Union, the United Kingdom and Korea — and leaves the rest to your own country's rules.

The 30-day right, and where to read. You can end the agreement free of charge within 30 days of the later of 10 September 2026 and the day this notice first reached you. Ending the agreement does not touch your files — Terms 16.2 — and 15.6 says what it does and does not do. Both documents are on the site in English and in Korean; from 15 September the new versions stand in their place, and the versions they replace stay published with their effective dates. The button at the top of this notice saves it as a dated file in both languages, and nmts@nmts.me will send the exact text of any version within seven days.

On 24 August 2026, version 2026-08-24-v10 of the Terms of Service and version 2026-08-24-v11 of the Privacy Policy replace 2026-08-11-v9 and 2026-08-11-v10. Every change in them corrects a sentence that described the software wrongly. Not one of them changes what the software does: no new data is collected, nothing is kept longer or shorter than it already was, and no setting of yours moves. We are giving the 30-day right to end the agreement anyway — it is set out at the end of this notice.

Two things we said we kept longer than we do. The Privacy Policy's retention table said a notice in your notice box is kept "while the account exists"; each notice is in fact deleted 12 months after it was made, and the new version says so and says why that period. The same table said an under-14 board bar "has no end"; it is in fact deleted 5 years after it was made, and earlier than that on the day we lift it because you have told us you have turned 14. In both cases the software was already deleting on the shorter schedule. The document was wrong, not the code.

Two things we said were deleted with your account, and are not. The quote ledger — which post of yours we quoted, where, when, and when we took the quotation down — outlives both the post and the account, because a promise to take a quotation down cannot be kept by a record that dies first. It holds no nickname and no account identifier. A board bar standing against an account also outlives the account, up to the dates above: an account identifier is derived from your account code, so a bar that died with the account could be washed off by deleting the account and creating it again. Both were already true; the old text said otherwise, and that is the more serious of the two directions this notice corrects.

A second decision taken by machine, which the Privacy Policy did not list. It said one decision about you is taken by machine — the board clock that restores or removes reported content when nobody has decided in time — and that nothing else is. There is a second: a report you sent that is still open 12 months after it arrived is closed on that day by the machine, whether or not anybody told you the outcome, and your contact address is erased in the same step. If you reported from an account, the closing lands in your notice box and says the period ended rather than claiming a judgement nobody made; if you left only a contact address, nothing reaches you. The new version sets out both decisions in full, and also states what the board clock reads that the old text left out: whether a copyright procedure or a court case is recorded against the content, which stops the clock entirely, and whether a rebuttal is standing beside it.

One outbound call we make that was not on the list. The Privacy Policy lists every call our machines make to another company. Since 11 August our server has also read a single number — how many people are connected — from Discord's public information about our own Discord server, at most once every five minutes, so the page about our community can show it. It carries nothing about you. Your browser does not talk to Discord: we deliberately did not place Discord's own panel on the page, because that panel would make every visitor's browser connect to Discord and hand it their address. The new version adds the call to the list.

What publishing the source does, and what it does not. Both documents said we publish the format so that it can be checked. Since 15 August the encryption engine's source, the boundary that exposes it to a browser, the format specification and the conformance vectors have been published at github.com/needmoretruth/nmts-crypto under the GNU Affero General Public License v3.0. The new versions name that, and then say the thing the old sentence let you assume: reading that source tells you what a browser should receive, not what yours received. We do not yet build the software so that anyone else could repeat the result byte for byte, and we publish no fingerprint of each release. We have also removed the sentence saying we intend to publish reproducible builds — we would rather carry no dated promise than one we keep moving.

Expiry dates, said more precisely. The Terms said the dates the product shows for an expiry are estimates and that the product labels them as estimates. Where the product can only work out a floor it now shows the floor and says so — "at least N days left", "on that date at the earliest" — and a floor is not an estimate: the real end is that day or later, never earlier. The new version says that instead. The product has behaved this way since the fix went out; the sentence had not caught up.

The 30-day right, and where to read. None of this changes what the service does for you, and we are giving the 30-day right to end the agreement anyway: you can end it free of charge within 30 days of the later of 24 August 2026 and the day this notice first reached you. Ending the agreement does not touch your files — Terms 16.2 — and 15.6 says what it does and does not do. Both documents are on the site in English and in Korean; from 24 August the new versions stand in their place, and the versions they replace stay published with their effective dates. The button at the top of this notice saves it as a dated file in both languages, and nmts@nmts.me will send the exact text of any version within seven days.

NMTS now has a board: a public place inside the product where you can write and read. It is off until you open a board profile. Opening one puts the NMTS Board Terms — version 2026-08-11-v8, their first — in front of you as their own document, with their own acceptance; nothing on the board happens to an account that has not accepted them. Posted notices are never edited; each correction is a new entry, and this is the fourth.

The date, and the names. The versions announced as 2026-08-16-v8 and 2026-08-16-v9 take effect today, 11 August 2026, under the labels 2026-08-11-v9 (Terms of Service) and 2026-08-11-v10 (Privacy Policy) — a version's name carries its effective date, so the names move with the date. They replace 2026-08-04-v7 and 2026-08-04-v8, which have been in force since launch. The text is what the earlier notices described, and the board is what has been added to it.

What the board adds, stated plainly. The board is the one part of NMTS where what you write is held on our server in readable form — that is what a public board is, and the Privacy Policy now has a section (2.12) listing every record it keeps and for how long. Your nickname is public; your posts and comments are public and readable without an account. Every post and every comment carries a report button, and the Board Terms say what it does, who hears the outcome and in what time. Nothing about the board touches your files, your credits or your wallet.

Two switches, and both start off. Quoting a post of yours where we promote NMTS, and displaying the storage mark, are the only two things in NMTS that stand on your consent. Each is off until you turn it on, each can be turned off in the same place at any time with no reason given, and turning either off costs you nothing — the board works the same afterwards. Turning the quoting switch on applies only to what you write afterwards; it does not reach back.

The 30-day right is unchanged, and we count it the way we promised. The previous notice said the 30-day right to end the agreement applies to this change, counted from the later of 16 August and the day that notice first reached you. Bringing the effective date forward does not shorten that: we still count from 16 August 2026, or from the day the notice reached you if that is later. Ending the agreement does not touch your files — Terms 16.2 — and 15.6 says what it does and does not do.

Where to read. All three documents — the Terms of Service, the Privacy Policy and the Board Terms — are on the site from today, in English and in Korean. The button at the top of this notice saves it as a dated file in both languages, and nmts@nmts.me will send the exact text of any version within seven days.

This notice changes the effective date of the announced revisions, corrects the record of when the first notice was published, and announces product changes shipped on 8 August. Posted notices are never edited — each correction is a new entry, and this is the third.

The date, and the names. The versions announced as 2026-08-13-v8 and 2026-08-13-v9 take effect on 16 August 2026, under the labels 2026-08-16-v8 and 2026-08-16-v9 — a version's name carries its effective date, so the names move with the date. The text is what the earlier notices described, with the further revisions named below. The reason for the move is the paragraph that follows.

About the date the first notice carries. The notice dated 6 August was written that day, but it first became readable on this site at 09:29 UTC on 8 August 2026 — a deploy delay. The date on a notice should be the date it was posted, and there it is the date it was written; we are correcting that record here. Counted from the real moment it reached the board, the period before a 13 August effect would have been four and a half days. The new version promises at least seven days of notice (15.3), and we would rather keep that promise from the start than explain a shortfall — so the date moves to 16 August, which is more than seven days after the notice actually appeared.

This revision is a material change, and we say so. The version in force refuses requests only after a material change; this revision changes the refusal rules themselves, and we treat that as material — the refusals that begin on 16 August stand on that clause of the version you accepted. That is a different test from the 30-day right's "more than a minor way", which stays yours to judge; and to leave no doubt, we state plainly that the 30-day right applies to this change, counted from the later of 16 August and the day this notice first reached you.

One more thing the new text spells out: a new version of the Privacy Policy alone has the same effect as a new version of the Terms — the four requests wait until the record that you were shown the new pair has been made. That has always been how the software works; the documents now say it.

Product changes shipped on 8 August, under the current terms' change rule. First, large files can now be paid for with credits — the version in force still says credits cover files up to 64 MB each; the software no longer has that limit, and the 16 August text describes the new rule. Two ceilings protect the funds that sign those payments: 2,048 credits per file, and 4,096 credits per account per day — the daily ceiling is a new restriction, and it is why this paragraph exists. Second, the support form now starts with diagnostic facts about the software attached (what your browser says about itself, and which build you run); "send nothing" is one press away, and your file list still waits for your own tick — the versions in force describe the old default, and the 16 August text describes this one. Third, a credit-bought file gains an "upload again with my wallet" path, which is how you keep such a file past its fixed term. And one record we have always kept is now written down: when we edit or remove a message of ours in a support conversation, the time of that is recorded.

Where to read. Until 16 August the site shows the versions in force today; write to nmts@nmts.me and we will send the exact text of any version, including the one taking effect, within seven days. The button at the top of this notice saves it as a dated file in both languages.

This notice corrects and completes the notice of 6 August 2026. A posted notice is never edited — a correction is a new entry, and this is that entry. Nothing here moves the date: the new Terms of Service (2026-08-13-v8) and Privacy Policy (2026-08-13-v9) still take effect on 13 August 2026.

The correction. The 6 August notice said: “everything you could do under the old versions you can do under the new ones, on the same terms.” In one respect that was not accurate, and we withdraw the sentence rather than defend it. The version in force today says requests are refused only after a “material” change, and names five: upload, share, rename, restore from the trash, extend. The new version refuses a short list after every new version, until your acceptance of it is recorded. Read side by side, the new version is stricter about when a refusal can happen, and different about what is refused — the previous notice should have said so plainly.

What is actually refused, finally. Renaming, restoring from the trash and recording a storage extension are refused in no case — the software opened those three on 6 August and they stay open. Applying for free credits is open too: the release that carries this notice opened it, so waiting to accept a new version can no longer cost you a weekly application. What the new version refuses until your acceptance is recorded is four things: uploading a file, creating a share, publishing your sharing identity, and entering the preview build. The last two never appeared in the old version's list although the software always refused them — what changes on 13 August is that the document finally says so. The screen that asks for your acceptance used to say the opposite (that renaming, restoring and extending are refused); that screen text was wrong, and the release that carries this notice fixes it.

Your 30 days, stated correctly. The 6 August notice described a right to end the agreement free of charge “within 30 days of a new version taking effect.” The final text counts those 30 days from the later of the day the version took effect and the day its notice first reached you — a notice you have not seen cannot start your clock. Does the right apply to this change? We think this change does not affect your use in more than a minor way — it takes nothing away, and it opens things the old text said were refused. But that judgement is yours to make, not ours: if you see it otherwise, write to nmts@nmts.me and we will not argue about the deadline.

Two changes the 6 August notice did not mention. First, the current terms promise to announce only “material” changes before they take effect; the new terms announce every new version before it takes effect. Second, entering the preview build now stands in the terms as a third separately recorded consent, next to the recovery-map confirmation and auto-approval arming — the warning you agree to there is recorded by its version.

The final text was revised again before taking effect, after an adversarial legal review. The section on ending the agreement now says in one place what ending does: it means deleting your account, which destroys the encrypted file list and the wrapped keys we hold; a storage term you already paid the network for is not refunded and keeps running; so download what you want to keep first. It also states that none of this narrows your standing right to delete your account at any time, free, and that while you have not accepted a new version, the version you last accepted remains the agreement between you and us. In the Privacy Policy, the definition of “encrypted” now names, in the same sentence, the only two places we hold a key — the connection and our database backups — and the policy's legal-basis table now carries a line for the preview-channel record. Both documents now use the product's own words for upload and download. And the acceptance record keeps one row per version pair, so accepting the same version twice adds nothing. Until 13 August the site still shows the versions in force today; write to nmts@nmts.me and we will send you the exact text of any version, including the one taking effect.

The download button. The 6 August notice said “the button at the top of this notice”; the button was in fact at the bottom. From the release that carries this notice, every notice carries the save button at the top as well, and the screen that asks for your acceptance also offers the notice as a dated file made out for your account, naming the versions in force, the versions you last accepted, and your right under section 15.6.

On 13 August 2026, Terms of Service 2026-08-13-v8 replaces 2026-08-04-v7, and Privacy Policy 2026-08-13-v9 replaces 2026-08-04-v8. Both of the old versions have been in force since launch. The new ones correct passages that stopped being true after we published them, add one clause, and change the wording of a term used throughout. Neither takes anything away from you: everything you could do under the old versions you can do under the new ones, on the same terms.

What four passages of the Terms say now, and what they will say. Two of them state that the service is at version 0.0.1; it was at launch, and it is at 0.10.0 on the day of this notice, so the new text says the version number is below 1.0 and points at the two places the product shows the exact number. One says your acceptance of the terms is recorded once, when your account is created; since 6 August it is also recorded each time we publish a new version and you accept it, and each record is kept rather than overwritten. The last says a screen that offers you a new version and takes your acceptance is not built yet, and asks you to write to nmts@nmts.me instead; that screen was built on 6 August, so the new text describes it and drops the request to write to us.

The words change in both documents, and the meaning does not. Until now both documents called an encrypted record “sealed” — a word the product itself no longer uses anywhere. Both now say “encrypted”, and the Privacy Policy defines it where it first appears: encrypted in your browser with a key we do not have. Two other things are encrypted with keys we do hold — the connection to our server, and our backup copies of the database — and those two always carry the word “connection” or “backup”, so the difference is never left to the reader to work out. In three places in the Terms the old word did not mean encryption at all: it meant paying for storage, or uploading. Those places now say so. No obligation, limit or right changes with any of this.

One clause is new. Section 15.6 sets out the only reasons we may change these terms — correcting something that has stopped being true, following a change in the law or in a ruling that binds us, following a change in the storage network's rules, formats or prices, describing a feature we added, changed or removed, or making an obligation of ours clearer or stronger — and states that we do not change them to take away a right you already have under the version you accepted. It also gives you 30 days from a new version taking effect to end this agreement free of charge, if that version affects your use in more than a minor way. Until now the Terms said why we may change the service (5.6) but not why we may change the Terms themselves.

The Privacy Policy changes for one reason. Its section 2 says it is the complete list of what our server holds, every kind of record and not a selection. On 5 and 6 August we added a table that records which accounts have entered the preview build — that your account is on it, the label of the warning you agreed to, the release your browser was running when you entered, the release that returns you to the ordinary build, and when. It holds nothing about what you do there, and it is deleted with your account. The new version lists it in the four places the policy enumerates what we hold, how long we keep it, what deleting your account removes, and what we hand back on request. Nothing about the way we handle anything else changed.

What you will see on the day. When you sign in on or after 13 August, the acceptance screen comes before the rest of the product. It names the version in force and the version you last accepted, links to the full text of both documents and to this board, and takes your acceptance with a tick and a button. Beside that button is one that puts it off. Until you accept, five requests are refused: uploading a file, creating a share, publishing your sharing identity, applying for free credits, and entering the preview build. Everything else goes on working — reading your drive, downloading your files, deleting them, emptying the trash, restoring one from it, renaming and rearranging what you already hold, recording an extension your wallet has already paid for, undoing a share, writing to the support inbox, and deleting your account. You may keep and take away everything you already have without accepting anything.

Your rights, unchanged. Storage you have already paid for stays governed by the version you accepted when you paid for it, until that term ends (15.4). The full text of the version in force is at nmts.me/terms; we keep every version we have published and will give you any of them if you ask at nmts@nmts.me (15.2). The button at the top of this notice saves it as a dated file in both languages, so what you keep is a copy and not a link. If anything here is unclear, the support inbox inside the product reaches us.