diff --git a/97.md b/97.md
new file mode 100644
index 0000000000..5ae69cfbdf
--- /dev/null
+++ b/97.md
@@ -0,0 +1,100 @@
+NIP-97
+=======
+
+Ring Signatures
+---------------
+
+`draft` `optional`
+
+This NIP describes a protocol to associate any standard nostr event with a ring signature of is content field, as introduced by Rivest, Shamir, and Tauman in their 2001 paper "How to Leak a Secret" [1].
+
+## Background and Motivation
+
+In the original paper, Rivest, Shamir, and Tauman use the example of "a high-ranking White House official" who wishes to leak a secret without revealing which official signed the message.
+
+Suppose that a set of entities each have public/private key pairs, (pk1, sk1), (p21, s21), ..., (pkn, skn). Party _i_ can compute a ring signature σ on a message `m`, on input (`m`, `ski`, `pk1`, ..., `pkn`). Anyone can check the validity of a ring signature given `σ`, `m`, and the public keys involved, `pk1`, ..., `pkn`.
+
+## Requirements
+
+A ring signature event must meet three requirements:
+- a content field which contains the message `m`, the message to be signed by the ring signature
+- a `ring-signature` tag that identifies the event as a Ring Signature event and that contains the ring signature `σ`
+- One `ring-members` tag which contains an array of all public keys (`pki`) in the ring.
+
+### Event kinds
+
+Any event kind that utilizes the content field (e.g. kind 1, 30023 (long form), 30818 (wiki), etc.) can make use of this NIP. However, this NIP also introduces a new event kind, kind 2001, which may optionally be used to link a pseudonym to a list of signatories, as described below.
+
+## Usage
+
+Suppose nostr user Alice with `pk_Alice` wants to leak a secret `m` without revealing her pubkey, other than that `pk_Alice` is an element of some set `S` of (presumably well-known and highly regarded) pubkeys [`pk1`, `pk2`, ..., `pkn`]. She will use `pk_Alice` to generate the ring signature `σ` but will create a throwaway ring signature pubkey `pk_ring-signature` to wrap the secret in a nostr event as in the examples below.
+
+## Examples
+
+Generic example:
+```json
+{
+  "content": "secret message",
+  "kind": 1, // or 30023 (long form), 30818 (wiki), etc
+  "tags": [
+    ["ring-signature", σ],
+    ["ring-members", [<pk1>,<pk2>, ..., <pkn>]],
+  ],
+  "pubkey": "<pk_ring-signature>"
+}
+```
+
+In this example, Alice holds the private keys to `pk_Alice` and to `pk_ring-signature`. `pk_Alice` is one of the `pkn`. The public will know (can verify cryptographically) that `σ` was generated by one of the `pkn` but will not know know which one.
+
+**One-time use:**
+
+In the base case, `pk_ring-signature` is used for this one event without the intent of reuse:
+
+```json
+{
+  "content": "I'm a cabinet member of Trusted But Corrupt Organization. In this note, I will spill the beans and tell the whole store from start to finish ...",
+  "kind": 1, // or 30023 (long form), 30818 (wiki), etc
+  "tags": [
+    ["ring-signature", σ],
+    ["ring-members", [<pk_cabinet-member_1>,<pk_cabinet-member_2>, ..., <pk_cabinet-member_n>]],
+  ],
+  "pubkey": "<pk_ring-signature>"
+}
+```
+
+**Repeated use:**
+
+If Alice decides to create a Ring-Signature-linked pseudonym for repeated use, she uses kind 2001 to "announce" her pseudonym, as in this example:
+
+```json
+{
+  "content": "I'm a cabinet member ... This is the first in a series of notes, all of which will be signed by this pubkey (pk_ring-signature), in which I spill the beans on ...",
+  "kind": 2001,
+  "tags": [
+    ["ring-signature", σ],
+    ["ring-members", [<pk_cabinet-member_1>,<pk_cabinet-member_2>, ..., <pk_cabinet-member_n>]],
+  ],
+  "pubkey": "<pk_ring-signature>"
+}
+```
+
+In this case, `pk_ring-signature` evolves from a simple throwaway to become a bona fide pseudonym. Note that `pk_ring-signature` is referenced in the content field and is therefore included within the ring signature message `m`.
+
+## Nostr Relays and Clients
+
+A strength of this implementation is that relays and clients that do not support RS will nevertheless store, transmit and process them in the usual fashion, including display of content.
+
+Relays and clients that do support this NIP will do so in the following ways:
+
+### cryptographic validation of the ring signature (REQUIRED)
+
+### Web-of-trust score for the Ring Signature Pubkey (OPTIONAL)
+
+Given an appropriately selected web of trust (WoT) scoring method, calculate a trust score for the `pubkey_ring-signature`, a "ring signature WoT score" RS_WoT, which is the _minimum / lowest / worst / most untrustworthy WoT score for all pki in the set S_. RS_WoT is effectively the "weakest link" of all the pubkeys in S. Users may wish to filter and discard as probable spam any RS event based on RS_WoT. But if RS_WoT is high-trust, and if Alice wishes to maintain `pk_ring-signature` as a pseudonym for repeated use, then RS_WoT can be used as a floor upon which to build a reputation. Note: in this scenario, it is also essential for `pk_ring-signature` to be included within the signed message `m` to prevent any rando from attempting to appropriate the reputation of RS_WoT by republishing the RS. (See the Repeated Use example above, where `pk_ring-signature` is included in the signed message `m`.)
+
+### Non-WoT methods for spam prevention (OPTIONAL)
+
+PoW ([NIP-13](./13.md)) for spam prevention, since in standard used cases `pk_ring-signature` will be unknown and unvetted by WoT, thus making spam prevention by other means difficult.
+
+## References
+[1] Rivest, Ronald L.; Shamir, Adi; Tauman, Yael (2001). "[How to Leak a Secret](https://link.springer.com/chapter/10.1007/3-540-45682-1_32)". Advances in Cryptology — ASIACRYPT 2001. Lecture Notes in Computer Science. Vol. 2248. pp. 552–565.