Nostr Tech Weekly 12.17.2023

Nostr Tech Weekly 12.17.2023

The Nostr Report's "Nostr Tech Weekly" is a weekly newsletter covering interesting projects, protocol updates, and other technical advances in the Nostr-verse 🌎 Written by Greg White.
Nostr Tech Weekly

Dec 17

Happy Sunday #Nostr !

Here’s your #NostrTechWeekly newsletter brought to you by written by

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)

It’s been a light few weeks for new NIPs or NIPs that seem to be nearing “official” adoption (changes being accepted to the NIPs list). But there’s one that’s timely and new to talk about.

1) (Proposed) NIP 100: DEX orders over Nostr

The team at OrdersExchange is proposing a protocol for communicating orders for digital assets using Nostr. The first use case seems to be BRC20 Tokens (which are fungible tokens issued on Bitcoin AKA ordinals).

The idea is that DEXs (and their users) would benefit from orders being communicated more widely, it would improve price discovery and help create more efficient markets. Sellers would post their sell order and buyers would be able to post proof that they paid for the asset and therefore close the order.

DEXs could become Nostr clients looking for and coordinating these Nostr events to create efficient exchange. This NIP is early in its development but could be a consequential addition to the Nostr economy if DEXs are interested in implementing the protocol.

Notable Projects

Collaborative live editing documents 📄

Prompted by an issue opened in the codebase where all the NIPs live, has started thinking through how to enable collaborative, live editing documents via Nostr. Think of how you can edit things via Google Docs with several people at once.

There’s an open source software called Automerge which should be able to do the heavy lifting. In summary, Automerge is able to create and update documents with incremental changes from various users (and reconcile possibly conflicting edits).

What’s novel about this would be using Nostr as the protocol for communicating the collaborative edits instead of a central server (like Google Docs). There’s a lot of dev work ahead for this project, and some questions around if or which relays will want to play host to whole documents (and their edit history). But this could be another freedom tech that is improved by Nostr 💪.

Followed by friends on 🫂

announced that the Nostr client Iris supports a feed of who your friends are following. I think Coracle has had this feature for some time as well, but it all supports pushing the frontiers of content discovery on Nostr without giving up control of your feed.

This is another example of “web of trust” based operations on Nostr, and it seems like a rich area to continue investing in to build a better, freer social experience.

Latest conversations: The Lightning Network and Nostr

The recent move by Wallet of Satoshi to pull out of operations in the US has made clear that Lightning and specifically LNURL providers are a central point of failure for Nostr.


Zaps are one of the main things that makes Nostr special (so far). Zaps are fun. Zaps help us support content creators directly. Zaps help us support people who wouldn’t get a dime from any of the other social platforms.

Zaps create a far better measure of how much users care about content than reactions that cost nothing. Zaps are a great way to start people on the circular Bitcoin economy.

Nostr and disintermediating platforms with lower fees

Nostr has the opportunity to disrupt platforms like Patreon, Youtube, Twitch, Spotify, etc by offering the same (or better) experience to users while helping content creators keep more of their money.

That dream entirely depends on low fee transactions which are currently most accessible via the Lightning Network and often via Zaps. Protecting this infrastructure and ensuring it stays decentralized is key to this possible future for Nostr.


Zaps (and other proposed features for paying content creators directly via Nostr) depend on the LNURL protocol and Lightning Wallets that run it for their users. Rita getting zaps via her lightning address Traditionally Lightning requires the receiver to do the work of generating an invoice and setting the amount the invoice is for. That’s not practical if the goal is to tip a content creator or charge X number of sats to unlock a blog post without knowing who or how many people will do so.

The LNURL protocol (specifically the “pay” portion) for Lightning wallet providers enables payers to request a one-off invoice from the receiver’s Lightning wallet provider (in the amount the payer wants to send). Then the payer just pays the invoice like normal through their Lightning Wallet.

A good description of LNURL and the Pay Request protocol can be found here.

Everyone that can receive zaps generated an LNURL address with your Lightning wallet provider at some point, and the whole thing is very useful. Only trouble is that it requires the Lightning wallet providers to have an always-on service that can service requests from payers who want those one-off invoices.

Custodial Lightning is Central Point of Failure

If you don’t want to fully self-custody your LIghtning Node, you have to have a Lightning Wallet Provider in your jurisdiction that supports LNURL functionality. There’s on the order of dozen providers TOTAL that currently support this functionality, and one of them just got pressured out of operating in the US (Wallet of Satoshi)

This isn’t a problem that has to be solved immediately. It may not even be the next most important bottleneck to fix for Nostr to thrive. For example: it may be more important to create better ways to onboard and retain users. But, if US regulators continue pushing custodial lightning wallet providers to cease operation in western jurisdictions, we may see this problem become the most critical problem for the community to solve.

It’s worth starting the conversation sooner rather than later.

Solution: More providers?

Most Bitcion wallets don’t support LNURL. many of the best ones do, but many of the most popular don’t, e.g. CashApp doesn’t support it. Coinbase doesn’t even support lightning transactions nor wallets 🙄.

One way to decrease the “central point of failure” issue is for more Bitcoin wallets to support Lightning and LNURL functionality so that we have more options (and more moles for regulators to whack). One thing we can all do is continue to reward the Bitcoin companies that build these features with our business and pressure the ones that don’t until they give in.

Solution: Go up a layer?

Lightning (which is arguably an L2 for Bitcoin) isn’t a panacea. As Bitcoin usage scales, fees on Lightning will probably go up (even priced in sats) and as Bitcoin price goes up as well, the transaction fees may become more comparable to what we see from traditional payment providers (Visa, Stripe, etc).

Hal Finney (one of the first and main contributors to Bitcoin) painted a picture of a future where Bitcoin succeeded where banks would open between each other and each would issue its own ecash for daily use by most people. That way Bitcoin was the asset of highest value, banks would use these channels to settle transactions between them, and then cash-like transactions would be driven by digital cash issued by banks which would be Bitcoin backed.

Keep in mind, this was all before Lightning was even under development. Hal hadn’t even imagined how Lightning would help enable more than just traditional banks to participate in the payment rails, nor could he even imagine how Lightning enables solutions like CashU to issue ecash that can be interoperable between any entity that uses the Lightning network.

Hal’s future is on its way, and it’s even better than he predicted. And we, as Nostr folks, may need to go up a layer anyway to maintain the low fee, cash-like transactions powered by Bitcoin on Nostr that helps commerce on the internet thrive.

Going up to a Layer 3 (like Cashu) seems like it also enables the commercial activity we need on Nostr without requiring centralized always-on custodial solutions to receive our payments to each other.

There are trade offs going to a Layer 3 (as you get further from Bitcoin itself, you have to trust your counterparties more), but the trade offs may be worth it as the ecosystem of Nostr and Bitcoin users grows.

What do y’all think?

If you can think of other solutions, please start a conversation by replying to this post. There’s a lot of intelligent folks who care deeply about the success of Nostr and there’s nothing we can’t solve together.

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

Stay Classy, Nostr.