Ok first of all, NIP-05 is out of the question. It's not signed, it's not a contender here. That was just to make it easier to find someone, back when we didn't have better ways. It was my idea to put it into nostr.json in the first place, so I am shooting down my own idea.

My newer idea is expressed in NIP-65, which is just to spread that kind-10002 event to hundreds of relays (while only using a few relays for regular events).

I've always been in favor of relays or servers that specialize in serving kind-10002 events. I was going to suggest if someone does a DHT to put the kind-10002 events in there. Sounds like that is already part of your idea.

It seems that if all the clients move over to publishing into a DHT, then a DHT would have the advantage that all the data would be in it (the hash table being synchronized, I presume), whereas if you just ask a popular relay, it might not know, and you could never know for sure if that was because the relay didn't know or because the data wasn't there. BUT that property doesn't appear unless and until everybody moves to using the DHT. And I'm not sure people will because of the chicken-and-egg problem.

But a DHT seems like (even though it is distributed) a potential single source of failure. If there are "root servers", how many are there? Can they cheat?. Can things be removed from or replaced in a DHT, and if so, cant someone censor data out of it, and then replicate that censorship widely? If not, how is that enforced? I admit to my ignorance on this point.

wait, you still think nostr is about social networks?

I’m waiting for an audio event type where you get to hear a snippet of a podcast highlight. Zap the fee and then entire audio unlocks encrypted directly to your pubkey.

每天看着nostr和lightning肉眼可见的变得好用 速度惊人 多少让我有点盼头

wallet of satoshi开testflight 可能适配nip57不远了 现在已经可以看到zap发的信息了

今天弄了弄lightning tips bot 觉得telegram搭配一些bot什么的确实好用

is there any site in existence, where given a note ID, it will tell you how many relays it has seen it on?

service (checkout service):

seller:

register product -> share to nostr button

user:

sign up on checkout service just once -> put pubkey, shipping details just once

nostr:

user zaps product -> nip57 receipt comes back to nostr

checkout service:

receives nip57 event -> fulfills purchase -> begins last mile process

凉州黄牛肉火锅已经超越潮汕牛肉火锅了吗？

对我来说是。

电猫应该能搞一下😀

但用户总有过滤内容的需求，过滤就要靠代码，要不就在客户端写，要不就在relay端写，我的感觉也是relay端更好一些

一是浪费流量，一是效率不高

我现在更倾向于在客户端过滤，我可以自己定制规则，并可以确认。

尽量坚持“dumb relay, smart client”

That’d be very similar to the hypercores/Slashtags model