- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.
Relays MAY notarize events by supporting a `NOTARY` message.
- First a client sends a `NOTARY` message to the relay with an event id as the first argument.
- Next, the relay MAY respond with a `NOTARY` message with the same event id as the first argument and a timestamp matching when the relay first saw the event as the second argument.
- If the relay has not seen the event it SHOULD respond with `null` in the timestamp field.
Note that relay-provided notaries provide a weaker guarantee than OTS proofs. Depending on the importance of the verification, multiple relays with a good reputation should be consulted in order to determine a reasonable result.
# Peer Notaries
Users MAY notarize events by publishing a `kind:4341` event. `content` MAY provide any human-readable explanation of the event. One or more `notary` tags MUST be included indicating event ids and timestamps. Event addresses MUST NOT be used.
```jsonc
{
"content": "I vaguely remember hearing about this note last year",
Note that user-provided notaries provide a weaker guarantee than OTS proofs. Depending on the importance of the verification, multiple users with a good reputation should be consulted in order to determine a reasonable result.