Happy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by NostReport (npub19md…6vzk) written by greg (npub1r3f…7ex2)
#NostrTechWeekly is a weekly newsletter focused on the more technical happenings in the nostr-verse.
Many great discussions this week. Let’s dive in!
Recent Upgrades to Nostr (AKA NIPs)
1) (Proposed) NIP 34: Wiki 📜
Wikipedia is flawed because there’s only one article per topic which forces everyone that works on Wikipedia to fight out what is “true.” This will always lead to people claiming whatever is on Wikipedia is “the truth” because there’s only one article per topic.
Google experimented with a Wikipedia alternative called Knol which was similar, but anyone could submit an article on a topic and then it was by the voting of users that determined the top articles for that topic. The theory being that readers could go through multiple articles on the topic from different perspectives and determine the truth for themselves.
What fiatjaf is proposing in this NIP is very similar to Knol, but published via Nostr to give it more censorship resistance than Knol. With reactions and bridges to other knowledge bases, we could quickly bootstrap a nostr-based rival to Wikipedia with more nuance and debate baked in.
Author: fiatjaf (npub180c…h6w6)
2) (Proposed) NIP 17: Event Metadata ℹ️
When clients are displaying a note published by a user, there are often things about that note which would be useful to display to users reading that note. E.g. how many comments, reposts, and reactions there are. These are often computationally and time intensive operations for a client since they’ll need to query many relays to get a reasonably accurate count.
This NIP proposes that relays could optionally add such information as metadata on each note as it is returned to clients so they do less work to get that information. Both clients and relays would benefit from needing to do less work to give users the same, good experience.
Author: arthurfranca
3) (Proposed) NIP 34: Algorithmic Filter 🔍
One of the possibilities that makes Nostr great is the chance at algorithmic choice. People may want no algorithm, or a light algorithm to dedupe their feed of the same note being reposted by a dozen people, or a heavier algorithm to curate their feed and help them discover new content.
This NIP proposes a way for relays to support generic algorithms for ordering notes so that clients can query for notes from relays in a way specified by the indicated algorithm. There is also a concept of “seen at” which will allow users to tell relays they’ve seen a note so that it won’t show up in future algorithmic queries for notes.
This is still under development and refinement, but looks very promising.
PS - Yes this is also NIP 34, so whichever gets merged first gets the number I guess?
Author: arthurfranca
Notable Projects
relay.tools
Relay.tools is a tool for quickly spinning up relays. You can specify a subdomain of nostr1.com and pay a lightning invoice, and they’ll spin up a relay at that address for use by the nostr-verse.
Looks like this is under continued development, and could become a useful tool for creating, discovering, and educating folks about relays.
Author: nostr: cloud fodder (npub10np…tl5h)
Email style subscriptions
Getting notified about certain posts is difficult on Nostr. If you want to subscribe to this publication, for example, you have to follow us and look for when it’s published every week 😅.
Wouldn’t it be great if you could subscribe to a publication and a link would be DM’d to you when it was published? It’s not a new concept, newsletters have worked like this for decades, but we don’t have an email-like system on Nostr.
franzap (npub1wf4…dgh9) took a stab at creating a way to “subscribe” to something and then it’ll be NIP-04 DM’d to you when that account publishes in the future. It’s currently a proof of concept, but there’s likely something there to help folks who don’t want to have to use a different client just to see their subscriptions, or scroll endlessly to make sure they didn’t miss anything.
Better Backups
In case you’re unaware, many relays will erase notes published to them after they reach a certain age. This is done primarily to save on hosting costs, especially for free relays. This makes sense, but it presents a problem around data retention for Nostr users. Even paid relays may go out of business, and then your data is lost forever (unless it’s on other relays).
It’s been a common ask that there was some way to backup our data quickly and easily. Either to a private relay or to spread the data to more active relays so that there’s less chance of data loss.
iefan 🕊️ (npub1cmm…lr6f) and npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj (npub1226…grkj) have done a great job creating a backup service that now takes seconds instead of minutes. And it looks like iefan 🕊️ (npub1cmm…lr6f) will be adding features to make it easier to port that backed up information around (as a file, to other relays, etc).
Huge load off my mind having a backup of my account (even all the reactions and comments on my notes) in case there’s loss somewhere else in the nostr-verse.
Latest conversations: Custody of Private Keys
The state of private keys
If you have the private key for a Nostr account, then you own that Nostr account. You can publish notes as that account, you can change the profile info, you can ask relays to delete notes for that account. It’s total access.
Even still, many clients require that you paste your private key into a text box and allow the client to use the key to publish events as you. The best clients store the key only locally on your device so the client’s developers never have access to your private key. It’s becoming clear that some clients are storing private keys off-device and that comes with trade offs.
ZBD controversy
A discussion was started about how ZBD seems to store private keys for Nostr accounts on their servers. If ZBD is able to use those private keys to help users publish events, then ZBD could theoretically hand those private keys over to third parties (three letter government agencies, advertisers, etc). There’s a tremendous amount of trust users should have in ZBD when giving ZBD that power.
The spectrum of self-custody
On one extreme, users totally give up control: many folks don’t understand private key/public keypairs and so want to offload the cognitive load to a trusted third party. They’re willing to give their keys to a third party and have that third party do all the signing and publishing of Nostr events on their behalf.
On the other extreme is using a NIP-07 browser extension. This means that a Nostr client has to ask for your permission whenever it takes an action that requires your public or private key. That way the client never touches the private key, it just asks the extension to sign events before publishing them to the users’ relays. If you’ve ever used it, the popups are incredibly annoying after a while.
Is there a better way?
Is there a middle ground where users don’t have to manage annoying popups, but can be in complete control of their keys?
Theoretically you could have a third party service that: Stored public and private keys for a user in an end-to-end encrypted way, so that they can’t give anyone access to your keys even if they’re hacked. Allowed users to have a username/password/2FA interface for logging into the service and retrieving their keys (maybe the password is the encryption key).
This would allow folks that don’t understand private/public key pairs to have a familiar experience without compromising their security.
It may even be possible to extend the capabilities to make it truly an all-in-one solution for Nostr account management. Give users an OAuth experience for logging into clients (Login with WhateverYouCallIt button instead of pasting in a key) Allow users to direct requests for access to private/public keys from Nostr clients to this third party to be authorized by the user (like NIP-07) Allow users to store and update preferences of how much you access each client should have. Avoiding constant popups whenever a user is using a client they already trust.
In order to attract normal, everyday internet users we’ll need to give them an experience they expect and understand. And I think we can do that without compromising security like we’re seeing with clients that store a user’s keys on their servers.
Next week: Privacy on Nostr
A discussion was started around an architecture to allow private nostr interactions via P2P interactions between users and clients (bypassing relays). There’s not a ton of detail yet, but it’s a hot topic and next week we’ll dive in more.
Events
Here are some upcoming events that we are looking forward to! We keep a comprehensive list and details of Nostr-related events that we hear about (in person or virtual) that you can bookmark here NostrConf Report
- Nostrasia Nov 1-3 in Tokyo & Hong Kong
- Nostrville Nov 9-10 in Nashville, TN, USA
- NostrCon Jan 12, 2024 (online only)
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.
Stay Classy, Nostr.