Happy Sunday #Nostr !
Here’s your #NostrTechWeekly newsletter brought to you by nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk written by nostr:npub1r3fwhjpx2njy87f9qxmapjn9neutwh7aeww95e03drkfg45cey4qgl7ex2.
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](https://nostr.com/the-protocol/nips))
#### 1) [Remove NIP authors from NIP repo](https://github.com/nostr-protocol/nips/pull/883)
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 merged a change to NIPs which removes all the authors. The reason he gave was to reduce the intimidation people felt in proposing NIPs, or updates to NIPs. Seems reasonable; the NIPs must flow!
#### 2) Updates to [NIP 89: Recommended Application Handlers](https://github.com/nostr-protocol/nips/pull/884/files?short_path=2564c3a#diff-2564c3a6909e547c53b0e20b7dcb73a6e40dbe8a849a5b56bb923219462583f8)
This is actually a change that I think can be applied to any Nostr event, but is specifically useful in the context of NIP 89. This change explicitly outlines an optional piece of metadata on notes for what client generated the event.
This can be useful when clients are encountering event kinds they aren’t able to handle in that client. Knowing the client that published the event is a good indicator of where to point users viewing that unhandled Nostr event to a client that can natively handle the event. Not to mention more easily attributing innovation as new event kinds are used by clients working on cutting edge ideas.
Author: nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft
#### 3) (Proposed) [Overhaul of NIP 51: Lists](https://github.com/nostr-protocol/nips/pull/880/files?short_path=0d42225#diff-0d42225c4bd69ef69ef24d2de380ff90ca763019d04692558a1b78adeda25d50)
NIP 51 as it stands now is a way for users to generate lists in Nostr. They can be lists of users to mute, lists of articles, or a list of relays (for whatever purpose these may serve). This proposal is to overhaul how lists are created and used based on learnings from several implementations since NIP 51 was merged.
One of the bigger changes seems to be not using “patameterized replaceable events” and instead using “non parameterized replaceable events” for publishing some standard types of lists. That means lists can still be updated but you can only have one list of each kind (one mute list, one bookmarks list, etc)
The NIP itself was also a bit hard to read, so nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 cleaned it up in this change as well.
Adopting this change may be a larger lift because some developers have already implemented lists in the current way NIP 51 is outlined.
Author: nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
#### 4) (Proposed) [NIP 86: Review Anything via Nostr](https://github.com/nostr-protocol/nips/pull/879/files?short_path=0c68547#diff-0c6854700bbd41bd872c1bfbd5cb4d821d7ba163fcf50cba880801a1ce3f75e5)
This NIP proposes a Nostr event kind to represent reviews. They can be reviews of anything, but they may include labels to indicate in a structured way what is being rated. This is a great foundation for a sovereign version of everything from Yelp to Rotten Tomatoes.
Imagine an uncensorable restaurant review system, or an experience where you can refine movie ratings based on who you follow (maybe even out a couple jumps). Lots of possibilities.
Author: [staab](https://github.com/staab)
## Notable Projects
#### [Relay Operators Telegram](https://w3.do/2WsY4gdF) 💬
Relays are half of the Nostr protocol but they’re often not the focus of development work. If Nostr is to scale, relays will be the workhorse that will need to be built out to handle it; and there is a lot of work still to do.
There are ~350-400 active relays based on [Relay.Guide](https://relay.guide) and so there is a fairly small community to be organized around relay operation. nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 created a Telegram group to make that a reality. Thanks for inviting people in. 💪
#### [Ontolo](https://w3.do/crBdEoBA) 🏷️
nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc announced Ontolo this week. It’s a micro-app for labeling Nostr events.
Nostr events may need labels for any number of reasons. Content warnings (self-reported or by a third party) are a common use case, but Jeff outlines that this could also be used to label data in a way that’s useful for creating training data for AIs.
It would be pretty cool if Nostr bootstraps a large, open, distributed, and censorship-resistant data set that powers open source AI development of the future.
#### [WavLake and Nostr Wallet Connect](https://w3.do/DaJdBhhh) 🎵
As we talked about last week, content creators stand to benefit the most from Nostr by cutting out the platforms/middlemen where content monetization currently lives. Musicians may be the group of content creators that get the worst deal under the status quo.
WavLake is attempting to change all that by creating explicit support for listeners to zap artists directly through the app. May the value-for-value commence!
nostr:npub1yfg0d955c2jrj2080ew7pa4xrtj7x7s7umt28wh0zurwmxgpyj9shwv6vg
#### [Zapit.live](https://www.zapit.live) ⚡
nostr:npub1cmmswlckn82se7f2jeftl6ll4szlc6zzh8hrjyyfm9vm3t2afr7svqlr6f created a way to monetize any link. Whether it’s a blog post, an unlisted YouTube video link, or music, you’ll be able to monetize content via lightning in a Nostr-native way.
From what it looks like, if someone pays a lightning invoice generated by zapit.live, then they can be DM’d the private link that contains the paywalled content.
It’s great to see work helping content creators make a living. I wonder if we could make it so that content published on nostr:npub1048qg5p6kfnpth2l98kq3dffg097tutm4npsz2exygx25ge2k9xqf5x3nf or nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q could support unlisted content (encrypted when on relay and paying the lightning invoice DMs the decryption key?)
Then we could attempt to convert ZeroHedge’s paid blog to something Nostr based. 😈
## Latest conversations: DVMs
Data Vending Machines (DVMs) are something that seems unique to Nostr. They’re a way for people to request tasks be accomplished and put a bounty on completing the task. Then DVM providers can bid on that task so that the requestor gets the best price a DVM provider is willing to take.
It’s the foundation of a marketplace for decentralized and specialized compute.
#### DVMs for decentralized algorithms
From what I can remember, the motivating force for DVMs to come into existence was to solve the problem of algorithmic feeds on Nostr. We came to Nostr to get away from centralized control of social media feeds, but there’s real value in feed curation. Nostr seems to be the best shot we have at compelling algorithmic feeds, but where the user has choice in that curation.
DVMs are a great solve for this. Users can put a bounty for some small amount of sats asking a DVM to create a curated list of nostr event (representing an algorithmic feed) based on the user’s follows and interests. Users may want to specify the type of algorithm or a set of trusted providers, but they will be able to use market forces to get the best price.
The decentralized nature increases fault tolerance, and motivates DVM providers to create the most efficient and compelling algorithms for curating a user’s feed.
What’s amazing is that the pattern for DVMs can be used to facilitate any algorithmic offering. It started with curating a user’s feed, but it can easily be used for AI image generation or LLM operations, translation, or data extraction of annotation.
#### Does this exist anywhere else?
There are marketplaces underutilized hardware. A great one I read about recently was for GPU compute where anyone with some spare GPU can sell time on their hardware per unit of time.
There are marketplaces like this for a lot of specialized equipment (GPUs, video rendering hardware, genome sequencing, etc). They’re great, but these kinds of transactions are in the tens of dollars, up to millions of dollars, depending on how much compute is needed.
Where DVMs excel is in the realm of software because it’s never been possible to pay for short bursts of discrete compute (running an algorithm). Now that we have Lightning and Nostr Wallet Connect, these micro-transactions can be coordinated in a way that can finally be profitable for the providers.
#### The future of DVMs
DVMs were spawned in the context of Nostr because they’re a good fit for uses cases in Nostr (algorithmic feeds, translation, annotation, captioning, etc).
DVMs could also generalize to any one-shot, algorithmic work that requires limited context. You could even imagine DVMs as a layer between a user and N number of service providers’ APIs. If service providers want to compete, they make a DVM as a bot to call their own API in exchange for money from users.
For example, if LLMs become more commoditized, I could imagine that people just want the cheapest provider of a decent LLM for their application. Developers don’t want to create separate code to call OpenAI, HuggingFace, or any other major future provider. In this world, they just create a request to DVMs in a standard way and the DVMs do that interfacing with those APIs and return a standard response. Or LLM providers like HuggingFace may just offer a DVM as a way to increase revenue by competing in an open marketplace instead of convincing users to use only their API.
This could happen for all kinds of compute, driving down the cost of such tasks by increasing competition and transparency from providers.
#### Increasing adoption today
That future is cool, but what are some things we could do today to help DVMs become ubiquitous?
1. *Clients.* More Nostr clients would need to integrate with DVMs to allow their users to utilize their offerings, so that providers have a constant stream of demand to make offering a DVM profitable.
2. *Standardization.* There are some very obvious use cases, and we’ll need to create standard ways to format requests to, and responses from, DVMs for these use cases so that DVMs providers are more fungible.
3. *Trust.* Users are implicitly trusting the DVM provider to be discrete and not leak their data during processing. Encryption is a good first step, but there may be other ways to make it harder for DVMs to violate the privacy and security of users.
I think DVMs could be one of the killer unique offerings of Nostr that drives wider adoption of the protocol and ecosystem in general. Can’t wait to see what gets built.
## 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 nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk
Stay Classy, Nostr.
Oddbean new post about login | logout