Happy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by NostReport (npub19md…6vzk) written by gregwhite (npub1r3f…7ex2)
The #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) Deleted NIP 22: created_at limits
By its very nature Nostr has trouble reliably knowing when a piece of content was published. NIP 22 was an attempt to allow relays to be the authorities on when an event was created/published by only accepting events with a “created_at” that was recent according to the relay.
The challenge with this is rebroadcasting. The “created_at” can’t be modified because then the signature on the event that confirms the user authorized the event would be invalid (the signature is created by taking into account the created_at field). So if relays reject events that weren’t created recently, then events can’t be moved around (if a user wants to move relays or back up their content).
Overall, not many relays implemented NIP 22 because it caused too many problems. On top of that, whenever the “created_at” has to be reliable, devs are tending to use OpenTimestamps which is a non-Nostr but much more reliable system.
So, fiatjaf (npub180c…h6w6) deleted NIP 22.
2) (Proposed) NIP 88: Relay Notifications
The impetus for this NIP was the difficulty for paid relay providers to get their subscribers to pay their subscriptions. Currently it’s difficult to manage a monthly subscription with lightning, and most of the time you have to manually authorize the monthly payment every month.
This NIP outlines a way for relays to ask clients to pass along a message to users. The first use case is for relays to remind users to pay their subscription and include a link to pay it easily.
What’s nice about this is: 1) The protocol is more general than that specific use case, as the relay can send any kind of message to the user. Lots of possibilities! 2) This doesn’t require clients to enforce subscription agreements between the user and the relay, preserving decentralization and the opt-in nature of Nostr development.
Author: Vitor Pamplona (npub1gcx…nj5z)
3) (Proposed) NIP 29: Image Metadata
There’s often metadata on images that is useful for clients displaying images (alternative text, dimensions, blurhashes, etc). There isn’t a standard way to provide that content to clients; this proposal changes all that.
It proposes an “imeta” tag to Nostr events so that when a user publishes an event with an image in it, their client can include this metadata to help future clients render it well. 💪
Author: staab
Notable Projects
Search and NostrDB 🔍
NostrDB is essentially a relay that lives within a Nostr client. This has many advantages for clients because it simplifies the client logic around managing events from many relays.
From what I can tell in my research, Damus uses NostrDB as the main relay that the app reads from when rendering the user experience in the app. Then it’s NostrDB’s job to sync events between NostrDB and the user’s desired relays.
Without NostrDB clients have to connect to all the users’ relays simultaneously and sync events. As syncing is going on, the client then needs to update the user’s experience. Doing both at once causes the client’s code to be more complicated and usually less performant. By separating the concern for syncing with the user’s relays to NostrDB, the client can focus on the user experience.
The new news here is that jb55 (npub1xts…kk5s) has improved NostrDB to support very performant search. That means a client can sync events from the user’s relays, and then search that content in milliseconds without making a network call.
Without this, clients will need to reach out to each relay individually and make a filter request and wait for responses to trickle in. Then the client has to aggregate all the responses and show the user a result.
An architecture where there’s a NostrDB on the client, and/or a NostrDB powered relay that specializes in search, could make the work of discoverability much easier for clients. LFG!
Onboarding Normies 🛝
Rabble’s Talk on Nostr for Normies has motivated many thoughtful discussions (and some less-kind discussions) around how to attract and retain more regular folks on Nostr. But it seems no one is as prolific (in general but specifically) in their motivation to solve this problem as PABLOF7z (npub1l2v…ajft) .
This project is a demo of an experience for Nostr users to sign up for Nostr without ever touching the public and private keys. They create a username (NIP 05 address) and use an email to authorize any future recoveries of access to the Nostr account.
The experience is familiar to anyone that’s signed up for a service by logging in with Google or Twitter (which is most internet connected westerners). The experience still preserves choice for the user (where are they going to host their NIP 05 address, which nsecBunker will custody the keys, which email they will use to do recoveries, etc).
This could be the foundation of an onboarding experience that’s great for regular folks. Great work Pablo!
Better Backups 📦
Without the ability for users to move relays, Nostr isn’t truly censorship resistant. So, backup services will always be a core tool for the freedom-loving user of Nostr. iefan 🕊️ (npub1cmm…lr6f) just released an update to NostrSync.
It feels more performant and feels simpler for the user. On top of that, users can now manage their backups, which means that we can start to take snapshots of our Nostr data. All stored locally so you continue to own your data.
Latest conversations: Onboarding Normies
The people in our community with the most experience building social products that people have adopted at scale have been telling us that Nostr is not ready for normies yet. ( Rabble’s Talk on Nostr for Normies and Jack’s latest assessment )
But we are seeing a ton of development that is making Nostr better for normies, and it seems like we’re close to all the lego pieces being ready. Here’s what I’ve seen lately.
Abstracting keypairs
Regular folks don’t understand public/private keypairs. It took decades for regular folks to accept usernames and passwords, and best case it’ll still be a while before regular folks understand public/private keypairs.
To help people join Nostr today, it’s sensible to offer services that wrap Nostr keypairs with a username/password experience that’s recoverable by email. People will understand it, and as long as they can still download their keys, they can self-custody whenever they want. If service providers end-to-end encrypt the actual Nostr keys, it could even be said to be non-custodial.
Pablo’s recent demo of an easy signup flow without managing Nostr keys is orders of magnitude easier to understand and educate new Nostr users on. Clients that adopt workflows like this could see retention increase quite a bit.
Finding and Filtering content
Decentralized systems are hard to search for specific content. It took a while for Google to solve the issue for web content. Twitter did incredibly well because of their search functionality. Nostr currently struggles to help people of all interests find the content and content creators they want.
Will’s work on NostrDB (as mentioned above) seems like it could be the foundation of performant search of Nostr content. Purpose-built search relays would be a valuable tool for clients helping users solve the discoverability, and we may be close to a truly great technological solution.
Approaches like Coracle’s introduction of “web of trust” based content discovery could also tackle the discoverability from a different direction. As is, it makes the global feed a bit more enjoyable. In the future, this pattern could power everything from discoverability, to semi-algorithmic feeds, to opt-in content moderation based on your social graph.
Part of making content enjoyable for regular folks is allowing and aiding people in filtering their feed how they like. Content moderation should not be forced on anyone, as that’s not in the spirit of Nostr, but rather allowing users to opt-in to filtering algorithms.
Rabble’s Nos.lol is taking the first steps towards using web of trust to help filter content in an opt-in way. Labeling tools like Ontolo could soon aid users in generating content warnings or lists of pubkey that are sources of content that people may want filtered.
Web of payments
Another challenge for normies is paying for all the services that power a great Nostr experience.
Quality relays Hosting images/videos Usernames (NIP 05) Translation Zaps
Currently there are free or custodial solutions but those can’t be run as charities forever, especially if there’s a surge of adoption.
Users are already not used to paying directly for social media, but paying independently subscriptions for all these services without being able to even use a credit card is jarring.
The problem of users paying with fiat but service providers receiving sats or a different fiat currency may soon be solved by Strike, but this is an area of underdevelopment.
Super-clients
For the freedom tech literate among us, it makes sense to sign up for services independently and manage your own self-custody lightning node/wallet to pay for services with sats. When you add up all the services this may be more expensive, and it’s definitely more work to manage, but those costs are worth it to many of us.
To service normies, we may see the development of super-clients. Where larger, well-funded clients (Primal, Nostr.Band, Damus, Amethyst, or even new players) may start to build services into the client to give an all-in-one solution for normies.
These super-clients may provide a NIP-05 address host, hosted nsecBunker with username/password interface, image/video hosting, translation, a quality relay, discoverability relays, translations, a few optional managed content moderation schemes, etc. All paid for via their hosted custodial lightning wallet the user can load with fiat but pay with sats.
Despite its trade-offs, this will make more sense to normies than the current paradigm. From what I can tell, we’re already seeing Primal working towards this level of capability. I imagine it’s very tempting for any team who wants their client to achieve scale. On balance this may not be a bad thing, but there are trade-offs to manage to minimize centralization.
Maintaining decentralization and censorship resistance
In a world that has super clients, they would be centralizing forces. They may even start to break from the protocol to build features they feel are necessary or give them a competitive advantage. This would have the side effect of decreasing interoperability and therefore decentralization.
To maintain the heart of Nostr, censorship resistance and freedom, while still offering an experience that can handle the needs of normies, it’s important to keep pressuring centralizing players to at least maintain perfect interoperability.
Users on super-clients should always be able to opt-out of aspects of the all-in-one solutions offered by these super-clients. If someone joins a super-client and wants to swap out the wallet, or the provider of content moderation, they need to be able to do that.
Users on super-clients should always be able to use other Nostr clients. If a user has their keys in a Primal nsecBunker they should be able to use that to log in to other clients and use them without difficulty.
Symbiosis with Normies
There is an exciting future equilibrium where everyone in the world is more free because of the work being done today on Nostr. A future that moves the needle for a good portion of humans requires us to find ways to onboard normies.
Normies bring more usage, and the possibility of more monetization. Through monetization we can attract more development and fund even more ambitious projects. Can’t wait to see it. 🙂
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.