Except that Nostr already works and is inherently more flexible by design.
Less is more.
Discussion
It's easier for Pubky to be an optional Nostr add-on, without breaking interop, than the reverse.
So yup, agree.
It makes everything in Nostr essentially a subset of Pubky. There's nothing you can do in Nostr that you couldn't do in Pubky. But the reverse isn't true.
Brining signed JSON to pubky would already break interop with the one app they have.
Bringing pkdns to Nostt event and media hosting + fetching would interop more or less fine.
That's my point.
You could replace Pubky with Internet in your sentence above and it would be equally true and non-argumentative.
I need to know what to build on in priority.
Nostr wins.
Anyone can make an app on Pubky. It's all open source. Some people already have kicked the tires on basic apps.
You can build on Nostr and it'll work fine on a Pubky app set to mimic a nostr client, should that become a thing in future.
It won’t because you need to somehow shove Nostr notes in a completely different identity system.
The reason it won't is because the curves are not compatible. (Ok you could play seed phrase games, but no point). But if it's zapchat then you could absolutely have a zapchat on pubky, you wouldn't have to design a whole new zapchat, keep the signed notes, relays and all. But you would need to go to an Ed curve, so breaking change.
You can take a Pubky based social media app and put it on Nostr as well.
Everything from ActivityPub to Nostr to ATproto to Pubky is built on entities and events.
They share 90% of the concepts. The rough details will remain the same.
The specific choices are what make or break protocols and what make Nostr inherently more flexible and developer friendly
Synonym has tried to build their own “Bitcoin web” in the past. An unnecessarily complicated and bloated ecosystem.
Their most recent pivot is Pubky as they try to grasp onto what remains of the market that hasn’t been captured by Nostr.
All they do is reinventing the wheel for corporate capture.
ActivityPub solved a problem in what they thought was the best way. And to be fair it was good for its time.
Now ATproto is trying to leverage a similar design but with more marketing bullshit and a new platform to capture people.
Pubky is no different. Nostr solved a problem and they are looking for the newest marketing hypeshit to push, so they can capture users.
Your cool idea here is “we can build pubky on Nostr”. And I would be excited by that bc it’s like Nostr for normal people.
So obviously there is value in Pubky. Because we wouldn’t have been spurred to have these discussions without it.
You can build anything on Nostr.
I agree, but when you say that, how much of “Nostr” is just basically client-server architecture + keys? If we call that nostr, then yeah it’s the bedrock
You cannot. If you need an app that displays accurate follower counts for whatever reason, you cannot build that app on Nostr. Elsewhere you could.
You can’t build it elsewhere either. You need to somehow find all users’ servers that might be following you.
Unless your relay collects that information for you :)
Sue you can. Sometimes that "somehow" is possible, given the laws of physics, what constitutes a reasonable infrastructure spend, what the chances of coordinating or limiting the parties involved are.
And sometimes it is not.
Also on nostr there are many things that are possible theoretically but impossible sociologically. Take NIP-04 depreciation. In theory once everyone agreed it was unsafe (which happened years ago) it could have disappeared overnight, for the safety of all. But sociologically that's an impossible outcome, and so it's still with us now.
Gets a bit old hearing nostr can do this, or nostr can do that, when the things being suggested are sociologically impossible. And no, adding the "if we just get everyone to agree" caveat doesn't get us out of this.
Even Youtube cannot show an accurate follower counts. Some people follow on unofficial Youtube client like Grayjay.
Yes, and some people just bookmark pages without subscribing. Or rely on the algo. But in all such instances those aren't YouTube subscribers. So if YouTube says you need 1,000 subscribers to enable monetisation, then that is requirement they can put out. If nostr says you need 1000 nostr followers to enable this or that, there is just no way, and there is no anything else you can point to instead.
Nostr cannot do it but nostr apps can.
If Primal say you need 1000 nostr followers to enable this or that, then that is requirement they can put out.
Right, and nostr.band could do it too (though their numbers would be different to Primal's). Chrome itself could do it if the Chrome team wanted. But this isn't a success of Nostr, in the same way Gmail gmail giving you 10GB of storage isn't a success of SMTP.
You compare that to atproto, where the the equivalent of Primal's caching service is built in to the core protocol itself, and the difference becomes clearer.
Or you look at bittorrent and how tit-for-tat incentives are core protocol, whereas for nostr relay monetisation is something strapped-on and not core protocol.
Makes a difference what's in the protocol itself.
Your “core protocol” distinction is a bogus argument: can it be done, or can it not?
If you look at it that way barely anything on Nostr is core protocol.
> If you look at it that way barely anything on Nostr is core protocol.
Exactly, yes! Nostr is an incredibly light protocol, so when we say what "nostr" can do we have to be careful. Most things attributed to Nostr are not in fact attributable to Nostr at all.
So no, my example cannot be done using "Nostr". It can be done in the same way a chrome extension can translate a webpage, as in that is not something we can attribute to the webpage itself.
Does this mean Nostr is barely anything? No. It's still something. Nostr is websockets and not QUIC, Nostr is k1 curve and not ed curve, and so on. There's a long enough list. But the attribution "nostr" gets for non-Nostr things is pretty wild.
Just like when we say “Linux” we don’t refer to just the kernel but all the distros and tooling about it, when we say “Nostr” we don’t refer to only to the protocol.
Sure, but to a point, past which it's silliness. I often here “Nostr can do X” when the truth is that a certain party can do X in a bubble that they themselves created with off the shelf technologies and that bubble has some sort of connection to signed json events (often less than necessary), and nobody else is doing this thing anywhere outside of this bubble...
You could flip the script and say Nostr is not a social networking protocol at all but rather a hackathon protocol, and then maybe you have a semantic back door to sneak all that stuff in. But if it's to be a networking protocol then some reasonable propagation threshold needs to be met otherwise ...
Like remember when we had Olas v1 and everyone said "Nostr has Instagram now". And then someone does a Kanban thing and it's "Nostr has Trello now". It becomes absurd, you have to admit.
EHHHHEEEMM...it's actually GNU/Linux 🥲
Nostr is infinitesimally tiny in the grand scheme of things. It's fun and I like a lot about it, but a healthy-sized and growing user base it is not.
I have no issue with some particularly entity leading something as long as it's open. I mean the world wide web itself was just a browser out of Cern. They didn't release the code and royalties till 1993. Then Mosaic and the rest came along and the decided to give up the name for general use.
MCP came out of anthropic, MCP is a good thing. Android came out of Google and now we've got Graphene OS.
Stuff can happen like that. Often does.
You seem to be treating Pubky as some sort of more general idea, while in fact they are two completely disjoint things.
Nostr assumes don’t trust, verify by default but can be loosened. With Pubky, each application needs to invent its own way of verifying and it is discouraged by the design.
Nostr relays are inherently simpler than Pubky homeservers. Nostr can also propagate data through a variety of methods, while Pubky makes it hard to not rely on homeservers.
There's no reason a pubky homeserver can't communicate with a websocket relay, both send and subscribe. It's not a case of Pubky homeservers versus websocket relays. It's just that there's very little reason to have websocket relays in the PKverse, because you can just read from the homeserver. But if you wanted to you could. What'd stopping you?
And there’s nothing stopping people from bridging over Pubky data. Or Mastodon. Or whatever.
What design clash though? You could literally port Nostr to the PKDNS world. After doing so, everything in Nostr's design would remain intact (if you wanted it to), so whatever's good about Nostr now would be good about it then. Plus you'd have PKDNS as a new dimension. (Except you can't port it like that because of the incompatible curves, so it's a theoretical exercise, but it does goes to show.)
You could not port things the other way round. So that would make Nostr's design the weaker of the two in terms of flexibility.
Nostr *is* the PKDNS.
That's gibberish.
I can right now create a list type that contains records for a pubkey.
I can send this out via any way I want, whether it be a DHT, or over BLE, or over bog standard relays.
PKDNS can only do one thing and that is use a single easy-to-DPI DHT to resolve records and nothing else.
I can right now also do a lot of things that are of no use to anyone or any system. I can write my keypair on a paper airplane and throw it out the window. I don't get where that argument is going.
Whatever you do has to be useful. There is nothing else like Mainline DHT. Not even close.
It is useful. Nostr can run over anything.
Mainline DHT means nothing if it can be easily detected and censored.
> Mainline DHT means nothing if it can be easily detected and censored.
Couldn’t you say the same thing about Bitcoin?
You could.
And this is why Tor/I2P is great, with bridges and other censorship evasion tools.
And also, Blockstream Satellite is another way you can interact with the network even if that were to happen.
So you could have the benefits of DHT DNS and Nostr if you used the DHT with Tor I guess.
The thing is, I don’t think the DNS lookups even happen very often
Which it is not. If you've put your own homeserver up behind your PKDNS then it'll be an order of magnitude harder to censor your pubky presence than it will your nostr presence. Not to say either would be a cakewalk, but you can't in good faith argue that nostr as it stands today is stronger in terms of censorship resistance.
They can censor your homeserver. Or the internet connections of who host Mainline DHT servers. So on.
DHT requires a complicated system that is easy to detect. A Nostr note however can be sent through any channel and one channel is all you need.
Ok that's factually wrong on I think potentially every count.
Joe this is the most fruitful discussion regardless of misunderstandings.
I think it’s really helpful to talk about Nostr vs pubky in terms of “can you build one with the other?”
Nostr still relies on DNS, if ICANN wanted to they could seize the domains of all the most popular relays. That probably won't happen, but DNS certainly is the centralizing factor of the whole internet.