GM, folks! Just putting this out there. I was thinking, while we have a few NIPs and torrent-based tools on Nostr, there are some quick wins to be had by tapping into the torrent ecosystem.
With so many people building HTTP views, bridge APIs to Nostr WebSockets, storage APIs (e.g., Blossom), and streaming tools... FFS nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tc4rdlnm is even exposing a FUSE interface that can be mounted with nak (just for laughs) to give you Nostr as a filesystem abstraction. So why aren't we leveraging WebTorrent and IPFS to make our lives easier?
I’m not saying we should abandon what we have. Just that we could use what’s already out there pragmatically.
For example, I keep hearing about Negentropy, which is great and all, but… Why can't your client or relay just join the swarm and sync all the notes and Blossom blobs associated with my pubkey? Maybe we could even expose all of this over IPFS and boom, you’ve got "Negentropy" and a cool alternative to njump.me. It doesn’t get much more bandwidth-efficient and P2P than that.
@jonny@neuromatch.social 🔗 https://neuromatch.social/users/jonny/statuses/114245524577616333
-
> we whipped up a bittorrent swarm that has 200TB of proven storage in like a month by cobbling together everyone's random hard drives. storing 200TB on s3 would cost at least $4.5k per month and would cost $10,000 to download it one time.
#gm #nostr #torrent #blossom #ipfs #growNostr #devstr
Torrent was designed over fixed large data. I'm not sure what would happen if the dataset you are syncing is constantly changing.
I think using mainline DHT to bootstrap a pubkey's relay list is a cool idea. But we instead just spread these relay lists out on the current popular relays, which works well once you've been using nostr for a while and your client can easily figure out which relays are popular. DHT would be better for people starting cold though.
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.
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.
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.
On a more fundamental level, I think the "one true way of doing things" ship sailed a long, long time ago. Deprecating a NIP won’t help much either (e.g., NIP-04 vs. NIP-17 even with harassment bots and some popular relays like Haven dropping kind 4 by default, most clients aren’t there yet).
In a way, while this is the opposite of what I’d push for as an architect, I’m happy for Nostr to be the hacky, pragmatic "PHP of Protocols." Every programming language feature ever invented eventually finds its way to PHP, and we all know how hacky and clumsy parts of PHP’s standard library are. PHP, like C++, gives you at least 10 ways of doing anything. But unlike C++, a first year CS undergraduate can easily hack something functional with it.
And that’s totally fine, considering what Nostr aims to be. PHP won the web race, while my favourite, "well-designed" programming languages are all competing in niche spaces. This doesn’t mean your call to clean up Nostr is wrong, it’s just that… good luck herding cats into agreeing on and implementing one true way of doing things.
However, just to indulge in one true way thinking: if you put a gun to my head and told me to choose, while I’d personally pick DHT, in terms of driving Outbox model adoption across all major clients before 2030, I’d go with the "well-known URI on steroids" approach. Maybe with additional NIP-05 provisions to standarise identities behind onion services. Perhaps also with a dead-simple, optional PUT endpoint to update relay information trivially from clients. To me, kind-10002 should be part of nostr.json, i.e., it’s connection bootstrapping information and, as so, should be trivially obtainable before I even connect to any Nostr relays.
