Show thread history
Anthony Accioly
5d ago
I get where you’re coming from. I’ve tested BEP-39 in real use cases, and I was impressed by it. From keeping a folder full of Markdown files in symc to ensuring I always download the latest episode of my legally licensed, totally fine-to-download favourite show, things just show up automatically in my torrent client without hassle. The update URL just points to the latest version of a torrent file and from there things just work.
Having said that, update cadence could be parameterised as well. Think njump. It’s smart enough to fetch my notes individually, but it doesn’t need a real-time view of my latest notes. So both the master "relay/tracker" and clients could pace themselves according to their own needs.
I really like your idea of storing a copy of someone's kind-10002 events on DHT! Probably also kind-10050 and maybe other discoverability-related notes. That’s an awesome idea.
On a similar front, despite my dislike for anything that relies on DNS, NIP-05 nostr.json could also hold a copy of all this. Kind of like what you did with the relays array, but on steroids. In other words, NIP-05 identity servers would function similarly to WKD for GPG. If you know someone’s nip05 identifier, you can retrieve all the info you need from there, no need for a second pass on a relay.
Having said that, update cadence could be parameterised as well. Think njump. It’s smart enough to fetch my notes individually, but it doesn’t need a real-time view of my latest notes. So both the master "relay/tracker" and clients could pace themselves according to their own needs.
I really like your idea of storing a copy of someone's kind-10002 events on DHT! Probably also kind-10050 and maybe other discoverability-related notes. That’s an awesome idea.
On a similar front, despite my dislike for anything that relies on DNS, NIP-05 nostr.json could also hold a copy of all this. Kind of like what you did with the relays array, but on steroids. In other words, NIP-05 identity servers would function similarly to WKD for GPG. If you know someone’s nip05 identifier, you can retrieve all the info you need from there, no need for a second pass on a relay.
See translation
1
0
0
0
0
Replies
Mike Dilger
@Mike Dilger
♥︎ by author
5d ago
I don't think we should have multiple ways because (1) it adds complexity, (2) it adds overhead (have to check them all), (3) things get out of sync. The DHT thing is a neat idea but nostr already has an effective solution without it. And the nostr.json relays came about before kind 10002 did, and maybe even should be retired, because mine keeps falling behind and getting out of sync.
See translation
1
1
0
0
0
Anthony Accioly
@Anthony Accioly
5d ago
I don’t disagree in principle, but in practice… kind-10002 as it is now isn’t sufficient. This is a chicken-and-egg problem: I need to connect to an unknown relay to fetch Mike Dilget’s kind-10002 event in order to figure out which relay I need to connect to in order to find Mike Dilget’s notes. It’s a strange way of bootstrapping things unless we accept relay centralisation or widespread blasting / Negentropy. IMO, the first is undesirable, and the second is wonky, it introduces eventual consistency at best and indeterminism at worst.
This isn’t a criticism of the Outbox model by the way. It’s definitely the way forward, but I think we need an efficient, hopefully deterministic, single-call way of doing this. And this has to be done without relying on Damus, nos.lol, Snort or whatever other giant relays to hold every single kind-10002 (or equivalent) in existence.
This isn’t a criticism of the Outbox model by the way. It’s definitely the way forward, but I think we need an efficient, hopefully deterministic, single-call way of doing this. And this has to be done without relying on Damus, nos.lol, Snort or whatever other giant relays to hold every single kind-10002 (or equivalent) in existence.
... See more
See translation
0
0
0
0
0