Happy Sunday Folks!
Here’s your #NostrTechWeekly newsletter brought to you by nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk written by nostr:npub1r3fwhjpx2njy87f9qxmapjn9neutwh7aeww95e03drkfg45cey4qgl7ex2.
The #NostrTechWeekly is focused on the more technical happenings in the nostr-verse.
Let’s dive in!
## Recent Upgrades to Nostr (AKA [NIPs](https://nostr.com/the-protocol/nips))
#### 1) (Proposed) [Update to NIP-07: Nostr Browser Extension](https://github.com/nostr-protocol/nips/pull/940)
[monlovesmango](https://github.com/monlovesmango) is proposing updates to the capabilities of the Nostr Browser Extensions. Currently, browser extensions are primarily used to enable usage of Nostr clients without giving that client your Nostr private key.
Since [NIP 44](https://github.com/nostr-protocol/nips/blob/master/44.md) was adopted, there are a few new Nostr actions creating encrypted content over Nostr that clients will want users to authorize without requiring users to input their private key. This NIP adds those new Nostr actions as something browser extensions should support going forward.
#### 2) (Proposed) [NOSTR Decentralized Advertising Network](https://github.com/nostr-protocol/nips/pull/955)
[ionextdebug](https://github.com/ionextdebug) is proposing creating a marketplace for advertising that runs over Nostr.
For those unfamiliar, there’s a constant bid and ask process for advertising space on platforms like Youtube or Google Adsense. The sell side is offering up ad space (for example 5-25 seconds at the beginning of a Youtube video for users within a specific demographic), and the buy side is bidding to put their ad in that spot. The highest bid wins the spot. This all happens in milliseconds every time you see an ad online.
This proposal outlines how this could be coordinated over Nostr instead of in Google’s walled garden. The use case would require Nostr to operate in ways it wasn’t designed for, so it may struggle to work in practice, but the NIP is early in the process of development.
## Notable Projects
#### [nsecBunker Update](https://w3.do/HuO-UVum) 🔐
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft announced an update to nsecBunker that allows users to an OAuth-like experience when logging into Nostr clients.
Bunker providers are able to provide account creation to Nostr users that feels a lot like signing up for any legacy tech service (username, password, control over what each Nostr client can do on their behalf, etc). This creates a set of Nostr keypairs which are necessary to operate in the Nostr-verse, but they’re stored in the bunker.
When a Nostr client wants a user’s permission to read or write with those keys (e.g., to pull their timeline or help a user post something), the client asks the bunker for permission, which then asks the user if they want to grant that permission. Users are also able to have their bunker remember their selections of grant/reject permissions for a given Nostr client so that things are easier with fewer popups the next time around.
Additionally, users that are created and managed via nsecBunker have a lightning wallet and lightning address created automatically. If nsecBunker could also help folks manage their full Nostr profile (Kind 0 data like profile picture, name, etc,) this could be an out-of-the box solution for clients looking to add a simpler signup/login experience to new users that don’t mind giving up some control.
From what I saw in the code, the data (including Nostr private keys custodied by the bunker) are encrypted at rest, but currently that’s one key to encrypt all keys in the bunker. It may make sense in the future to extend the functionality to give users the ability to encrypt their keys with their own password, but there are downsides to that which may make self-custody the easier option.
There’s no lock-in for users since bunker providers can help users download their keys if they want to self custody or move to another provider.
This could be a foundational tool that allows an ecosystem of bunker providers emerge. Bunkers may be offered as part of Nostr clients, or independently; they may be offered for free, or for a fee. But the opt-in and interchangeable nature means that users will be able to choose what works for them, including moving to self-custody once they see the benefits. And self-custody may even just be a self-hosted bunker. 😉
#### [Faaans](https://getfaaans.com/about) 🎨
This is another project from nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and although it’s still pre-launch, it has been teased as a Patreon replacement built on Nostr.
It seems like this project is one whose purpose and value is clear, but requires many capabilities that are novel to Nostr to be built first. From what I can see Faaans has built:
1. Oauth-like flow using new nsecbunker functionality from 👆
1. Ability to gate content until a Nostr user pays for it
1. The presence of uploads and NIP 98 HTTP Auth makes me think that there’s a non-Nostr backend for handling uploads (maybe to also help with gating the content?)
Anyway, I’m excited to see how it turns out. Cutting out middlemen and giving creators full control over their relationship with their audience could be the killer app that brings a flood of usage and business to the Nostr ecosystem. 💪
#### [Relay Auth to support privacy](https://w3.do/qZOxIUwk) 🤫
[NIP 42](https://github.com/nostr-protocol/nips/blob/master/42.md) allows relays to require clients to authenticate the user before the relay will take a requested action. This is useful, for example, for keeping DMs private.
By default all Nostr events can be queried by anyone that can connect to the relay. This is part of the magic of Nostr. But there are some kinds of Nostr events that likely should only be readable by a few folks. In the case of DMs, it makes sense to restrict who can download DM-type Nostr events to only those people involved in the DM.
This can be accomplished by relays requiring the user to authenticate with the relay before it returns DM-type Nostr events for that user. This announcement is that Damus looks to be adding support for Relay Auth, which may help with any number of features that can benefit from more privacy.
## Latest conversations: Web of Providers
The culture of Nostr currently highly values self-custody, decentralization, and “don’t trust, verify” which is very admirable. It’s woven into the protocol itself. There are downsides to operating on these principles, but most of us judge it to be worth it.
It’s usually possible to have our cake and eat it too (have a nice experience and maintain our values), but it requires technological advances and building products based on those advances. This takes time.
In the interim, devs may build something that’s less self-custodial, less decentralized, but far easier to use. Most of the time this middle ground is far better than using some legacy system that’s completely custodial, centralized, and locks users in. But that’s only the case if it’s a stepping stone to a solution that is everything we need.
#### Example: Custodial Lightning Wallets
When Wallet of Satoshi stopped operating in the US, I definitely felt how vulnerable the zap ecosystem was to some overzealous bureaucrats. But I was able to switch providers in a matter of minutes and get back to sending and receiving zaps.
I definitely considered moving to Zeus or Mutiny or reviving my own Lightning Node on my Bitcoin Node, but it’s all still too difficult to manage a reliable experience passively.
On net, I’d argue that using custodial lightning is better than using Venmo or something to send and receive zaps. At least we’re operating in Bitcoin and not fiat.
#### A must have: a competitive ecosystem
The trade offs of a middle ground are easier to live with if there’s a robust and competitive ecosystem.
In the case of custodial lightning wallets, we’re encountering the issue of a lack of robustness. There are only a handful of providers that are able to handle zaps. Losing Wallet of Satoshi was a significant blow. We definitely need more lightning wallet providers in order to be robust against nation-state attack.
The ecosystem must also be competitive. People need to be able to switch providers or move to self custody with little or no cost.
#### NSecBunker
NSecBunker is an excellent example of a middle ground solution that maintains manageable trade offs while working to discover a more perfect solution.
If Nostr users want to use bunkers, it’s trivially easy to spin up a bunker and provide it to them. Existing clients may spin them up, or people looking to start a business in the Nostr ecosystem may create bunkers (maybe with some extra features) and charge for them.
At the end of the day, this technology is built in such a way that interoperability is easy and users aren’t locked in. The lift for Nostr clients to support bunkers is small, so bunkers may soon be as widely used as the Nostr browser extensions. Since users aren’t locked in to any bunker provider, it’ll be easy for a web of providers to pop up and serve users in unique ways to discover what works best.
#### Build tech to enable a web of providers
Building Nostr tech that has interoperability top of mind supports the Nostr ethos and enables the ecosystem to develop incrementally without giving up our values. Luckily, the protocol itself encourages interoperability with its very architecture. 🫡
Let’s reward devs when we see them doing this important work, they’re building an immense amount right now and it’s an incredible privilege to witness and beta test. 🍻
## 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 nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk
Stay Classy, Nostr.
Oddbean new post about login | logout