Oddbean

Nostr vs. Bitcoin Github star history https://m.primal.net/LNIj.png Is this a fair comparison? What causes the next vertical phase? BTC bull market? Current apps get better? New apps/use cases emerge? cc @miljan @PABLOF7z @dk @brugeman @merryoscar @melvincarvalho @jb55 @bumi @Ben Arc @Martti Malmi @Vitor Pamplona @Stuart Bowman @gsovereignty

Bitcoin pump will help Real Nostr daily active user pump will be from better UI/UX from Nostr clients. This is driven by grass roots, boots-on-the-ground efforts to get normal everyday people in your community to actually use Nostr Then we 🚀

Apples and oranges. I'd compare nostr to IPFS, Farcaster, bluesky or mastodon —IPFS being a good benchmark. Nostr and Bitcoin have taproot in common, but are otherwise quite different. Main issues: dev exodus, and devX is lagging behind peers. IPFS, for instance, has a dedicated community manager. The relay network is neglected; I hope new companies step in or Ditto takes off. Damus is still a great public asset, while it lasts. User numbers are falling, retention is low (per nostr.band). Vertical growth seems unlikely without a major shift. Despite significant funding, nostr's sideways movement, says something’s wrong. Nobody wants to acknowledge that, though, let alone fix it. So I see that continuing. Even if there’s a surge, nostr lacks the capacity to match competitors, who are steadily growing. I'd love to see Jack, Tidal, Ditto, or others make a client, or better infrastructure, or a popular new app (maybe AI-driven). For now, nostr relies on goodwill—hopefully that keeps it afloat as a space of freedom for a while yet.

I’m definitely excited to see @TIDAL and @CashApp up the ante for sure. And I’m impressed by what the next version of @primal is looking like. I’m also really excited by the music/podcast discovery on @fountain_app with their new nostr integration. And I assume next tweetdeck style drop from @jb55 will be 🔥 I haven’t played with @Ditto yet. What excites you about it? And what sort of AI app do you think would be most interesting on nostr?

#ditto is next gen because it's not relay only. So it has a chance of scaling. It has an architecture, Alex has provably scaled things in the past, too. So we know it can be done. My preferred stack is what I am calling #SAND -- Solid, ActivityPub, Nostr, Ditto. I think the future is agentic, ie agents are the new apps. And they can communicate over nostr, too.

Cool! I'll play with it. I'm with you on agents communicating over nostr. openagents.com and fewsats.com are the best examples of this vision I've seen so far. cc @Christopher David I guess DVMs as well, though I've yet to find a user friendly way to interact with these - what's the best DVM client right now? cc @Dustin @PABLOF7z

Im an open agents subscriber. Didnt know about fewsats, looks cool, but requires email to login AFAICT. I also am looking for something more user friendly than DVMs. I have may own agent framework in any case called #sandymount and I've tried to add DVMs many times, but yet to get that over the line. I think it will be easier to do next year. I think with nostr is that you simply need a business to add nostr. Hopefully with a professional relay. No one seems to have done that yet. Which is odd, after all this time.

DVMs are more infrastructure imo, I don’t see them as something users will interact with directly (at least for most DVMs). The most used DVM right now is feed sorting algorithms, and clients make this user friendly and call the DVMs in the background (the user may not even know it’s DVMs that are doing the work). We haven’t really had multi DVM use cases yet (although folks are working on them). I think of DVMs as modules that could comprise agents, and the space is still so early. For example, we need libraries where you can call a DVM just like you would call an API (a python library for this is on my to do list). Many people building agents are using lots of APIs right? DVMs would replace these API calls and offer some neat tradeoffs.

Yes that would be a plus. I think we might need a lighter version that is easier to get started with and do useful things. Also I see it going in the direction of cashu integration, is my guess. And cashu want to charge on every tx. That's going to make workflows complex. I see DVMs getting more complex, not less, and they are already very complex. Perhaps it's a good time to examine the most useful parts of it, and make a simple version. After all, nostr took off when the protocol was a simple 2 page spec. Even nostr core is a beast of complexity now which changes too frequently. Getting back to simplicity I think is the path to success.

So the idea is, money in, data out. I think that's a great starting point. And you can have money=0 So in the base case it's just an API, right? Then there is the discovery. That seems to be a separate part. How to find a machine. Then there is the payment. ie on-chain, mint, lightning, cashu Then there is the need to make it fast, ie sub 400ms. I think make it into small logical micro sections that can be simply implmented and less monolitic.

Based on feedback from @melvincarvalho, perhaps this chart is more interesting: https://m.primal.net/LNLv.png (note I ran out of free lines so activitypub/mastodon is missing, but it surprisingly only had 1.2k stars)

I think the solution to the next leg up, is a simple one. And that is: "let nostr be nostr". Nostr is a relay system that transmits notes, and other stuff, from one user to another. It should be used for that. Nostr is a terrible database, and should never be used that way. Of course, developers love to break the rules, but it comes at the cost of bugs, lack of scalability and technical debt. Which nostr is now swimming in, and no one wants to admit it. Eventually they will have to. If you let nostr be nostr, then you can let a database be a database. You can let the cloud be the cloud, and so on. Everything just works when you use the right tool for the right job. Just like the LAMP (Linux-Apache-Mysql-PHP) stack allowed different techs to specialize in what they are good at, and avoid what they are bad at. But all working together are greater than the sum of the parts. That's how facebook was built, by an unexceptional programmer, in 2 weeks, and we're nowhere near to a facebook on nostr after 4 years, even with talented front end coders. If you have a mentality of "nostr or nothing", you will most likely end up with nothing. The solution is simple, just let nostr be nostr, and everything esle falls out.

Ma note suite à une période d' observation et d'analyse personnelle des diverses interactions depuis octobre 2022 sur github sans clé à l'époque , anonyme que je n'ai pas osé publier afin d'éviter des intimités de financeurs d'opensats ou de certains Bitcoiners objectivement récapitule ce que vous avez en tant professionnel reconnu du secteur... Cependant jamais je n'ai vu autant de mordus d'informatique bosser ensemble et de manière discontinues sur un site.. Pourtant il ne semble pas qu'il y eut un bon de commandes même nous les ux me semble anecdotique sur cet environnement.. Pourtant dans cette sphère pratiquement presque tous les professions y sont si l'on l'on se référe à certains bios puis on les retrouve évoquer des thématiques qui ne permettent pas de collaborer ou d'imaginer des apps utiles à certains oublis au regard du nombre de notes exponentielles similaire à des journaux personnels lesquels sont rarement publics mais conservent des etats, des des émois voire des problèmatiques psychosociales, la liberté individuelle, les droits..peu développent en ce sens évoque sur nostr, c'est peu, mais l'en-soi en émoi ou maux est bien sont latents sans les notes peu outillés puisque encore une fois rares sont ceux qui se sont posés leurs raisons sur nostr nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qg3waehxw309ajhjetn9enrw73wd9hsqwhj0h avait lancé une telle question mais les réponses ne furent.. objectivement et personnellement.

Both nostr-tools and strfry have less stars than the NIPs, that's the inversion to watch for, because they are what provide actual utility Specs are meaningless without implementations, particularly nostr specs where they're generalized json and websocket schemas that are indistinguishable from every other app on the Internet

Yea and I actually recall someone making the point it should have been binary Ultimately it's the implementations that make the rules, the idea of bouncing signed data off webservers is as old as the web itself... Nostr just made it simple for midwits to understand so they could feel like contributors... that came at the cost of a larp army obsessed with retarded specs, not implementing shit that actually works Nostr can only succeed if there's a broadly useful SDK, which imo has to have commercial motives