Nostr Web Client

what mleku said, and yes, there is a nip for terms but clients don't care. once they scrape that data themselves violating the terms, that's not a relay anymore, that's on the client that delivered the javascript CDN payload from their vercel accounts.

if you're so focused on what tekkadan is running his compiled notedeck, that's not the common path.

Tekkadan, ゲロゲロ! 🐸 5mo ago

Can't say I disagree with any of this which is why I'm running a #Pubky homeserver.

IDK what else I could do to meet my own expectations without building another competing standard. I don't think there's zaps in PK yet but otherwise it seems all right.

nostr:nprofile1qqsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktcpzamhxue69uhk6mr9dd6jumn0wd68yvfwvdhk6tcpzemhxue69uhhyetpd3ujumtvv44h2tnyv4mz7qg4waehxw309a6x2um59ekkcettw5hxgetk9usqc9v8 if anyone has a massive rebuttal for me on this side of the fence it's probably you. Everyone else just wants to bitch about the people who operate it but I see no reason to avoid DHT-backed infrastructure.

Especially with the medium timeframe transition considered, nostr and Pubky have similar goals. One could implement nostr zaps into Pubky and you would have a very incentive-aligned network of possibilities.

Is there some benefit to networks of relays, or, is there otherwise some reason to avoid DHT-driven architecture?

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

the whole point of what is so great about nostr is it's transport-agnostic

it doesn't wed your system to a consensus or a particular type of network

integrating DHT with a mesh network or LoRa low bandwidth connection isn't going to be as easy because DHTs are heavy on chatter, and kinda unnecessary for that context.

why i don't like bluesky is because you get stuck with a federated fan-in fan-out protocol

why i don't like fartcaster is because it weds your message protocol to a proof of stake blockchain, and IPFS, both of which have serious problems for actual censorship resistance (because it's not operating in the dark)

the problem with wedding the protocol to a DHT network is that you are also not allowing for the actual use of rendezvous properly, something that is uniquely valuable and used in the NWC protocol

there's nothing wrong with USING a DHT P2P protocol as a network transport, but you lose flexibility when you couple the messaging protocol to it because you can use it other ways as well, but anyway, as i see it, people who don't get what's so great about nostr is the decoupling, are gonna put their opinion on things by forcing the protocol to bind to whatever they think is cool and the things you can't do with that, will be lost.