Testing posting with proof of work

Does anyone know of a niche relay or a relay with a specific kind of notes that I'm not aware of? Or maybe a relay some eastern people are using to chat in their own languages?

Still the highest pow event I know of on nostr..

Is this Greenpeace approved? 😜

Alright nostr crew, need some help.

My father in law has an iPod classic with some very sentimentally important playlists on it. Unfortunately the iPod's HD is failing and the computer which he's backed this thing up on is also gone. I was able to extract the iTunesDB file from the drive and as I understand it this file should have the playlist metadata inside? Don't need to recover the actual mp3's just need the playlist names and list of songs contained. Anyone have any tips?

Willing to pay!

Does anyone know of a niche relay or a relay with a specific kind of notes that I'm not aware of? Or maybe a relay some eastern people are using to chat in their own languages?

👀 Got lucky on this one, target difficulty of 16 but got 23(!) leading zeroes.

Good Morning Nostr Denizens. At the request of my users the latest push of more-speech prunes all the tab windows to a config specified number of events once every hour. This should keep memory usage down, as well as preventing the event window from having to re-render too many events every time you move it to a new screen, or wake up from sleep.

POW=16 is basically unnoticable on my laptop, using gossip client.

I really think the clients should at least render if POW has been done. Then worry about how to use the fact later. #[4] #[3] #[1] #[2]

.

Bitcoin must-read book pile:

#[0]

+

I'm not saying tha REST is the right way to go. Just that it would be nice if a client to request POW (over a websocket is fine) without having to implement the auth nip.

And I can't imagine how a deep dependency graph could ever be a good thing. Modularity is one of the most important principles of design. You should be able to pick and chose which nips you implement without having to parse through a tree of interdependencies.

The issue is a REST service is not ideal as clients are already connected to at least one websocket. And the POW can take seconds to return a result. Since websockets make sense, using the auth NIP made sense too - as clients already support it (or will soon).

The idea was it can be run independently from a relays or a relay could enable the POW command optionally - using a supported nip in their server info.

Relays are the closest next step for events that have had POW/signed.. so it made sense to keep them together or very close.

The POW nip already explains the basics to add POW, so this was more of a NIP for a provider that had opinionated design.

There is also a growing dependency graph of NiPs that build on other nips. I see it as good thing, but it does make it harder to start from scratch.