Oddbean new post about login | logout What I don't understand is why you chose to essentially hard-fork nostr. Why not build all this cool stuff on nostr? It would all work as far as I can tell.
Even if he only changed one thing (the PKI), it would be a hardfork of nostr. There are some base level items that cannot be improved without a hardfork. So if you need to hardfork for that, might as well change some other things (like the assumption that everyone will have their own personal relay I suppose).
Okay but this is not what "hard fork" means. This is not a blockchain and we didnt use any Nostr code. We were never Nostr and there were no forks or defections.
Like, there could be good reasons like there were with scuttlebutt, I just don't know what they are
It is strange that this team is attacking its customers, presumably nostr developers, for not understanding their company’s product. Maybe this is not what is happening. This is what it looks like from the outside.
They come across as bitter, defensive, and arrogant. If they want people to try or use their product, they should get someone who knows how to talk to people to make announcements, and answer questions.
Yes, but also I think they're excellent marketers. If I were to read it cynically I'd say they're doing the crypto play — siphoning energy and talent away from a truly open protocol to a branded version of the same thing.
I think that's circumstantial, not intentional. And their abrasiveness is going to encourage people to take an ideological stand against them. It feels very counterproductive to me.
Yes, I agree, I think Carvalho is well-intentioned.
I've seen devs get defensive and hostile before when their work is criticized. I think it's a natural impulse when you feel like something you've put your time and energy into is being attacked. But you've got to find a way to keep your game face on so you done end up alienating the people you want to accept your work.
btcerrorlog is fractious and thin-skinned. Only a matter of time before the arguments pick up. I haven't looked at the tech stack. Is it web5? They have some very interesting solutions for scalability and key rotation. Nostr has the network effect. I think the best future is for nostr to adopt some of the web5 tech. In some cases it would be a backwards incompatible change, essentially a hard fork. But you can't bully people into a hard fork. ¯\_(ツ)_/¯
💯
NIH syndrome
Why didnt nostr build on one of the other incompatible designs that existed before it? Why is it ok for you to act NIH about Nostr, but not for people to invent things outside of Nostr? Why are we discussing loyalty and emotion in a tech conversation?
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.
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.
Absolutely, i am personally happy to join and talk about technical stuff or general themes.
Great, sent you a dm. Let me know if there's a better way to get in touch.
> in Nostr you can't do lists or counters safely, on Homeservers it is easy On community relays it's easy too.
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.
I'm open to other API / transport protocols. What's your case against JSON?
Oh sorry, didn't see this yet: nostr:nevent1qvzqqqqqqypzpycvemcjxuka9utq2l8u2ncdhk2rxhvt2x6wyumjx6cqe2m33lxeqqst4qrf03vjaj04f0zws8dd73axn3mx225h0wvcuahuhd2q54a8mps9fr0yw
Loving the criticism btw. You bring up many valid points.
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
you seem like a happy person :)
i aspire to having a reputation like Wolfgang Pauli https://bigthink.com/hard-science/wolfgang-pauli/ or H. L. Mencken people need to hear hard words when hard words are what fits
You are failing miserably, I know smart harsh criticism when I see it, all you are saying is fuck you, that is not a truth that hurts... get gud.
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