On July 28th, I submitted my proposal to @HRF for the Serverless Payjoin bounty: Payjoin over Nostr. You can read the protocol addendum here:

GitHub

BTCPayServer.BIP78/BTCPayServer.BIP78.Nostr/README.md at nostr · Kukks/BTCPayServer.BIP78

a BIP78 Payjoin implemention in C# for both sender and receiver. - Kukks/BTCPayServer.BIP78

The proposal is incredibly simple in nature, just as BIP78 was designed to be, to increase adoption chances. All logic within the Payjoin protocol stays the same, so the version is still 1. It is asynchronous (receiver can process later when back online), encrypted (communication is end-to-end encrypted), and lightweight (no server requirement, leverages existing Nostr network). In addition to this, I also added building blocks for a new experimental addition: Nostr Payjoin Market. If your wallet supports receiving Payjoin, you can share a static payjoin endpoint using the Nostr Coinjoin Discovery protocol (

GitHub

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Other wallets, which support Payjoin but want to send money to wallets that don't, can use these static endpoints to enhance their transactions. The goal? Make every transaction to every wallet a coinjoin. See the sample wallet code and additional detailed description:

GitHub

BTCPayServer.BIP78/BIP78SampleWallet at nostr · Kukks/BTCPayServer.BIP78

a BIP78 Payjoin implemention in C# for both sender and receiver. - Kukks/BTCPayServer.BIP78

See quick video demo of prototype:

I've often said that social Nostr is the most boring variant of what can be done, but even that isn't boring! It's beautiful seeing clients that can mimic every other closed platform's UX, but are still interoperable. Reddit, Facebook, Twitter, Twitch, etc. Nostr is everything! This is really cool: https://live.snort.social/live/naddr1qq9rzd3c8qcrxwfexy6qygrrle333hzctq70u95pp7rd6z0p307hd24uyjsqs88zs4hnxpgya5psgqqqwenscgn3np

Working on massively simplifying my relay code of NNostr https://github.com/kukks/nnostr. Recently, @lontivero asked me why my relay logic was so different to the rest, so here is my story: Back in 2021, we had to do assumptions on how clients would utilize subscriptions and filters. There were only A handful UI clients back then doing mostly the same thing and realistically 0 users as all the notes were just tests. Would everyone generally just create identical subscriptions? Would they have massive filters sets per subscription? Would filters be a template that everyone mix and matched into subscriptions? Was anyone even going to use any of this? As usual I went nuts and started building it super optimized from the get go. Every filter from every subscription was hashed and used as an identifier so that no duplicate sql call would be needed when users requested the same filters. Realistically though, nip01 still needed to mature and the filter spec gradually changed to introduce more convenience, such as paging and date ranges. This made writing clients way more efficient, but unfortunately made my optimizations just a bunch of crazy useless magic as filters were always different due to more precise query capabilities. I'm still happy with my relay code though, it comes with unique features such as a builtin balance system, fee charge on new keys and on per event basis, dynamic event fee based on event size, a chat bot for administration, and other fun stuff. Soon I'll be changing the filtering code to a more simplistic style, and I'm hopeful to eventually also find some more crazy stuff to build for it! I do have some interesting client side nostr bitcoin stuff being prototyped on the other end 😉 Always looking for feedback and ideas, feel free to reach out!

Updated the btcpay nostr plugin, zaps should be more stable now, but need some help testing plox