Nostr Web Client

I was thinking bout this one since #amethyst seems to support it https://github.com/nostr-protocol/nips/blob/master/94.md

I don't think the problem is storing the hash/magnet rather gaining a consensus on which p2p protocol to use if any.

Web torrent is a torrent only in name - since webrtc was designed by centralized people. (Every single peer connection has to be brokered by a server.)

Ipfs is a cesspit of bloat/complexity. (Will never run on user devices)

Regular torrents, well cool but only makes sense for bigfiles and non-browser clients.

If we can somehow gather all "security experts", ship them off to an island and leave them to enjoy the great debate.

Then we might just have enough time to patch browsers with lowlevel DHT api's and let people figure out the rest 🙂

StephanGuy 2y ago

consensus will form like all nostr after one app successfully adopts then another

looking into magnets they dont seem right for smaller files as they are a hash to find more info on the files to distribute p2p, may as well make a note for that

idea is we address via hash so we avoid centralization and loss of media, which is already happening, same reason we hash address notes, this is nostr philosophy ffs

if we stick to using hash addressing then we can use relays or any server to lookup them and if we want later a dht

Reply to this note

Please Login to reply.

Discussion

tforbanan 2y ago

Here's a somewhat accessible DHT implementation if you wish to experiment

https://github.com/holepunchto/hyperdht

(Note to self: ooh so that's the layer they stashed the noise handshake)

Dht's traditionally don't use cryptography, but that one seems to support discovery by public key