Happy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by NostReport (npub19md…6vzk) written by greg (npub1r3f…7ex2)
#NostrTechWeekly is a weekly newsletter focused on the more technical happenings in the nostr-verse.
Let’s dive in!
Recent Upgrades to Nostr (AKA NIPs)
1) (Proposed) NIP 43: Fast Auth between clients and relays
Some relays are member-only. There has to be some way for relays to verify the content being sent/requested is from an authorized user (one of the members). Most methods for this are clunky and slow.
This NIP proposes a faster method for auth between clients and relays. From what I can tell when clients open a connection to a relay they’ll open it with an “authorization” query parameter on the end of the relay url. That query param will actually be an encoded Nostr event whose payload has the necessary info for the relay to authenticate the user opening the connection.
Kinda looks like an auth header like you’d see in an http request but shoehorned into a query parameter since websockets (which are used for connections to relays) don’t traditionally support headers.
Author: aruthurfranca
2) (Proposed) Updates to NIP 03: Timestamps you can rely on
Sometimes you want to make sure that a piece of Nostr content was actually created/pushed to a relay at a specific time. The example from last week was in the case of a future betting system built on Nostr, you really don’t want people to be able to publish that they made a bet 2 weeks ago for something whose outcome was determined twenty minutes ago.
NIP-3 already outlines a way to add OpenTimestamp attestations to Nostr events essentially allowing Nostr clients to outsource trust to a third party on whether a piece of content was created when it claims to be created. As is, NIP 3 is a little hard to use. This update would make it far simpler.
In the new methodology, you’d publish a Nostr event of kind 1040 with the proof of timestamp and point to the event that you’re trying to prove the timestamp for.
Author: fiatjaf (npub180c…h6w6)
Notable Projects
Cellar Relay
If you haven’t been graced by the nostr.wine community they are a group of fine folks that host wine-themed relays. They’re some of the most reliable and widely used public and paid relays around.
Mazin (npub18kz…x5sz) recently announced the “Cellar” Relay that will store notes long term for paid users. Like we talked about in last week’s #NostrTechWeekly long-term note storage is a challenge for relay hosts (especially for relays that are free to users). But solving long term storage will help folks on Nostr feel like they’re building a persistent social experience instead of building an ephemeral feed.
Nice work! Glad to see the trend continuing for long-term note storage. 💪
Memestr.app
I can’t tell you how many times folks I talk to have said there should be a meme-focused client on Nostr. sarakeshtix (npub1zum…pl4x) delivers with https://memestr.app I definitely had some giggles when I logged on.
This could quickly evolve into a nostr-based Imgur and be far better for being nostr-based. But one thing I think is missing from the internet (not just Nostr) is a way to iterate on memes easily in the same place where you can share them. In combination with prisms/boosts this could be an interesting way for people to make money for their content and earn from what is built on top of their content.
Zap threads
Threaded conversations are an important component to social experiences on the internet. Reddit and Hackernews have really shown its power, we’ve seen StackerNews also leverage this format as well.
franzap (npub1wf4…dgh9) has created a nostr-based component for supporting the threaded comments, and it looks like it could be used in any web-application that needs commenting, spreading Nostr to every corner of the internet. It’s already powering the commenting on Habla.News
franzap (npub1wf4…dgh9) also did a great writeup on the reasoning for this project and where it’s going: https://habla.news/franzap/threading-the-web-with-nostr
If you need comments on your project, take a look!
Latest conversations: How decentralized is decentralized enough?
Distributed vs Decentralized
These two concepts are often used interchangeably, and it’s worth highlighting their distinction, especially in the context of Nostr. This is a good visualization to illustrate the difference.
Distributed: the P2P model
Robust, distributed systems are extremely censorship resistant, and include a lot of redundancy. Distributed systems distribute power widely, everyone is a peer.
Biological systems (cells, ecosystems, etc) are like this, cells are all peers and replaceable. Napster was distributed, everyone in the Napster ecosystem stored and shared some of the songs. IP (the “internet protocol”), which is how computers find each other on the internet, is a peer to peer technology where every node gossips about where to find other nodes.
Ideally all systems would be built this way, but in practice distributed / P2P systems are generally used when there’s a high chance of node failure (the death of individual cells) or attack (government takedowns). The challenge is that they’re expensive to run.
This might be confusing because Napster was “free” right? Most P2P software feels free-ish because many are donating some of their existing hardware/bandwidth/etc. But if you take the aggregate resources to run Napster versus just the parts of Spotify that help users to upload and download music, Spotify for sure uses fewer resources.
Distributed systems by their very nature have to assume that most peers in the network may fail. In order to maintain uptime, that results in P2P systems having many copies of what’s being shared and/or sending data many times to ensure it arrives.
I think most people would say they’d prefer everything to be P2P but it’s difficult to maintain a good experience in a P2P system and so it’s often only used in cases where it’s absolutely necessary.
Where does decentralization work better?
I wrote up a whole thing about decentralization a while back but the TL;DR is decentralized systems are better than centralized systems at distributing power widely, but they are generally still more performant than peer to peer systems.
Sometimes you need a mix of preventing abuses of power but still maintain a good experience for users. Freedom minded folks usually end up supporting decentralized solutions because they’re viable in the market and still take power away from centralized players.
Is Bitcoin decentralized or distributed?
The Bitcoin blockchain is a distributed system. Every Bitcoin full-node is an equal participant in storing, updating, and validating the blockchain.
Bitcoin as a monetary system, on the other hand, is decentralized: there are many more Bitcoin users than Bitcoin full-nodes. The nodes are the hubs and the users are the spokes.
There’s a reason for this architecture. Bitcoin nodes are ultimately in control of Bitcoin, it must be the least corruptible, most censorship resistant architecture possible. On the other hand a decentralized system has efficiency gains that make Bitcoin more competitive in comparison to existing financial systems. By having hubs (full-nodes, Bitcoin banks, wallet providers, exchanges, etc), the system is more efficient (and therefore cheaper). But by having many hubs, power is still spread widely.
Nostr: Decentralized or Distributed?
Nostr, as introduced by FiatJaf, seems like it was intended to be decentralized. Relays are the hubs and users are the spokes. Clients help connect users to relays (and therefore each other). There is wisdom to this architecture, because it will scale better than a P2P system.
Think of it this way, there are on the order of hundreds of millions of songs available for human consumption. With 10 million users storing a few hundred songs, there would be plenty of redundancy to allow Napster to distribute every song in a P2P manner. There are on the order of trillions of social media posts, if you include follows, reactions, DMs, etc, it’s likely in the quadrillions. With current technology a P2P system would never be able to provide coverage of every post and make it available in a reasonable time.
That said, there are some elements of Nostr that could benefit from being more P2P. Especially operations that would benefit from greater privacy (DMs, zaps, and reactions). Right now privacy around these actions is not well supported via Nostr.
Dev work has started on some P2P Nostr functionality announced by Vitor Pamplona (npub1gcx…nj5z) and it’s right along those lines: maximizing privacy and security for nostr-based comms. It will have all the great things and all the difficulties of any P2P system, but it may be necessary to improve privacy on Nostr.
One thing that is great about Nostr is everyone can try things out and see if they work and if people want them. I see a lot of demand for privacy for certain Nostr operations, and if a P2P model would help, it needs to be tried. We’ll see whether the trade offs of P2P make Nostr better or if they make it less likely to succeed. We’ll see as development continues!
Until next time 🫡
If you want to see something highlighted, if we missed anything, or if you’re building something we didn’t post about, let us know. DMs welcome at NostReport (npub19md…6vzk)
Stay Classy, Nostr.