It seems likely that nostr will split into two networks. The simple vanilla nostr protocol that we use today and have used for the last 4 years. And a new very complex network with a new untested protocol called negentropy. Both will live together. And hopefully interoperate. There will be a lot of politics here especially from the big centralized players, and also from the small grass roots running simple nostr relays. It's all good really. The only important thing is whether jack & co. will keep the lights on. Hopefully there will be a runway to try both systems for a while to come.
More info?
Follow celebs, they'll pitch it.
shots fired nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegpp4mhxue69uhkummn9ekx7mqcu9929
protocols evolve... you don't need to use HTTP/3 + QUIC which is wayyy more complicated than HTTP 1.0. I still use http 1.0 in some C projects, doesn't mean we can't strive to build faster and more efficient versions of something.
many clients, relays, and libraries have already implemented it. must not be that difficult to do? I haven't tried yet.
Entirely up to you. Most important thing is whether it will get funded, and for how long. The longer the nostr runway, the better. Given that damus is the elite client and the elite relay, it might make sense to wait a bit and let others do it first. You are smart enough to think for yourself and figure out the trade-offs, tho I suspect you will face some pressure.
I didnt say it was *impossible* to implement. I said it was overly complex. Nostr to-date has thrived on simplicity. That was the case before you were there, devs would come and try it out. The reason they would stick around was because of the simplicity. There is still going to be tons of relays running on the original nostr protocol, in any case. scsibug relay runs quite a lot still.
Libp2p helps a ton. We’ll be releasing a dev kit soon like NDK that makes it easier for developers to utilize it for nostr.
does it actually work?
badly
I've seen libp2p around but I've always been skeptical, I guess I could try it for myself and see.
Once HDK is ready it’ll be a lot easier for you to use it without as much manual setup. It offers noise as well! https://github.com/HORNET-Storage/HDK-Nostr-Go
We aren’t building HDK for iOS yet (maybe one day if we’re lucky). Not sure what the best approach would be for libp2p in Damus. I found this swift version of libp2p, but it doesn’t have QUIC support yet (it’s on their to-do list): https://github.com/swift-libp2p
was gonna try https://github.com/libp2p/rust-libp2p in notedeck as an experiment
nice that definitely has QUIC support! At least they have noise for iOS: https://github.com/swift-libp2p/swift-libp2p-noise
Deinitely a case of #FAFO 😂 Do try it, but you have run it for ages on different use cases to see what bugs it spits out. And what it does to your network.
funny HN comment > Honestly I think Consensys/IPFS/Libp2p is just some corporatized way to derail real P2P and decentralization. Their libraries are total garbage. Lots of complicated code that simply doesn't work. No documentation. I mean look how much IPFS and Libp2p is pumped but IT DOESN'T WORK. IPNS is a joke. All way overengineered crap that does everything but actually nothing. Look at the $$$ and pedigree behind Consensys it's 100% establishment. https://news.ycombinator.com/item?id=34177865
You know this, right? It's all shit coiner funded and over hype. Thought you were aware of this ...
I was aware of this for IPFS, but was curious to see if libp2p was at least somewhat useful
"Somewhat useful" is about right. But then they extrapolate to be a "new internet" etc. Same people. The thing I found with this, and so many solutions like it, is that really strange things happen to your network after a while. It could be a few days, it could be a week, it could be a month. First time I thought it was my router broken. But just strange things happen like DNS stops working, or everything in the house goes slow. There's so many of these little "paper cuts". Im skeptical they will all be fixed one day. After all LANs are set up to stop this. Which is why websockets are great, they get through every fire wall. That's the reason nostr works.
they have 3 different handshakes: tls, quic, noise... multiple transports. sigh.. someone should build a version of this that is a bit more opinionated. TURN/STUN is also still really hard, they have never been that reliable. I tried once with libdatachannel with no luck
You can choose your handshake settings. If using QUIC it doesn’t use noise by default since QUIC has encryption by default, but if you’re using websockets and have noise enabled then it will use noise.
What you’re complaining about is literally its biggest feature… libp2p gives you the option to select almost any transport and handshake from a config. It’s modular and flexible. Once it’s setup, you have a world of options at your fingertips. 🌎
Throwing IPFS and libp2p in the same basket is a mistake I think. I was hesitant too, but it’s quite developed. Libp2p documentation is decent, especially with AI to help. Try this link, it helped us at the start. https://proto.school/introduction-to-libp2p/ We don’t use a lot of the things in libp2p, but having multiplexing & QUIC with no certificate authorities is quite nice. I think it’s wise to pick out the pieces that work and leave the junk behind.
By that I mean IPFS is an over-complicated mess and overly relies on P2P tactics for data storage/serving… user-server model of nostr is key. Although, libp2p standalone without IPFS is quite nice. Just like how Merkle Trees without IPFS is nice. Took the good pieces. 🧩
Yeah, allows many other transports too. It’s integrated into the Nostrbox app I demoed at Nostradia. Will be releasing Nostrbox soon! So close. @Siphiwe
Fun fact: the dude that did http2 was also the guy that tried to fork bitcoin in the 2017 civil war.