Docs / Drafts

Drafts

The forms of a new problem, a revision of your problem, a topic (a proposal or a revision) and a result save what you type as a draft, about two seconds after each change. You can close the page and continue later, on any device you sign in with: the form opens with your draft. Your drafts are listed on Your drafts.

Who can read a draft

A draft is private on the site: no page, search, feed, API or MCP tool shows it to anyone else, editors included. It is not encrypted, though: it is stored in plain text in PubPhys's database, so the people who operate PubPhys can read it, as they can read anything else stored on the site. Do not put in a draft what you would not show them.

A draft is never signed, stamped, written to the public log or sent to AI. The text sent to AI is what you upload for the AI proposal (with your consent, AI at PubPhys) and what you sign; a draft itself is not. Files you upload are different: a problem's file, or a result's source files, become records at once and stay private until a public record names them (submitting).

What is saved

• New problem: one draft per problem you are writing, with its topic (or the new topic you propose with it) and its parent problems. Only what you prepared can be signed: if you change the text after preparing it, the page shows your draft and asks you to prepare again.
• Revision: one draft per problem you revise, with the revision it was written over. If the problem is revised meanwhile, the form says so and compares your text with the latest revision.
• Topic: one draft per topic you revise, and one new proposal per field.
• Result: one draft per problem, with the earlier results it builds on and which source files you chose. A draft does not keep a file alive: a source file not used in a signed result within 7 days is deleted, and the form then says it expired and asks you to upload it again.

The box confirming that you sign and the boxes allowing AI screening are never saved: you tick them again each time.

Limits

At most 50 open drafts per account, and 200 kB of text in each. A form over a limit says so and is not saved until you delete a draft or shorten the text.

Two tabs, one draft

Each save names the version it was made over. If you edit the same form in two tabs, the first to save wins; the other is told that the draft changed and stops saving, so it never overwrites the newer text. Reload it to continue from the saved draft.

Signing in one tab marks the draft of what you signed as used and clears its text, even when another tab holds a newer version of it. That tab can no longer save, and whatever it shows beyond what you signed is lost unless you copy it first.

When a draft ends

• Signed: when you sign the record the form builds, its draft is used up and its text deleted; the signed record takes its place. Signing never needs a draft, and a draft never stops you from signing.
• Deleted: you can delete a draft on Your drafts, at once and for good. Abandoning a new problem deletes its draft too.
• Sealed: sealing a draft (below) signs its record and clears the draft's text.
• Account deletion deletes all your drafts.

Sealing

A draft of a new problem or of a result can be sealed instead of published: tick "Seal it instead of publishing" in the form and sign with ORCID. The browser builds exactly the record publishing would, with a random 256-bit nonce inside the content, and the record goes into the public log at once. The log shows only its type. The record, its content and its files are served to you alone until you reveal it: no editor, admin page, search, feed, API or MCP tool shows them. A problem proposed with a new topic cannot be sealed: publish the topic first, or choose an accepted topic.

Sealing protects priority, not privacy from the operators. The sealed content is stored in PubPhys's database, which its operators can read.

• The seal date is the sealed record's earliest valid Bitcoin confirmation, never the time written in it. Until that confirmation is in, your Drafts page says "Bitcoin confirmation pending".
• Limits. At most one unrevealed sealed result per problem, none while you have a result on the problem, and no result while you hold one; at most 10 unrevealed seals, and 20 seals in 30 days.
• While you hold a sealed result on a problem, you cannot decide on that problem's results, contests, appeals or later revisions, nor remove it (who is excluded from what). Nobody else is told why: the seal stays private, and what others can infer is only
  • an editor who does not act on an item, which looks the same as an editor who chooses not to;
  • the administrator's list of privately blocked items, which shows that some editor of an item is privately excluded, but not who or why;
  • an item that stays undecided longer than usual.
• Lapse and renewal. A seal lapses 12 months after its seal date. Before that, renew it from your Drafts page with a fresh ORCID sign-in of the iD that sealed it: the deadline becomes 12 months from the renewal (renewals do not add up). You are told 30 and 7 days before. A lapsed seal cannot be renewed; it keeps its slot, can still be revealed, and the item is then dated by the reveal's own Bitcoin confirmation.
• Reveal. From your Drafts page you sign a short reveal record naming the sealed one, with an optional public note. The item then goes through screening like any new one, and both records become public when it is published. For a result you choose whether AI may screen it; if it has source files, the choice made when they were uploaded applies to the result too. While the result's problem is not shown, for example while its topic is hidden, or results are not being accepted in its field, the reveal waits and you try again later; if the problem was removed, the seal can only be abandoned.
• Abandon. Abandoning is final: the content and files are deleted, the seal can never be revealed on the site and earns no priority there, and a sealed result still keeps you from deciding on that problem's results. The record stays in the log.

What a purge leaves. Abandoning and account deletion delete a seal's content and files. What stays is: the sealed record, with its salted content hash (the nonce makes a short answer impossible to find by trying guesses); the unsalted hashes of its files; the problem, for a sealed result; and the date. Attached files are bound by a plain hash, so put a short answer in the text, not in a file.

Keep the proof file of every seal (on its record's page): after a purge or a removal it is the only proof of what you sealed, and an offline proof of an unrevealed or abandoned seal still shows anyone that the record existed at its anchor, though it earns no priority on the site. A reveal is checked together with its sealed record on the verify page; see the protocol.