techfeudalist 's avatar
techfeudalist
npub1nz3c...yxqu
Blessed by tech; working to bring the benefits to everyone. Freedom, incorruptible money, privacy.
Peter says: “Unlike OP_CAT, CTV doesn’t appear to raise much risk of unintended consequences beyond encouraging out-of-band fee payments in certain cases. This isn’t ideal. But no-one has come up with a widely supported alternative. My personal recommendation: do a consensus cleanup soft-fork, followed by CTV.” Peter admits it creates risk, but then claims omniscience to state that the risk is minimal. Activate OP_GFY instead!! ADD NO RISK TO BITCOIN. You have no right to gamble with the world’s money, and our hope for the future. @Guy Swann … another dev admitting that it adds risk. View quoted note →
I was shocked to learn from the book Broken Money how France, to this day, continues to subjugate and impoverish poor African countries through the CFA franc. And when anyone seeks monetary independence and opposes the franc, they are assassinated. I wonder how many French know that their country steals from poor Africans?
The guy, who spends his time bringing shitcoins to Bitcoin, is advocating for op_cat. No kidding. I guess that’s the quick TL;DR on why it’s a terrible idea. image
The plot thickens… Macron lured Durov to France on the pretext of having dinner? image
Quick summary in case you’re wondering what this debate is all about. Right now, nostr is very centralized. Potentially 90% or more of us are connected to a few massive relays. These relays are an easy target for govts, with the possibility that their operators could be punished. This is obviously not good for free speech. In this video, Will is talking about an “outbox” model. Nostr devs believe that moving to an inbox / outbox model will make nostr decentralized. Right now, your app is “dumb”. It just uses the relays you’ve set. The inbox / outbox model will make your nostr app smarter. For example, your app may know which relays are used by your followers. Your app will then send your post to the relays that they use. Likewise, to download messages from people you follow, your app will check first on your relays (they may have sent it to you) and/or your app can also check on their home relay. This is definitely a theoretical improvement. Some remaining issues though: 1. How will apps know the best relays for the people you follow and for each of your followers? If apps need to ask the central relays, then nostr might stay centralized. 2. The apps will need to actively discourage the large relays and this will worsen the UX by making everything slower. Users may not like it and may just use apps that only use the large central relays. 3. Right now, the apps just check a few relays. This makes it easy on apps. With the new system, apps won’t know where messages are so they will need to check a lot more. This increases the load on both relays and apps. We don’t yet know how well this will work. View quoted note →
Many people are saying “put it in the client”. Of course, this would be ideal. A few challenges: 1) Right now, each client can only connect to a limited number of relays. For example, Damus recommends ~10. This forces nostr clients to connect to a small number of large (high bandwidth) relays to reach all other users. Basically, if you can only connect to 10, then you want to connect to the same 10 as everyone else so that you can reach everyone. 2) If relays were installed in phones, they would quickly go online and offline. Each client would then be forced to connect to a massive number of low bandwidth relays. This is the opposite of what happens today. 3) Mobile devices have limited bandwidth and aren’t designed to be low latency servers. Desktops can handle more load, they generally have higher bandwidth limits, and can be left running for longer. People need to be motivated to run desktops to support the network. To move the relays into the clients (which should be done to make the network decentralized) the core underlying protocol would need to be completely redesigned. I’ve been brainstorming and experimenting with such a thing but it’s not ready for presentation. I think I’ve loosely “solved” the broadcasting piece (hint: bees and flowers). But I still have two massive missing pieces. First - replies (replying to someone else’s message so that 3rd parties can see it) Second - data efficient discovery (eg. how to allow hashtags in a way that doesn’t drown your device in spam). Both of the missing pieces are essentially data discoverability problems so perhaps they will eventually have a common solution 🤞 The challenge is minimizing latency, bandwidth, and data replication. Also, no matter what, moving the relays into the clients will likely degrade the UX. Centralized systems are faster, more responsive, and therefore generally have better UX. View quoted note →