Compare with Nostr

[NfNitLoop]

I delved into the Nostr ecosystem a bit, even going so far as creating my own server implementation and some tools for that. It has some pros and cons vs. FeoBlog that I keep wanting to make a blog post about, but I haven't sat down to collect my thoughts on it yet.

This issue is basically me collecting my thoughts until I make a blog post.

Nostr Pros

1. Number of Users: Nostr has many users. FeoBlog currently has one. 😆
2. Mutable Content: Nostr supports updating "blog post" content after a user has posted it. It turns out, this is really handy. The longer your content, the more likely you're going to find a typo after you've submitted it. I'd like to bring this to FeoBlog while maintaining edit history. (TODO: Allow "updating" an Item #128)
3. Lots of clients. There are multiple implementations of Nostr clients, from web apps to phone apps for Android and iOS. (This may be a double-edged sword, though, as feature support can be pretty different between clients.)
4. Separation of client and server. Nostr has a clear separation of a "relay" and clients that read/write to that relay. (TODO: Separate "Server" (API) and "Client" (UI) #127)
5. Better pattern for signing events/items. I struggled with finding the line between security/usability for this in FeoBlog. I ended up letting the user (preferably temporarily) save their private key in the web app. But Nostr has created a browser API (provided by a browser extension) which allows securely signing content without giving your key to a web site/app. I like this and would like to eventually do something similar. [TODO]

FeoBlog Pros

1. Better data model. Nostr uses JSON objects for its data. I think the goal here was simplicity, but that breaks down very quickly. For example, there are lots of single-letter attributes which are not intuitive. To know what they mean, you have to go read the spec. (Which is spread across many NIPs (Nostr Improvement Proposals?). FeoBlog uses a protobuf definition for its data types. Things can have more meaningful names, and are documented in the definition. Embedding binary data (like user IDs and signatures) is also more efficient in this format than JSON. It's simpler to sign this binary blob than the algorithm that you must use to sign Nostr "events".
2. Better crypto¹: FeoBlog uses NaCL public key crypto for signatures. Nostr uses [TODO] which was chosen because it was the same system used by Bitcoin.
3. Built-in support for binary file attachments. Nostr has some proposals for embedding files into Nostr "events", but the proposal is (AFAIK) still just in a PR that's not even easily discoverable. Meanwhile, binary files can be attached to any FeoBlog "Item".
4. Better protocol: Nostr's "relay" protocol implements long-lived subscriptions atop the WebSocket protocol. This makes client and server implementations needlessly complicated²³ for the common cases of "Get me this item" or "What items are new since $date?". FeoBlog just has simple HTTP endpoints that you can GET or PUT.

Footnotes

1. Crypto means cryptography. ↩

2. One example: A client may provide multiple query terms to OR together for a subscription. But servers may limit how many terms they support. Many clients ignore servers' metadata about how many queries they support and just get errors as a result. ↩

3. There is no way to query for a list of items that exist in some date range. Querying that date range always returns the entire set of items in that date range. That makes it very inefficient to find out what's new. (There is an optional COUNT query, but that requires even more round trips to find updates, and is more complicated to implement.) ↩