mikedilger on Nostr: > so yes it works well, but can it scale to be the next web? I'm not satisfied that ...
> so yes it works well, but can it scale to be the next web?
I'm not satisfied that it can.
> In fact it is quite difficult to make a DHT network separate from Mainline if it is compatible.. because only one dude can force both networks to merge
Same with nostr. Hard to make an isolated nostr bubble. hodlbod (npub1jlr…ynqn) has to invent new systems on top of nostr to isolate his church group.
> where as there is a whole social graph and happenstance that is involved in Outbox model
I don't think social graphs have anything to do with the idea that people will declare where they publish (rather than readers signing up and asking you to copy them). The happenstance that does exist is that there needs to be some overlap in the relays that people use for getting at the bootstraping information (the kind 10002 relay lists).
But let me divert just a second. There are two ways to use a DHT here (1) to augment NIP-65 by serving kind-10002 events, or (2) to replace NIP-65 by being the relay lists. In case (2) I would need to insert into the DHT a record in the form
secp256k1-pubkey => Vec<(Url, Usage)>
and I would need to change that data whenever. Is that possible? Is that how pkarr works?
> ... ed25519 keys...
Ok. Sounds like this is better for a nostr-next idea, since we are stuck with secp256k1 keys.
I'm not satisfied that it can.
> In fact it is quite difficult to make a DHT network separate from Mainline if it is compatible.. because only one dude can force both networks to merge
Same with nostr. Hard to make an isolated nostr bubble. hodlbod (npub1jlr…ynqn) has to invent new systems on top of nostr to isolate his church group.
> where as there is a whole social graph and happenstance that is involved in Outbox model
I don't think social graphs have anything to do with the idea that people will declare where they publish (rather than readers signing up and asking you to copy them). The happenstance that does exist is that there needs to be some overlap in the relays that people use for getting at the bootstraping information (the kind 10002 relay lists).
But let me divert just a second. There are two ways to use a DHT here (1) to augment NIP-65 by serving kind-10002 events, or (2) to replace NIP-65 by being the relay lists. In case (2) I would need to insert into the DHT a record in the form
secp256k1-pubkey => Vec<(Url, Usage)>
and I would need to change that data whenever. Is that possible? Is that how pkarr works?
> ... ed25519 keys...
Ok. Sounds like this is better for a nostr-next idea, since we are stuck with secp256k1 keys.