quoting note1g7u…8qveHappy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by NostReport (npub19md…6vzk) written by greg (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) (Proposed) NIP 71: Video Events
If Nostr wants to disrupt Netflix or Youtube, we’ll need support for video content.
So far Nostr devs have mostly shied away from storing full files (videos, PDFs, images, etc) on relays in favor of storing files on dedicated file storage/CDN solutions (e.g. nostr.build). That has meant that to bring file-based content into the nostr-verse it has to be referenced within a note or (via NIP 94 ) just publish a Nostr event that is just a reference to a file.
NIP 94 is powerful because we can wrap something that’s not on Nostr in a Nostr event which makes it referenceable and make that reference shareable natively via relays.
This proposal is to create a wapper around NIP 94 to help facilitate more than just hosting the video content. This proposal helps allow video-based clients to do two things: 1) create a replaceable nostr event for the video (so if the creator uploads a new version or switches hosts, people can still reference the same Nostr event). 2) Track video view counts.
It’s still under development but could be helpful as we try to bring more content creators over to Nostr 💪
Author: zmeyer44
2) (Proposed) NIP 44: Places 🌏
Much physical commerce is discovered by consumers via map apps. You go on Google or Apple Maps to find an art supply store near your apartment, or coffee shops that are open right now when you’re in a new city. These centralized solutions have dominated, but Yondar seeks to change that.
Yondar is a Nostr client that allows users to publish places on a map. This could be places of business or events, really anything that has a location. It could unlock crowdsourcing the place-based apps we’re used to using, so we can wrest control back from the tech giants.
This NIP is a proposal to make “place” events a protocol that’s available to any Nostr client. So that the idea can spread beyond just Yondar. Can’t wait!
Author: arkin0x
Notable Projects
Updates to negentroopy and strfry 🛜
Doug Hoyte (npub1yxp…qud4) is the primary author of the StrFry relay. It’s one of the most popular relay implementations used by relay operators because it’s performant and extensible.
Doug announced a slew of improvements this week to a library underpinning strfy, called negentropy. Negentropy (from my limited understanding) is a protocol for set-reconciliation, which I would summarize as optimizing the process of syncing two sets of data quickly and with minimal compute resources and data transfer.
I don’t know the innards of strfry but I do know that when scaling systems like relays much of the difficulty comes from distributing data onto many servers so that the relay can hold increasing amounts of data but still serve users requests quickly. You usually can’t have your cake and eat it too.
Improvements to projects like negentropy allow us have relays which are both larger and more performant. They’re not the sexiest advances and usually go un-celebrated, but Nostr will be faster for users and relay operation should get cheaper because of this project.
Thanks Doug!
StrFrui ✔️
Relays are inundated with new events constantly and sometimes relay operators want to “sift” through new Nostr events pushed to the relay to ensure that unwanted content can be rejected. This has been done for rate-limiting, spam filtering, and sometimes outright npub censorship. Which as a relay operator is their right.
Problem is, as Nostr usage scales, relay operators will need more sophisticated tools to manage content on their relays. jiftechnify (npub168g…2dlc) built StrFrui which is a framework for building sifters for relays running strfry (common, performant relay). Thanks for helping Nostr scale 🫡.
Latest conversations: nsecBunker
The landscape for security of Nostr keys is rapidly evolving. Here are the current options:
- Paste your nsec into the client - yikes, but sometimes there’s no alternative, like on iOS Nostr Browser Extension (nos2x, Nostr Connect, etc) - good if you’re on a browser, not encrypted at rest.
- Android Signing App - great if you’re on Android and the client supports it.
- nsecBunker - great security if you want to be hands on managing a bunker
We’re early so we’re still learning the architectures that work the best and those that will be compatible with future, more user-friendly experiences. I’m starting to think nsecBunker has the most potential, because it’s cross platform, encrypted at rest, and can be built so that users never have to manage Nostr keys if they don’t want to.
How does nsecBunker work?
Short answer: it’s complicated. Slightly longer answer:
- Give the bunker your nsec (or let it generate one).
- You authorize a client with certain permissions (can publish kind 1 notes for 10 hours, etc).
- That generates and npub+token that you can use to log in to clients that support nsecbunker.
- While that authorization lasts, that client can take authorized actions on behalf of the user who’s key is in the bunker.
There’s also a flow in reverse (starts with the client wanting to take an action), but I’m not going to get into it right now. It’s much harder to explain.
How is this better?
NsecBunker has a few advantages over other solutions:
- Users never need to copy/paste the nsec
- Nsec is encrypted in the bunker with a passphrase so even if bunker is hacked you’re ok.
- Bunkers can work in any Nostr context (browser, mobile app, hardware device, whatever).
The biggest downside to nsecBunker is that you need a Nostr account to be the admin of the keys stored in the bunker. Whereas the Nostr Browser Extensions you can have one account and self-manage it.
The pot of gold at the end of the rainbow
There are always going to be people that want to custody their own Nostr keys, but most humans likely won’t have the knowledge nor inclination to do so. What they want is something that’s more like the “Login with Twitter” button.
In this future, a user would sign up with a Bunker provider (these could be paid services). The user would use a email/password to manage their account with the provider. The user could generate as many Nostr accounts as they like, but the Bunker custodies the keys.
Clients would then have a “Login with Bunker” button that allows the user to put in their Nostr address (NIP 05) and that will be de-referenced to a bunker and a few relays to help the client and the bunker do all the coordination to get the user logged in and ready to use the client. It will basically be OAuth but using Nostr events as the transfer protocol instead of just HTTP requests.
This architecture allows the least technical users to have a familiar experience while benefiting from all the security and control tools that sophisticated companies still struggle with.
Best of all, if users can export their keys in the future, then they can always migrate out of a custodial solution and self-custody once they learn the advantages. More freedom for users and freedom tech still gets more accessible to everyday folks. PABLOF7z (npub1l2v…ajft) created a proof of concept of just such an onboarding flow, check it out here.
What needs to be built
While bunker providers would need to build some management software around nsecBunker (user/subscription management, passing along permission requests to users, etc) most of the work to make this possible is client-side.
More clients will need to support the authorization scheme that nsecbunker requires. This would require new login capabilities, as well as supporting nsecBunker style remote signing capabilities (to delegate authorization to the nsecbunker instead of relying on the user’s nsec being on the same device as the client).
It’s not insurmountable, but it is not trivial; and if history is any guide, client adoption will take time. We’ve seen that Nostr browser extensions still haven’t become universal, even though most developers will tell you they should be mandatory at this point.
My prediction is that iOS clients will lead the charge because iOS doesn’t have the same ability as android for apps to interact with each other (via Android Signing Apps) so nsecBunker may be their only way for iOS clients to stop requiring users to paste in their nsec directly into the client 😬.
I think we’re well on our way to this future, and it’s one that will be much easier for normies to utilize while still allowing for people to opt-out and self custody if they wish.
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.
greg on Nostr: This week is focused on nsecbunker and some improvements to relays! ...
This week is focused on nsecbunker and some improvements to relays!
