Happy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by written by
#NostrTechWeekly is a weekly newsletter focused on the more technical happenings in the nostr-verse.
NIP activity seems to be slowing down, but it’s made up for by plenty of Nostr development. Let’s dive in!
Recent Upgrades to Nostr (AKA NIPs)
1) NIP 24: Extra Optional Fields
NIPs often define new kinds of events that can be published to relays. Whether it’s a basic text note, a zap receipt, a blog post, whatever there is data that MUST be included for the event to do its job.
Over time devs find some additional data useful to making that event work better; they’re not required but they are helpful. Until now this was just knowledge in the heads of developers; now there’s a NIP where it seems like we’re going to collect definitions of optional data for various types of Nostr events.
Author:
2) (Proposed) NIP 105: API Service Marketplace
Many services provide APIs to developers to build on top of that service. For example Nostr.watch provides an API that’s the best source of a “full” list of relays that are in operation. They happen to make that freely and publicly available. Sometimes it makes sense to charge for an API.
There’s always difficulty charging based on usage of an API, because charging per request in the world of fiat, where fees are 3% with a minimum of 15 cents, is too expensive. What ends up happening is a daily, weekly, or monthly charge for a user’s usage, and that adds risk to the provider that they won’t get paid.
This NIP outlines a way to allow a per-API call transaction using lightning. So that the user only pays for what they use and the provider gets paid immediately. The first obvious usage case is providing an API to access OpenAI’s API and charging on a per-request basis.
Authors: CoachChuckFF UncleJim21 cmdruid
Notable Projects
Exit
Many former Twitter users had a lot of great content locked up in Twitter’s (now closed) ecosystem. Thanks to we now have a way to take our personal Twitter archive and broadcast each tweet as a nostr note.
This seems obvious as a way to make people feel better about leaving the Twitter ecosystem because they aren’t leaving anything behind. In fact, they’ll now own that data and control it forever.
Prisms
When the first post about Prisms came out I remember reading the note like 5 times asking myself: “But what is a prism?” Fortunately, wrote an excellent article about Prisms, and credits the initial idea to
Read the article here
Prisms are a way to split a single payment into many. The Nostr use case for this is paying out to multiple people when zaps are made to a note. Imagine one person announces a new nostr product but there are 3 devs. All zaps should go to all devs so a prism can be created to help with that.
Author: and and
Nostr.Cooking
Ah yes, we Nostriches love the joys of cooking (I’m looking at you #garlicstr). I have heard many suggestions that we should have a nostr-equivalent to allrecipes.com. It seems like a natural ecosystem to live on Nostr, where people could have the ability to create, publish and receive tips for good recipes. Also the open ecosystem of Nostr lends itself well to people copying and tweaking recipes and publishing that new version.
That’s why https://nostr.cooking is such a wonderful addition to the nostr-verse. I can’t wait to try some recipes out and attempt a few forks myself.
I do think these are published as kind 1 events though, so they’ll show up just like any other basic text note. I wonder if a new event kind would be appropriate. There’s enough structure to the recipes to warrant it, and it would allow for interesting features for recipes, such as the ability to scale a recipe’s ingredients list depending on how many people you’re cooking for.
Author: and
nostrsync.live Backups
One of the challenges of Nostr is ensuring you don’t lose any data. Many relays will delete events after they reach a certain age, usually to save on hosting costs (especially on public relays).
It’s also been a challenge to find a good backup system that also broadcasts events back onto relays that may have already “forgotten” the event. strikes again in his quest to make the perfect backup and broadcast experience.
Nostrsync.live will query events from dozens of popular relays, create a unified list, and then rebroadcast all the events onto many popular relays to ensure your data isn’t lost and others can access it well into the future. Thank you!
Latest conversations: Historical Nostr Events
Data Retention
As mentioned above regarding backups, many relays will delete old events. It’s an easy shortcut to keep up with ongoing Nostr usage without hosting costs ballooning for relay operators.
is ensuring that eden.nostr.land will retain events for paid users indefinitely, but I haven’t heard the same promise from other paid relay operators yet. It’s not cheap to do! Especially as the amount of Nostr traffic and notes grows over time.
also said this week also that scaling relays is going to be hard. I imagine the proximity of that note to the one about eden.nostr.land retaining events indefinitely means they’re related 😂.
Operating a service like Facebook or Twitter gets expensive, especially at scale, even more so when each user can have a decade or more of history on the product. Centralized services are generally more cost efficient as well so it’s unlikely a decentralized system like Nostr leads to a cheaper outcome. Relays that are fast and hold your data indefinitely likely won’t come cheap.
Event validation
Many relays also won’t accept events where the created date of the event is too far into the past, because there’s no way to validate that the event was indeed created at that time unless the relay receives the event close to the indicated created date.
This isn’t super important for reactions to a note but there are all sorts of shenanigans that can be pulled if you can retroactively publish things (a simple example is publishing that you made a certain bet after the outcome is decided).
I’m not sure if Nostr needs to solve that problem, but certain applications won’t be a good fit for Nostr if we don’t. If we’re ok with that then relays don’t need to reject events that were created far in the past.
If we do reject old notes being re-broadcasted then we’re going to introduce a problem with users moving between relays. Imagine I was paying for a relay that had all my data, but one day I decide they’re too expensive and someone else is offering the same service for cheaper. If that new relay won’t accept my old events then I’m basically wiping my entire history of content in order to move relays.
Possible solutions
NIP 3 uses Open Timestamp where if you have a valid attestation you can put that on the Nostr event. That is essentially outsourcing credibility of the timestamp to a third party. So it’s only as credible as the third party.
There are some attempts like Nip 77 to create more web-of-trust via clients and relays as a proof of a valid timestamp. It’s still under development and discussion. I wish them luck, I’d love to see a nostr-native solution.
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). We haven’t heard more details yet, but when we do we’ll report in 💪.
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.