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

Replies (6)

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.
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
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 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.
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.
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.