If there is an open decentralised system, and it can be unilaterally crawled and indexed, and said crawling and indexing can drive a reasonable profit, then it will be crawled and indexed. This is just like a law of nature.
Discussion
This is irrelevant.
Why? If there's always a convenient and full (or pretty full) index at the ready then you agree that affects motivation to do all the hard work for outbox and such? Or no?
Maybe, although I'm not sure that should be a thing currently since no one is making any money on Nostr, everybody working on Nostr clients is supposedly doing it for idealistic reasons and/or being paid by grants.
But I'm not talking about outbox now, outbox only comes up after you've decided to see or follow some specific person's notes, before that you need to discover that that person exists, and to me the only reasonable way to have that is by relying on relay feeds -- and these could be created by centralized indexers, like https://algo.utxo.one/, but if they are exposed through the relay API that makes them very easy to be reused and exchanged by other clients.
This is the part where nostr:npub13ndpm2hm9hud4azsq5euhf5mv3d05r90wymwxsd7rdn29609hhvqp60svh knocks on your door in a suit and tie and tries once more to sell you PKDNS from a shiny black briefcase.
But yeah, I'm with you mostly on the relays and also the good work Jumble has done to help visualise what's possible there.
I still think though that the whole thing is mainly a use case issue. Change the use case to B2B and many nostr problems just go away, you no longer need the things nostr doesn't have (like how after linux moved away from consumer desktop OS and towards servers it no longer needed a sexy GUI which it couldn't figure out how to make anyway), and with lots of money to be made as SIs, and no grants needed. There's no other use case where the potential income goes up by 10 and the crazy-difficult problems go down by 10.
I don't see how PKDNS solves that. I'm talking about learning that someone exists and if I should be following them or not. That's about content, not about how to find their relays.
Finding their relays is easy, we don't need Pkarr for that. Yeah, it's not 100% guaranteed but what we have here is practical enough for the current world.
By the way: Pubky solves content discovery in a way that is very similar to what Bluesky does though, and both are also similar to Farcaster. They all see Nostr and think something like: "oh, there are these centralizing tendencies that may affect Nostr and that would be very bad for Nostr if it happened, so we will just hardcode those in our protocol description and pretend that somehow it is not broken from the start?" (it ends with a quotation mark and they are super confused and the rest of their lives makes no sense anymore).
It would already be bad if they only used a "global" server for content discovery, but no, they also use that for the normal feed building anyway, instead of the outbox model.
Some independent dude over there just made a proper relay that (if I understand his thread right) the entire BlueSky AppView could theoretically run off of—and the relay cost per month would only be like $20. (An AppView of the size of bsky.app is always gonna be hecka expensive, so cost of running the AppView another thing altogether, but on the relay side that's pretty interesting.)
That's interesting, but it's deleting data after 48 hours and having trouble connecting to 40 PDS servers?
How does it decide what users it will fetch posts from?
Where's that from? Maybe that means mushroom servers? Each bluesky mushroom PDS box has something like 500,000 individual users (PDSs) in there, I forget the number but it's a lot.
I read it in the thread, maybe I misunderstood it but doesn't matter.
The other question is more important, and it's not even a rhetorical question. When you register on the Bluesky app do they make a special allowance on their relay for your account? Or do they label your account with something that tells the relay to fetch your posts? Why can't nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhggpt7fy's Bluesky bridge automatically put all of Nostr's content inside Bluesky?
Relays choose which PDSs to index. I think there's some way for independent PDSs to send an HTTP request to a specific relay and be like "yo pls index me" but I don't know if it's roadmap or live. Anyway the relay could always ignore that.
For pushing nostr content into Bluesky, something tells me the Bluesky team trusts Bridgy Fed more than Alex Gleason Inc.
I guess if Alex made his own AppView and spun up one of these budget relays he could use that AppView to hydrate whatever content and relationships from whatever PDSs he wanted (bsky.app hosted or nostr bridged/programatically controlled) and keep track of timelines and all. But then you'd need his client to see the combined universe. And PDSs would be outside hosted.
On the topic of Bridgy Fed though, here's the Bridgy Fed guy's talk from the ATProto conference a few weeks back. I think he likes nostr, cause at the end of the talk he talks up nostr as some sort of destination where things are converging or something. Watch to the end. Maybe he's a sleeper agent for you.
ahahah, thank you for linking to these talks. The talk is very good, the comparisons are cool to see.
Interestingly, since the beginning he is painting Nostr with a good light. I didn't know he liked us so much, and didn't expect him to be so open about it in a Bluesky conference.
Nice to see this honesty, and great overview.
What is Ryan’s nostr native npub?
Found via AP bridge
nostr:npub192zgfvxl3xukuwld7fcd3l88un9rxxynsxd4fay4pj3x9cgxrh2qvxegjh
fwiw We didn't "see nostr and think" anything really. As you know, we have been researching this stuff since before nostr existed. Bluesky too.
What we saw were problems and what we have is a comprehensive vision for an ecosystem we are solving for. We didn't use Nostr because it does not meet requirements and attempts to interface with Nostr people were always retarded.
Yes, there is a big distinction between "discovery" of endpoints for an identity vs "discovery" of identities and content you like. Obv, these are very different topics.
Feel free to continue glossing over the first one, but you have to admit Pubky(pkarr/pkdns) is a strict improvement over nostr in that regard.
For the second form of discovery (of content), Nostr won't have any special advantage over any other platform as there is no novel method in Nostr. In fact, Nostr is likely to have more trouble due to uncertainty around relays and data (and the other form of discovery).
In Pubky, we do in fact have an intentional design for identity and content discovery, and it is mostly novel.
We use a Semantic Social Graph, which creates subjective relationships between keys and URLs. This graph can then be applied as filters or by distance and weight, like a WoT.
In the end, you can't have perfect p2p web, so you must design for scaled and trusted use cases. We can offer the people competition and interoperation within an open ecosystem, but everyone needs services indexing, cloud hosting, moderation, etc.
Yeah at first I was thinking discovery of endpoints for identity, for which it's pretty hard to disagree that PKDNS is a step up over free-floating metadata events. For nostr at this point I wonder how painful processing a list of carefully selected breaking changes (encryption type included) would be? Even just changing encryption and maybe transport, and leaving most everything else the same. My gut says nostr would bounce back pretty quick, given that so much of nostr a this point is nostr enthusiasts. Of course if it didn't bounce back that'd be a big "D'oh!" moment.
The other discovery seems like a problem that if you *genuinely* have it that's a good sign!
Have a look at nostr next https://github.com/mikedilger/nostr-next -- tons of good stuff in there
Discovery is sovled in nostr with did-nostr, which is far better than spray and pray. It's simply a case of which clients want discovery and which want to struggle on without.
If you want censorship-resistance then #pubky is your choice. And it slots nicely into with did-nostr and discovery. Gen-1 clients will continue trending sideways, bluesky will continue growing, and clients that upgrade will gain market share.
The web is working as expected.
Great list. I like all these. Before I was on the fence about breaking changes, now I think just go for it.
How, though, I dunno. Council of the elders in a desert tent?