Oddbean

What is the moment when we leave the early days? Big user inflow won't happen with the state of things but the status quo won't change if there is no organic demand for quality. I can't celebrate progress for progress sake. So many basic functions are still not working, those I mentioned are the most notorious, while more and more weird functions are being implemented on top. Sometimes it looks to me like some people try to reinvent the wheel. I wouldn't compare the speed or effectiveness of nostr development to neither bitcoin or email, it's happening a different era with never before seen possibilities of collaboration, funding, computation, network infrastructure, talent acquisition, distribution and urgency. I do see the enormous potential and readiness to get going but also no common goal, maximum fragmentation, and no obligation to deliver quality or finish anything. That's the curse of FOSS of course, there's no quality controla and no financial incentive, only ideological drive which pays no one's rent, and when I point out the flaws all I hear is 'well do it yourself' and 'it's free you shouldn't complain'. The free relay model needs to end sooner than later, there is no free lunch, to pretend there is just prolongs the catastrophe. I pay for an Instagram grade nostr client, immediately and double digits. But I pay for the product not the promise. For now, when I on board people, its exactly this: it's early man, don't take it to heart, it's all a bit weird, weirdstr we say, but one day, with or without you, it will be better! Will, I wish one day you make the money you deserve for all the work you put in. Make it good, make us pay

There is a far bigger problem than what you have highlighted: People are building so many crazy-idea apps on top of a fundamental nostr layer which still has problems and still needs breaking changes. And now that they have, if we break those fundamentals everybody's houses of cards fall down. And so IMHO all the rapid adoption is the thing that will probably kill nostr. Far too much built on top of a still flimsy foundation that is now unable to be fixed. I wrestle with this dilemma in my dreams at night, tossing and turning, considering all the ways to make subkeys happen and how every single one breaks something deeply, etc. The issues in your OP are smallish bug/features that can very easily be solved by comparison. Amethyst can become less complicated (by automating things or something I dunno), and can add ability to tag somebody, and primal can add ability to block somebody. These are stupid simple problems that just haven't happened yet. I think your expectations of how things should already be are very high.

First, I shouldn't have said "need" that is too strong of a word. Nostr can keep going without breaking changes. And in part I'm speaking in the abstract based on experience, based on the number of breaking changes that have happened so far and their approximate rate. But I think some of the big things below app level are subkeys (for an offline masterkey) through something like a slightly modified NIP-26, binary events over websocket binary, something like negative filters or negentropy (specifics to be worked out), some kind of better relay usage for the many basic usages that actually exist (Vitor is working on that), ... that is off the top of my head.

Yeah, I had a similar list in mind. Subkeys and key management/rollover in general being the elephant in the room, because you kind of need to break some things there, as everything is currently operating under the assumption that keys are not just identifiers, but identities. I guess there's just a lot of defiance, because it's a big "I told you so" to stomach.

Break it all now Developers, users, we're all early adopters Things breaking comes with the territory And those were our choices Rn the network is entirely ppl with faith and passion for the protocol Ppl who can bear the pain of things breaking for a better future Choices 1) break things now 2) break things later when nostr has millions of daily users and functional business models 3) set a broken protocol in stone forever and ever

Is there a list of the protocol-level bugs out there? Do you have a list or do you have the time to write one down? Getting it out of your system also might help with the nightmares 😊 Yes I talked specifically about the on boarding and user experience, looking top down, outside in. I wish for the client devs to focus on the core business, to get the basics perfectly right before moving on to the funky stuff. 👉 Dear devs, learn and copy from those who have invested billions and decades of research in designing their addictive apps. Stand on Facebooks shoulders and grow even taller, there's nothing wrong about it. The Instagram UI is perfect, every teenage girl can use it and they do. Looking at Primal for example: It features a big lighting symbol front and center, that's not a social media app, it is a Bitcoin wallet with social functions.

“break those fundamentals” can you elaborate on this please? My few sats: Nostr isn’t bitcoin and still a toy. I guess that more experiments should be made to achieve the desired goals of decentralizing and make it censorship resistant! If it’s fails then it better to be now than we onboard millions on here and say “ooops it doesn’t work”

Nostr is a toy, yes. A great toy, and developers love it. Unlike bluesky, or mastodon, it is not set up for mass adoption, but is very good for R&D. Opensats could change the equation, but they have an R&D strategy is working, rather than a growth strategy employed by bluesky. And it may be a bit late, anyway, since some devs have left. But this all might actually be good. If you zoom out, you see that nostr is build on http. Rather than nostr having to take over everything, you could instead, take the best parts, and deploy them to a wider audience on http in general. In fact, this is by far the most likely path. Nostr has bitcoin native payments, we just need to make bitcoin the native payment system of HTTP. This is why projects such as npub.pro are so amazing. Similarly with single-sign on, nostr identity can be used in many existing systems. Nostr is a toy for R&D but can spread to the whole web, which has a chance of working.

I think it is helpful to think of how centralized and decentralized processes life-cycles work. A centralized process has a goal/demand defined by centralized planning (stakeholders). This goal helps the builders coordinate effort towards a limited array of use cases. Then, solutions for those use cases are engineered into existence. And repeat. It is very straight forward, and agile (haha), but that demand might be overestimated, as central planner might be wrong, incompetent or dishonest. Decentralized processes have a more "organic" development life-cycle. Builders build with their own use case in mind. Once a use case becomes popular (ie., there is demand), community adoption will help steer development of these solutions. This is slower, and there is no clear finish line, as demand evolves with time. Some solutions might be abandoned along the way. Surviving solutions will be the ones that actually provide the most value, as there is continuous demand. there is a natural chaos in the way decentralized processes work, and time frames differ from centralized ones. The fact that this https://github.com/nostr-protocol/nips is the current reference for how nostr is supposed to work is a coincidence. There is no guarantee that this will still be true in 5 years. People can only build ideas they see value in. Only time will tell who is right or wrong what works and what doesn't. I would advise people to be wary of making or blieveling in "this is how things should be" arguments when it comes to the development of decentralized projects, as such arguments are filled with bias and projection. in an organic decentralized process, you can only look back and say what has worked best so far. there is no telling how things should be. any predictions are only that, and have no bearing on reality.

Then let's get fresh value statements into the mix, new users who will tell us what they like and would spend money on. Because money somebody's money is always spent, right now by 'free relay' operators and devs who ask donations. Foundations are good, grants help over the early days but people vote with their feet, thumbs and their wallet. No better communication tool but money itself. For that we need solid basics, not zap forwarding and.

By all means, give it a try. Just adjust your expectations as you progress. It might be that it takes longer that you might have imagined or predicted. It might be that the solution you are interested in is not in high demand, and that people will flock behind a different idea.. even if that idea comes to fail at some point in the future. and on that note: https://x.com/geyserfund/status/1811434402041282680

This is terrible logic. Any crappy project can use this logic to just suck people dry for years on end. It doesn't mean Nostr can't improve, but the fact that some projects take time should not all convince anyone that something moving slowly can actually get into orbit just because a rocket starts also moves slowly at one point in the launch.

Well, Nostr sucks so bad I left twitter permanently and use Nostr exclusively…………. These handicaps you are pointing out are immaterial, will dissipate with time as future iterations are released…….. My background is a simple pleb with rudimentary knowledge of computer science……….

when I tell people that:"... they'll have to secure their nsec and publish their npub..." and their eyes glaze over and they're gone. #smij #zapd nostr:nevent1qqs0qe9fyknasus6zfxdyf04nndahu3ap07d9yncl00y9s6qxej8kcqppemhxue69uhkummn9ekx7mp0qgs2rlzal4lleatrezg4tdrxw5d4srg3tcfkutuvjr5fzvu9h0kmrncrqsqqqqqp23lmyy