Oddbean

Walk me through this, we start by saying: let's switch to ed25519 keys to leverage Mainline, then let's not sign everything with the root identity, instead let's use central http servers acting as data stores that adds strong consistency and an ordered key value store api... and you think anyone would have listened to us let alone implement any of this? ok here we are let's do it.

But that's the most extreme version of the argument. Why not make pkarr domains optional like this: https://github.com/nostr-protocol/nips/issues/1548 About home servers, I would say strong consistency doesn't scale. Even centralized web companies know this, and have embraced eventual consistency.

facebook and twitter have been running their global content delivery system on eventual consistency for over a decade, it's not at all in question best effort this is one of the worst delusions of blockchain projcets

Is this our job though spending our time begging on Nips repo? we built Pkarr, we showed it to everyone for many months, and we're told it was unnecessary. Pkarr is still there and keeps getting better. Anyone is welcome to use it. And for strong consistency, I meant it in the Write sense, meaning, in Nostr you can't do lists or counters safely, on Homeservers it is easy. Another way to say it is: single writer. Think how LMDB offers great transactional safety because it just rejects lock-free multiwriter paradigm. And if you believe that most users read way more often than write that is a reasonable tradeoff (maybe slower writes or occasionally unavailable writes) for the sake of having stuff like consistent pagination and exclusion checks and maybe versioning. Saying that that doesn't scale is like saying having only one Git remote doesn't scale, of course it does.

> Is this our job though spending our time begging on Nips repo? No, I'm just saying that worse is better™️ and one of the most reliable paths to success is to use something that has traction. c.f. javascript. It's fine if you're trying to build something more pure/perfect, you just might end up like urbit. But that's your business, not mine. > And for strong consistency, I meant it in the Write sense That makes sense, inconsistent writes is indeed another pain point of nostr development. This makes me curious though, do you have a plan for read replicas? E.g. if Musk joined pubky, would his homeserver get overloaded with people trying to read his pubkweets, or would his content get replicated to hubs? This whole thing is a delicate balance between performance and decentralization, but nostr does have a story for it.

Worse is better if it is worse to the devs but better for the users. I claim that all our decisions are meant to achieve sovereignty over IDs without any more complexity that isn't inherent in the very web. I say that is pragmatic not pure or perfect, I am not trying to reinvent functional operating systems, hell I specifically try to work on things that can be "done". The most leverage for the least novelty. If you mean Nostr network effect, then 1. arguably it barely exists 2. we explained why a hard fork was practically unavoidable. As for your question, I honestly don't have much more ideas than what is in Bluesky which itself is iffy; the idea is, if homeservers sign their own data, then others can act as their CDNs without a relationship, so a big thing like Internet Archive can bail you out if your Umbrel homeserver is dying. Theoretically that should work, just like Bittorrent or Git...but also let's be honest Internet Archive works regardless, even if not signed. But when the low hanging fruits are done, we will work on signed append only searchable merkle trees per user. At least I did a proof of concept a while ago. In reality, nobody gives a shit and bots just trust Bluesky firehose feed without the expensive merkle proofs. But we will do what we can if the complexity budget allows.

For now, we do what the web does, we have "Indexers" that crawls homeservers and serve trusting clients. I think that is a good pragmatic first step. On one hand it is cheap and simple, on the other hand there is no gatekeeping or walled garden, anyone can spin a crawler/indexer. All what signed data ever does, is enable altruistic sharing of the burden of crawling... but that assumes there will be that altruistic sharing in the first place... if it ever happened, fine we will help it.

I think you're under-estimating what a game changer signed messages actually is. But I appreciate the back and forth, it's forced me to do some more research. pkarr seems great, and I do wish you guys the best, we're all on the same team. I just wish there could be more collaboration when we're all so aligned, it's the same problem you get on nostr — all the devs just go and do their own thing rather than working through differences. NIH is real.

If we talked you would hopefully realise I have a good grasp on what self authenticated data is good for. But I also know when it is not serving any real purpose, what I am saying is I have an intuition to the space where they fit. Consider that we may have started from the njump end of the spectrum; serving resources over HTTP. we can and should still fill the underlying space with Git like system. But hopefully you could appreciate that; 1. we are not shocking developers either tons of complexity that they don't need to build apps but also don't know they don't need, so just overwhelmed. 2. we don't commit to things we are not sure how it will work yet. 3. this is the time to get involved with us, discuss our plans for the data model that will be used for trustless data propagation, understand our motivation of that design and share your experience as a client dev or as relay operator. I would love to discuss these plans with anyone who listens, to get insights back.

I do appreciate all of that. And I'd like to see cross-pollination between the two projects. I'll be sure to read the docs when I have a chance. On the topic of digital signatures, you may be right that they aren't strictly needed, but I like them because they're so simple and give you so many guarantees that they really open up the design space and protect you from your own mistakes. Having them is a left side of the bell curve approach which makes the rest so much easier. They're a bit expensive in terms of computation, but I don't think they add very much complexity if you can just import a library and call a function. > I would love to discuss these plans with anyone who listens, to get insights back. Would you or John like to come on the nostr:nprofile1qyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahzummtxqhx7un89uqzphl3mpurnffw88l6vmukxylervy8xn22envuanr3678u9648r9363yvpq7 ? I've been trying to get other protocol devs on, but they all want to build in private and the timing is never right. I'm always interested in comparing notes.

Not sure what is this, but I will assume it is a relay that you make sure to only read from before you write. But I submit to you the question: why are we reinventing HTTP and Rest just because Fiatjaf felt like it? Just because we want to have signed data, doesn't mean clients have to talk to their home servers (or in this case community relays) using an API and transport meant for sync and gossip. Saying nothing about JSON or secp. People say Pubky hard forked Nostr, but Nostr is what hard forked the web for no reason.

secp256k1 just because everyone else seems to hate it because fuck you that's why also, propose an adequate key succession/rollover scheme that enables stable identity and we are talking, otherwise, stop wasting your time

I see, it has to be acknowledged when it's offensive to the target. Right. No, you just seem myopic about the history of protocols and how worse is better and traction beats "better ideas" and you insist on getting into casting shade on what is powering your ability to even have the conversation. There's just no point in trying to be polite with people who are so obviously incentivised to speak this way on this forum where nobody actually cares about you trying to take the weakest approach. You surely realise that nostr is too established to have a migration to your "better" protocol which no doubt makes tradeoffs that are going to hobble it like everything else everp

I was not trying to make the super established Nostr change, in fact I was answering a question of why not work within Nostr... and when I said it wouldn't have worked you said fuck you then told me that it wouldn't have worked 😅 We are both in agreement

I've been watching nostr people in denial about how it's growth will come from commercial adoption while the essential feature of instant messaging is ignored and the stupid rhetoric about free as in beer and as soon as replyguy turns up people finally realise that nostr is fit for small, semi private but interconnected communities. If you emphasise interoperability you will succeed. It is already a lot of friction onboarding and unless you guys actually solve that problem I'm staying skeptical and building my realy

Being sharp tounged is perfectly fine with me, just have something intelligent to say after you capture my attention with what you think is harsh... nostr:note1fa6fe9wst3rl88nkfn8yuj0jdtt7qduvpu3sh7e8279a8kd3wjuqjnuaal