Happy Sunday #Nostr !
Here’s your THE #NostrTechWeekly newsletter brought to you by <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>NostReport</span> (<span class="italic">npub19md…6vzk</span>)</a></span> written by <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1r3fwhjpx2njy87f9qxmapjn9neutwh7aeww95e03drkfg45cey4qgl7ex2" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>gregwhite</span> (<span class="italic">npub1r3f…7ex2</span>)</a></span>
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) (Proposed) NIP 41: Simple Key Migration
One of the big worries of Nostr users is pasting that all-important secret key into a new client and wondering if they’re going to fuck you over down the line.
If this happened you’d just create a new private key/public key pair and ask your followers to follow the new account. Now there’s a structured way to do this; plus some helpful features to prevent abuse.
This NIP introduces two new kinds of events: An event where you authorize (with your current Nostr account’s keys) potential future Nostr accounts may migrate to in case of a compromise of your current account. (Kind 1776) An event to actually announce a migration to one of the pre-authorized accounts. (Kind 1777)
Both must have OpenTimestamp attestations to prove the “created” timestamp on the events are accurate. This is important because after 60 days without a contested 1777 clients are expected to automatically update users’ follow list from the old pubkey to the new pubkey.
In the event of a private key being compromised and a hacker publishes a new 1776 (to authorize a fraudulent new pubkey) and a 1777 (to migrate to the key they just authorized) the original user has 60 days to publish a 1777 using the old 1776 whitelist. Otherwise the fraudulent 1777 will take effect.
Authors: <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>PABLOF7z</span> (<span class="italic">npub1l2v…ajft</span>)</a></span> <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>fiatjaf</span> (<span class="italic">npub180c…h6w6</span>)</a></span>
2) (Proposed) NIP 108: Lightning Gated Content
Substack has an advantage over a traditional blog because authors can enforce that they get paid before content is consumable. Zaps can only go so far for monetizing content in a structured way. This NIP introduces general purpose lightning gated content.
The way it’s architected, a content creator would publish the paid-only content in an encrypted fashion and publish to relays. They’d essentially be selling the decryption key through this process.
There would be a third party “gate server” which would accept requests for the decryption key, which would present the requestor with an invoice. Once paid the user can request the decryption key, if the invoice is paid the gate server will return the decryption key. The user who paid for the key can now take the publicly accessible (but encrypted) content and decrypt it for consumption.
If this becomes common then Damus would finally, actually be in violation of Apple’s app developer guidelines around “content unlocked via payment” and giving Apple their 30%. 😅
Authors: coachchuckff, excalibur_guild
Notable Projects
Coracle web of trust 🕸️
Knowing how many of the folks you follow also follow a specific account is a useful signal on how trusted that account is. This idea is core to the concept of “web of trust” where our followers are helping us build trust with their followers and vice versa (it’s a web-like pattern).
Coracle implemented a way to refine your global feed to only content from folks that have a certain number of your followers following them. If you set this too high the feed won’t have much content, but if you set it to more than 0, then you’re less likely to get spammy content. Definitely improves finding people to follow.
Author: <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>hodlbod</span> (<span class="italic">npub1jlr…ynqn</span>)</a></span>
Friendstr 🫂
In the same vein as the web-of-trust feature from Coracle, Friendstr is a way to find people you should be friends with (or so the idea goes).
This client analyzes your following list and shows how many folks that you follow in common; which is some indication of how similar your interests/social circles are. Very neat and could lead to more social connection. ♥️
Author: <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1cpstx8lzhwctunfe80rugz5qsj9ztw8surec9j6mf8phha68dj6qhm8j5e" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>captain ☦️</span> (<span class="italic">npub1cps…8j5e</span>)</a></span>
njump 🔗
Ever wanted to share Nostr content with someone without assuming the Nostr client they’re using? Usually you just send the note ID, or npub, or naddr. All of which aren’t recognized by most places where you do the sharing (Telegram, Discord, Twitter, iMessage, etc)
Cue Njump: creating shareable links to Nostr content. The best part is that Njump gives great previews of the Nostr content so that places like Telegram, Twitter, etc can display a nice preview like every other kind of social link.
Honestly the only reason we don’t use this in these articles is because the client we use to publish it (habla.news) recognizes Njump links as links to Nostr content and automatically embeds the Nostr event instead of just showing a link to the content 😬. Sometimes you just want a link, not an embed.
Author: <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>fiatjaf</span> (<span class="italic">npub180c…h6w6</span>)</a></span>
Nostr Potatoes 🎥
Hooray for a decentralized version of Rotten Tomatoes!
We can own our reviews and respect the reviews of our social circle instead of unnamed “critics” or the masses of people with heterogeneous tastes. Rejoice, for this is the freedom Nostr can bring.
All levity aside, this is very creative, and a damned good use case for the decentralized and social nature of Nostr.
Author: jrc-dev
Latest conversations: Privacy and Security on Nostr
What is (the) Nostr good for?
Proving a piece of content was authorized by a specific pubkey Distributing that content widely in a way that is censorship resistant
The first is the foundation of any social media, no matter the content type (text, images, video) or consumption interface (phone, tablet, laptop). Nostr is better at doing the second part than any other social media out there.
What is Nostr NOT good at (for now)?
Privacy and security.
One of the fundamental tenets of cybersecurity is don’t leave your equipment nor data lying around where people can access it. Nostr stores our data on relays which gladly retrieve it for anyone that asks. Given enough time, encryption can be cracked. Given enough examples of encrypted data encrypted by the same key, the time to crack it rapidly decreases.
You might ask, “then how is anything sent securely over the internet?” Data is stored securely, on private servers. It’s only in the sending that there’s risk, and the architecture of that sending is fundamentally different from how Nostr works and that architecture makes it much harder to attack.
Data transferred via https is ephemeral, the sender encrypts the data before sending it off. The data is passed between many servers to get it to the receiver. The servers in the middle are meant to forget that data after the transfer is complete. (I’m aware of the NSA’s role in this, but I won’t get into it right now) Unless the data is intercepted the data isn’t stored, much less in a way that the public can query for.
Nostr data on relays is intentionally not ephemeral, it’s one of the fundamental design decisions that makes Nostr good as a censorship resistant protocol.
What do you want the scope of Nostr to be?
Many debates around technical challenges on Nostr boil down to the question of “what do you want Nostr to be?”
Nostr won me over because it was a way to publish content in a censorship resistant way. Activists, builders, political figures, journalists can all use Nostr to publish their work, even if it’s controversial enough that centralized platforms censor it. That is an incredible gift to humanity if we can spread it.
Over time, my imagination has grown to see Nostr also as a way to decentralize digital identity. We are building a digital identity as we use Nostr (even if under a pseudonym). From a technical perspective there are some great applications outside of social media for Nostr users authorizing actions using their Nostr private key (signing a contract, “login with Nostr”, etc).
I’m tempted (as I see many are) to pursue Nostr as the foundation of a more free internet. Rebuilding WhatsApp, Substack, Craigslist, Google Drive, Docusign, etc. would be awesome. The fundamental challenge is whether that will work, in a technical sense, on Nostr.
People deserve security and privacy in their digital lives just as much as they deserve being uncensorable. Until there’s a technical solution that allows Nostr to handle data that we want to be private and secure (indefinitely) I’m not sure it’s wise.
Secure and private comms on Nostr
One way I’ve heard to solve the technical issues around privacy and security for communication via Nostr is making it more Peer to Peer. I haven’t seen a detailed technical architecture of the strictly P2P version, but my understanding is that data would be transferred via relays but it would be more ephemeral and gift wrapped so that the real metadata (from, to, created timestamp, etc) isn’t even known to the relay operators.
This would make Nostr more like the open internet of decades past. Our relays would take the place of the DNS servers (how computers find each other), and clients would likely store the sensitive data on users’ end devices (their phone or computer) instead of storing that data on the relay or in the cloud.
If the technical implementation works out, this would solve for secure and private communications, but wouldn’t help with other use cases (Substack, Google Drive, Docusign, etc).
We may be yet to discover a way to solve every technical challenge and make Nostr secure, private, and censorship resistant for any app we can think of. What’s great about Nostr is that people keep building and trying things. And when they provide value, people adopt the product.
Can’t wait to see 💪
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 <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>NostReport</span> (<span class="italic">npub19md…6vzk</span>)</a></span>
Stay Classy, Nostr.