Building a nostr client [0]

nickmonad.blog

Building a nostr client [0]

Basic data structures and Event generation

March 26, 2023

#nostr

#rust

Over the past few weeks, nostr has continued to take much of my attention. I'm still<br>fascinated by this protocol and I'm very curious to see where it goes in the coming years.

If you haven't heard of nostr yet, it stands for "Notes and Other Stuff Transmitted over Relays", and is a pretty<br>simple, yet powerful, idea for defining and growing a social network. Instead of a centralized server (or even<br>federated servers that talk to each other) it uses the concept of "relays" that allow clients to connect to them and,<br>you guessed it, transmit "notes" and "other stuff", using a cryptographic key pair to sign and verify that data.

By the way, how do people pronouce this thing? Is it "nos-ter", "nose-ter", ... something else? I tend towards the<br>first way for some reason.

As the protocol's GitHub states:

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.<br>It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and<br>signatures, so it is tamperproof; it does not rely on P2P techniques, and therefore it works.

Clients have the option to connect to as many or as few relays as they want, some of which are free and open to the<br>public, and some of which require payment to access. This allows for a wide variety of communities to coalesce<br>around certain relays if they choose, and move to another if the one they are using decides to censor them for<br>any reason.

The implications of this are pretty amazing, and I think it will open up a lot of opportunity in so many directions.<br>Not only from the standpoint of free speech, but also for relay operators and client developers to build features in<br>a competitive way, very quickly raising the bar for the network as a whole. We are still very much in the early days,<br>and things are a little bit crazy, but the hype is real, and I believe for good reason.

Let's build a client!

Besides all the reasons I mentioned above, I'm excited about nostr, because, as a programmer, I get to build things.<br>My own things. Things that define how I interact with the network. There are a lot of good clients out there already,<br>but I figured, "why not try and build my own?"

This is the first entry (index 0) in a series of posts I intend to write outlining the basic discovery and process<br>of building a client. Hopefully we'll run into some interesting challenges that need thoughtful solutions, and we'll<br>progress towards something relatively usable.

I'll be writing this series as I develop the client (seriously, I haven't written a single line of code as I<br>write this sentence), which is something I've never done before. I'll do my best to strike a balance between content<br>and pace. I don't want to dump every single thought in my head out into this post, otherwise it could take hours<br>to read, but I want to show enough to get an idea of what it takes to build a client at a technical level. I'll also<br>have to stop writing these posts at some point (there's more to life, ya know?). But, I'll keep developing the<br>client after I wrap up this series, and anyone can follow along on GitHub once we hit that point.

Hopefully I won't give so much detail that it's exhausting to read. I'm hoping I'll get better about tightening up<br>these posts as I go.

Wait, what about the name? After looking at all sorts of weird combinations of "rust" and "nostr", I came up<br>with roostr. I like it because it gives the project its own identity, and is actually pronoucable as "rooster".

I'm aware of the whole ostrich thing nostr has going for it. I just wanted some combination of "rust" and "nostr"<br>and settled on something unique in the space!

THE STACK

I'll be writing this client using Rust. That's it. That's the stack.

It'll be a terminal-based client, because frankly it's just easier, but I also love the challenge of making a usable<br>terminal UI. There's a neat minimalism there.

I will definitely assume some Rust knowledge for this series. There are a million ways to learn Rust and I can't<br>really teach it any better. I'll make clarifying notes if I think something is particularly odd about Rust that<br>needs explaining, but I want to keep it to a minimum.

The Protocol

Nostr, as a protocol, is refreshingly simple. The main GitHub repository<br>is a high-level look at the protocol and motivations behind it, but the NIPs<br>repository is where all the action is.

NIP-01 is one of the few mandatory NIPs that relays<br>and clients must implement, and is the obvious starting point for us. Highly recommend giving it a quick once over<br>before continuing.

Events

Looking at the first available struct defined in NIP-01, let's take a stab at defining it in Rust. I want to start<br>with the event generation and signing portion first, before we start connecting to relays.

pub enum Kind...