Oh, but they read them if they're embedded right? note1/npub1 are nice because they're actual ids, but have no routing information embedded. I think we can't use them long term if we want nostr to work (npubs are probably ok because we can check indexers).
I learned a little more about why people have such a hard time with bitcoin's "intangibility" while talking to my mom last night.
I asked her what it was like when credit cards were invented, and she explained that before electric cards there was something called a "charga-plate":
https://historyofinformation.com/images/Screen_Shot_2020-08-18_at_5.41.58_PM.png
This was a metal rectangle you would present at shops, which would be pressed into paper to create an authenticated artifact of the transaction.
The precursor to charga-plates was just regular paper checks. In either case though, the mental model is the same, and credit cards simply extended the same mental model of having some physical cash in the bank (whether or not that is strictly true), and authorizing someone else to talk to your bank and pull some out.
Bitcoin completely breaks this mental model. The problem isn't that it's intangible, because we've been using intangible money since the 16th century. The thing that breaks people's minds is that it is intangible, and has no custodian.
When you sign a transaction, who are you authorizing, and to request money from whom? It really doesn't make any sense from the legacy money perspective to authenticate ownership of a UTXO with cryptography, broadcast it to an etherial network, *pay* one of several miners to include your transaction in a "block" (?) so that the math money can be split and some handed to your counterparty.
Anyway, I think this difficulty might exist for nostr as well. Credentials authenticate you with the account holder, but keys authenticate your content with the reader. To make this worse, users have to custody their keys, making them the account holder and custodian — and when they log in to an application, they have to ask themselves permission to create self-authenticating messages! Weird.
No, I think it's about the mental model, not about ease of use. We'll get past it, but I think the fact that no one is holding your cash in a vault that makes bitcoin so weird.
I want this
nostr:nevent1qvzqqqqqqypzpckv7l8jqspl8u4y54dn9rcduwlrs4v2040nxce0m2h0cunvrj8tqyfhwumn8ghj7am0wsh82arcduhx7mn99uq32amnwvaz7tmjv4kxz7fww468smewdahx2tcpz4mhxue69uhkvun9deejuat50phjummwv5hsz9nhwden5te0v96hg6pwdehhxarjxyhxxmmd9uqjqamnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9a3ksct5qqstn4fk2fnrv4xp0l4r4vgygraqne6n4uxj63tdv4n5ervhaldcsvqvpfucs
"It's 5 am, just got done grounding myself, time for my sauna and cold plunge"
[Cut to bitcoiner eating a raw steak]
"I used to have ulcerative collitis. I still do, but I used to too"
[Checks the bitcoin price]
"Time to go to my job as an insurance broker. Gotta stay humble and stack sats"
[Cut to bitcoiner scrolling through millions of bitcoin podcasts]
"Lunch time, brought a pocket steak"
[Bitcoiner awkwardly eats a bloody steak from a plastic bag]
[Checks the bitcoin price]
"Time to orange pill some people"
"Do you guys take bitcoin? No? ...ok"
[Bitcoiner standing by the road holding a sign that says "vote for bitcoin"]
"Let's see what the latest is on nostr"
[Comes home to an empty room, grabs his only place setting from the cabinet]
"Steak time"
[Cecks the bitcoin price]
"Check out my library"
[Just 30 copies of The Bitcoin Standard]
"Can't wait for Nashville"
oh, Medium, wonderful
But yes, I'll read it. I've always like what Carvalho says, I just haven't seen him do anything substantial. But maybe now I will.
Oh, didn't realize you're Carvalho himself. Nice to meet you! As I say below, I've followed your work for a long time, well before I got into the space. Now I have to re-write my note to speak in 2nd instead of 3rd person 😅
On your critiques of nostr:
> Scalability/incentive challenges that result in only a few centralized relays, lacks key-delegation and identity-based routing, inviting censorship and data loss.
I agree on key management, but the rest of it is either wrong or has to be justified a lot more. A "challenge" does not "result" in anything. And there is identity-based routing in NIP 65 and other places.
PKARR sounds great, but again, why not bring it to nostr rather than pump your own brand? I'd love to see someone solve that problem on nostr.
I also have a problem with your thesis that DHTs "ensure scalability". P2P DHTs are pretty well understood to not scale. Hub-based DHTs can scale, but that's basically nostr's topology. You even say "the network scales seamlessly, supporting millions of nodes globally". Don't we need billions? Unless you're talking about shared homeservers, but, again — that's the same topology as nostr.
You claim that pubky is "not just another app or platform; it’s a paradigm shift". I'd argue that the paradigm shift happened as early as scuttlebutt, other protocols are just attempts to improve on their work, pubky being no exception. The attempt to claim all this stuff for your own brand is kind of sketchy.
We would have loved to have you over here on nostr for the last two yearse pushing forward web of trust, content curation, decentralized algorithms, identity-based routing, etc. These are things nostr developers have been working on for years now. They're just all still nascent because everyone has their own project to take care of. Nostr has a high level of redundant work happening compared to bluesky, pubky, etc. Which has its challenges, but I see it as a good thing.
I'm hard on pubky not because I'm a nostr-only robot, but because I closely followed your work for quite a while prior to getting into nostr development. I installed the wallet, read the slashtags docs, etc. So this isn't just a confirmation-bias opinion. I'd love to see all the effort that is going into pubky go into building on nostr. Unless you think nostr isn't salvageable? But apart from the DHT implementation, it seems to me like all pubky's good ideas could be retrofitted onto nostr.
Cool, well I think that's fair. Key management is a hard problem. If nostr can't solve it (somehow), then I agree, I don't think it'll succeed. Obviously I think we still have a chance to solve it without throwing away all our work so far, but I don't know enough about how PKARR works so I'll have to read up. I do think though that pubky is about as complementary to nostr as mastodon is. They can be bridged, but that's not a long-term solution, one network will have to win out (meanwhile blossom is pretty much orthogonal to both).
> Pkarr was suggested to Nostr people probably a year ago or so.
Can you link to a conversation? I don't see anything on the nips repo. I can imagine why nostr devs would be resistant. But my point is that you don't have to ask for permission to build on nostr, you could just do it, then say "hey, look how well this works".
It's also fair that if you've had all this in the works since before nostr then you could say the same about us having NIH syndrome. But it's at least interesting that the momentum went with nostr, not slashtags. Maybe that's down to Jack Dorsey, but I think there's more to it than that. That's all on the social level, but you should at least ask why people are building on nostr and not discount it.
My point about DHTs is just limited to p2p networks. DNS doesn't really require that scale, and it seems like pubky also allows for shared network infrastructure, so it may be irrelevant. Nostr relays are really just ad-hoc DHTs, so it's more about how they're used than the technology itself.
Right, we basically have the same thing with bunkers. "Sign in" to your nip 46 signer once, then authorize sessions with the bunker. One nice thing about this is that the signer and data storage are decoupled, which means you're not limited to the "homeserver" paradigm, giving you lots of options for special-purpose relays (inbox, outbox, DM privacy, topic-based, community relays, trending relays, etc). Twitter has tons of interesting caching mechanisms that allow for content to reach across the network quickly. Home server designs (as I understand them) don't actually work very well for that kind of thing.
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.
Yeah, I don't know enough about the PKI to comment too much. But since it's still key-based, you could build that whole system on (or maybe around) nostr.
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.
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?
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.
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.
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.
Running haven, thank you nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hszymhwden5te0wahhgtn4w3ux7tn0dejj7qg7waehxw309a38y6t8dp6xc6t8dp68xtnwdaehgu339e3k7mf0qy28wumn8ghj7ctwdahzucm0d4c82ar9wghsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5kxnuzx and nostr:nprofile1qy2hwumn8ghj7enjv4h8xtn4w3ux7tn0dejj7qgnwaehxw309amk7apww468smewdahx2tcpz4mhxue69uhhyetvv9ujuat50phjummwv5hszgrhwden5te0vf5hgcm0d9hx6ctcd9kkzmrfwd68xtn0dekxjmn99uqzpckv7l8jqspl8u4y54dn9rcduwlrs4v2040nxce0m2h0cunvrj8tac4r8z
This is interesting, someone is quoting a translated version of one of my blog posts, and I still get mentioned. Nostr transcends language apparently.
nostr:nevent1qvzqqqpxfgpzpm8pyl303ymdqefk0rldp0vfm0fydvf4cpczskr0nhqx4a69h2uuqythwumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0qy08wumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0d3skuee0v4esz9thwden5te0dehhxarj9ehhsarj9ejx2a30qyt8wumn8ghj7mn0wd68yetvd96x2uewdaexwtcpzamhxue69uhhyetvv9ujumn0wvh8xmmrd9skctcqypd3249wm3qhyejzg7w53v6dwuk3tllag9nq93424lm4hl0v7arxwcjgvem
Oddbean new post about login | logout
Notes by hodlbod | export