Release 0.2.0 (#10)

* Index statistic page.

* List of reserved named without corroborating Nostr events.

* Changelog update, update cargo.toml for v0.2.0.

* Bold the message on the uncorroborated claims screen.

* Clarifying language in the spec.

* Handle edge case where a name is being indexed twice because it was posted with the same NSID twice.

* CHANGELOG.md

* Updating SPEC to remove transfers and added an Appendix for changes and updates.

* Removing transfers from version 0x00

* Limiting names to 43 characters.

* Use Primal.net for user links.

* Index Stats was still using transfer_events table

Author: ursuscamp

.gitignore

@@ -13,4 +13,5 @@ nomen.db
 records1.json
 *.csv
 *.psbt
-release/
+release/
+*.bak

CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 0.2.0
+
+This release includes a database migration, so make sure to back up your index before upgrading.
+
+Features:
+  - Transfers have been removed, and names have been limited to 43 characters for vesion `0x00`. They will be enabled in the next version with a better designed.
+  - Primal.net is now used to npub links.
+  - New page to list blockchain claims for which there are no indexed record events.
+  - Index statistic page.
+
+Bugs:
+  - Fixed a bug where a name was double-indexed because the same `OP_RETURN` was uploaded twice
+
 ## 0.1.1
 
 Features:

Cargo.lock

@@ -1,7 +1,8 @@
 [package]
 name = "nomen"
-version = "0.1.1"
+version = "0.2.0"
 edition = "2021"
+build = "build.rs"
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
@@ -35,3 +36,6 @@ time = { version = "0.3.20", features = ["formatting", "macros"] }
 tokio = { version = "1.26.0", features = ["full"] }
 toml = "0.7.2"
 yansi = "0.5.1"
+
+[build-dependencies]
+vergen = { version = "8.0.0", features = ["build", "git", "gitcl"] }

Cargo.toml

@@ -0,0 +1,8 @@
+use std::error::Error;
+use vergen::EmitBuilder;
+
+fn main() -> Result<(), Box<dyn Error>> {
+    // Emit the instructions
+    EmitBuilder::builder().all_build().all_git().emit()?;
+    Ok(())
+}

build.rs

@@ -14,28 +14,29 @@ Indexers (like a DNS name server) link on-chain claims to published Nostr events
 
 ### Blockchain
 
-In order to claim a name, publish an output to the bitcoin blockchain in this format: `OP_RETURN <VERSION><TRANSACTION TYPE><NAME FINGERPRINT><NAMESPACE ID>`. All names have an associated owner, which just a private/public keypair. Public keys are always 32-byte X-Only Public Keys used everywhere in Nostr and Bitcoin Schnorr signatures.
+In order to claim a name, publish an output to the bitcoin blockchain in this format: `OP_RETURN NOM <VERSION> <TRANSACTION TYPE> <NAME FINGERPRINT> <NAMESPACE ID>`. The spaces are for readability and not significant. Do not include spaces in the final `OP_RETURN`. All names have an associated owner, which just a private/public keypair. Public keys are always 32-byte X-Only Public Keys used everywhere in Nostr and Bitcoin Schnorr signatures.
+
+`NOM` is just the byte string "NOM", a tag indicator to let the indexer know this ia Nomen output.
 
 `VERSION` is reserved for future use, for incompatible changes to the protocol, or unlocking additional namespace. It is one byte and must currently be `0x00`.
 
 `TRANSACTION TYPE` represents the type of claim being made on chain. It is one byte. It may be `0x00` which represents a new name being claimed, or `0x01` which represents an ownership change of the name (owned by a new keypair).
 
 `NAME FINGERPRINT` is the first five bytes of the HASH-160 of the name. The purpose is to allow a name to be verified as unreserved, even if a Nostr event cannot be found to prove it.
 
-`NAMESPACE ID` represents a HASH-160 (20-byte) hash of the ownership information for this name. If the `TRANSACTION TYPE` is `0x00` (new name) then the `NAMESPACE ID` is the HASH-160 of `<NAME><OWNER PUBKEY>`. If the `TRANSACTION TYPE` is `0x01` (ownership change), then the `NAMESPACE ID` is the HASH-160 of `<NAME><NEW OWNER PUBKEY>`.
+`NAMESPACE ID` represents a HASH-160 (20-byte) hash of the ownership information for this name. If the `TRANSACTION TYPE` is `0x00` (new name) then the `NAMESPACE ID` is the HASH-160 of `<NAME><OWNER PUBKEY>`. Please be aware that the pubkey is a 32-byte byte string of the pubkey, not any textual representation such as bech32 or hexadecimal.
 
 **Note:** The owner of the Bitcoin UTXO that generated the `OP_RETURN`, or the amount in the UTXO, do not matter. Bitcoin, in this case, is being utilized only as a decentralized timestamp server. The only thing that matters is the order of transaction outputs.
 
 ### Nostr
 
 Nostr is the propogation layer of the protocol. The only required information on-chain is the information necessary to determination ownership of a name, and that is only in a shortened hash form.
 
-There are currently three types of Nostr events. These are all parameterized replaceable events (all events are idempotent and thus replaceable).
+There is one new kind of Nostr event. It is a parameterized replaceable event (all events are idempotent and thus replaceable).
 
 | Event kind | Event type    | Description                                                   |
 |------------|---------------|---------------------------------------------------------------|
 | 38300      | NAME          | Matches `0x00` tranaction type. Publishes records for a name. |
-| 38301      | TRANSFER NAME | Match to `0x01` transaction type                              |
 
 #### New Name
 
@@ -45,19 +46,13 @@ When the records need to be updated, the owner may just publish another name eve
 
 **Note:** When receiving new events, and indexer should recalculate the namespace ID and compare to the `d` tag to validate the event, then use the namespace ID to link to blockchain for correct ordering. Indexers should also treat any blockchain transactions with mis-matching name fingerprints as invalid.
 
-#### Transfer
-
-After publishing a `0x01` transfer transaction, publish a `38301` kind Nostr event. The `d` tag for the event should be the lower case hex representation of the `NAMESPACE ID` published to the blockchain. Additionally, there should be a `nom` tag with the `name` value as the parameter. `content` must be lowercase hex encoded value of the pubkey of the **_new_** owner. The published event must be signed by the current owner of the name, in order to properly establish chain of custody.
-
-**Note:** When receiving new events, and indexer should recalculate the namespace ID and compare to the `d` tag to validate the event, then use the namespace ID to link to blockchain for correct ordering. Unlike publishing new names, the namespace ID in this case is not constructed from the pubkey of the original owner, but the pubkey of the **_new_** owner.
-
 ## Appendix A: Name format
 
 It is necessary to limit the characters used in names. While it might be tempting to allow any valid UTF-8 string, there are good reasons not to do this. In the Unicode standards, there are sometimes different ways to the construct the same character, invisible characters, or "whitespace" characters that may not necessarily be rendered, etc. This could allow for malicious individuals to trick unsuspecting users into clicking/pasting incorrect names.
 
 While it is desirable to have a wide range of characters and languages be usable, for the time being it is necessary to restrict the use of characters to the basic characters typically used in domain names today.
 
-Names must match the following regular expression `[0-9a-z\-]{3,256}` and must be ignored by indexers otherwise.
+Names must match the following regular expression `[0-9a-z\-]{3,43}` and must be ignored by indexers otherwise.
 
 ## Appendix B: Protocol expansion
 
@@ -88,3 +83,10 @@ There are no restrictions on key/value pairs, but they are recommended by conven
 | `WEB`    | Full link for website (not necessarily the same as `DNS`) |
 
 Others may arise later by addition or general public acceptance. The above listed are not required, but if the owner wishes to include any of this data in their records, it is recommended to use the above keys.
+
+## Appendix ZZ: Changes and Updates
+
+**2023-09-19**:
+  - Given the issues cited [here](https://github.com/ursuscamp/nomen/issues/6), the design of transfers in `0x00` is not good and has been removed. As of the time of publication, no transfers have been issued by any users, so this is a not a breaking change.
+  - A new version will be issued which will enable transfers, and an upgrade path will be available for version `0x00` names to `0x01` names. However, in order to link the `0x00` to `0x01` names on chain, the upgrade transaction will require the names to be put on chain in plain text, necessitating limiting them to a maximum of 43 bytes for now (80 byte OP_RETURN maximum - 5 bytes for Nomen metadata - 32 bytes for a public key). As of the time of publication, no names longer than 43 bytes have been issued, so this is a non-breaking change.
+

docs/SPEC.md

@@ -8,9 +8,7 @@ use nostr_sdk::{
 };
 use sqlx::{sqlite, SqlitePool};
 
-use super::{
-    Cli, ConfigFile, NameNewSubcommand, NameTransferSubcommand, ServerSubcommand, Subcommand,
-};
+use super::{Cli, ConfigFile, NameNewSubcommand, ServerSubcommand, Subcommand};
 
 #[derive(Clone, Debug)]
 pub struct Config {

src/config/cfg.rs

@@ -62,9 +62,10 @@ pub struct Cli {
     pub subcommand: Subcommand,
 }
 
-#[derive(clap::Subcommand, Debug, Clone)]
+#[derive(clap::Subcommand, Debug, Clone, Default)]
 pub enum Subcommand {
     #[command(skip)]
+    #[default]
     Noop,
 
     /// Extra utilities
@@ -82,12 +83,6 @@ pub enum Subcommand {
     Server(ServerSubcommand),
 }
 
-impl Default for Subcommand {
-    fn default() -> Self {
-        Subcommand::Noop
-    }
-}
-
 #[derive(clap::Subcommand, Debug, Clone)]
 pub enum UtilSubcommand {
     /// Generate a private/public keypair.
@@ -117,7 +112,7 @@ pub enum UtilSubcommand {
         /// The public key of the owner
         pubkey: XOnlyPublicKey,
 
-        /// Transaction kind. Possible values: create, transfer
+        /// Transaction kind. Possible values: create
         kind: NomenKind,
     },
 }
@@ -156,9 +151,6 @@ pub enum NameSubcommand {
 
     /// Broadcast a new record for your name.
     Record(NameRecordSubcomand),
-
-    /// Transfer a domain to a new keypair.
-    Transfer(NameTransferSubcommand),
 }
 
 #[derive(clap::Args, Debug, Clone)]
@@ -205,41 +197,6 @@ pub struct NameRecordSubcomand {
     pub privkey: Option<NostrSk>,
 }
 
-#[derive(clap::Args, Debug, Clone)]
-pub struct NameTransferSubcommand {
-    /// The name to broadcast records
-    pub name: Name,
-
-    /// Public key of the new owner
-    pub pubkey: XOnlyPublicKey,
-
-    /// The transaction to sign. May be a path to a PSBT file or a Base64 encoded PSBT string.
-    pub psbt: String,
-
-    /// Specify your private key on the command line. May be useful for scripts. Beware of shell history!
-    /// Will prompt if not provided.
-    /// This is the private key of the current owner of the name.
-    #[arg(short, long)]
-    pub privkey: Option<NostrSk>,
-
-    /// JSON command output
-    #[arg(short, long)]
-    pub json: bool,
-
-    /// Broadcast the associated Nostr event
-    #[arg(short, long)]
-    pub broadcast: bool,
-
-    /// Verify against the index that the name is exists and is transferrable.
-    /// Be sure to run the indexer first, or this is not very useful.
-    #[arg(short, long)]
-    pub validate: bool,
-
-    /// File path to write a serialized PSBT file
-    #[arg(short, long)]
-    pub output: Option<PathBuf>,
-}
-
 #[derive(clap::Args, Debug, Clone)]
 pub struct TxInfo {
     /// The txid to use as input.