One thing I don’t like about Nostr is that you have zero ability to lock down who has read access to your notes. I guess unless you run your own server, but even then the nature of the protocol is to spread notes like an unstoppable virus. But 99% of people don’t want that.
Nostr sacrifices safety for proliferation, which is not that trade off that most people want or need.
Does Pubky differ at all in this regard?
On Pubky you have control in the sense that only what's found on your home-server can be considered yours, as in cryptographically linked to you. And you can edit and delete stuff on your home-server at anytime. (Unless you use some future client that signs every note nostr style, but that's not the default way of going about things.)
In terms of read access to your stuff you certainly could control that on Pubky, since the place where things are being read from is your homeserver, not some relay outside of your grasp.
Pubky offers both strong censorship resistance and a high degree control, the trade off is that it didn't emerge from the same sort of quantum soup as nostr, so it's much more managed, at least for now.
How is that different than just using a read-restricted relay?
Depends if you mean a read-restricted relay you run or one that you don't.
In both cases though, it's different because anyone with access to this read-restricted relay can copy the notes, and those notes are cryptographically linked to you, and depending on who you are you might not want that. (And in various other ways too.)
You might want the cryptographic link to be between you and your space, as opposed to between you and your notes.
Ah, I see. But I would have to give up the atomization of the notes to achieve that.
No you wouldn't have to give it up.
On Pubky you can have future plausible deniability, which can be quite empowering for some people. BUT if you don’t want future plausible deniability then you can just sign all your events with your private key nostr style (assuming someone builds out such a client). That's totally an option on the protocol. You have keys at your disposal for whatever you want, same as nostr, want a client that's fully atomic then just a matter of building it.
But it does feel pretty empowering to have that plausible deniability. You want to be able to say it wasn’t me if it actually wasn’t you (your account was hacked) and sometimes you want to be able to say it wasn’t me when it actually was you.
That degrades trust, tho.
Well on pubky you've got both options, atomic (signed notes) and non-atomic (signed space). So you pick the trade-off you want.
If you choose the atomic option on pubky then it'd be no different to nostr in terms of everything being a signed event, and the trust involved.
On nostr you only have the atomic option. Nostr one option, Pubky two options.
That said I’m not sure if there'd be enough demand for someone to code up a pubky client that serves users who want the atomic model. Could be I suppose. One way to differentiate.
Verification of events still happens, but through the location, not individual events.
It doesn’t degrade trust at all. And it increases safety and security. Only benefits.
And yes like Joe said, you can still verify individual events, but for the average person, that is a risk with no upside.
It's like an umbrella and a raincoat. You can have both, but if the umbrella is big enough then most people would probably ditch the raincoat.
you mean every time you receive a note you have to go on a server and ask if it's valid?
if you want that you can just have a relay that signs notes with random keys
anyone reading from that will know they are from you, but the signatures will not mean anything
thinking about it, no one is really going to run their own homeserver, so they will be essentially delegating full power over their identity to some vibecoded malicious provider
"but they just change their pkarr and retract everything"
then in this world nothing anyone ever says can be trusted to really come from them
> delegating full power over their identity to some vibecoded malicious provider
If the homeserver controlled your identity, homeserver migrations would not be possible. Homeserver migrations are possible even after a homeserver has “banned” you. So I think there is some gaps in your understanding
they control it temporarily
because they can publish stuff under my name
> Master keys are kept in cold storage, and access is delegated through revokable homeserver sessions, minimizing exposure and maximizing security.
https://medium.com/pubky/pubky-the-next-web-3287b35408f1
It’s like urbit and “master tickets”.
what I'm saying isn't that they have your key, but that they have your authorization to write stuff in your name by just having it on the server
So do nostr apps, no? Damus can do that right now if they wanted to
what? no, damus is open-source code running on your device, it's not under the control of anyone else
if nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzdmhxw309aex2mrp0yhx5c34x5hxxmmdqyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnvv9hxgpywa92 wanted to steal your key he would not be able to
Ok? If you enter your key somewhere, you’re giving them access to run everything. Pubky is infinitely more secure than that.
And if you use Nostr signers, Pubky is also much simpler.
So cool, copy what pubky is doing and put it on nostr. Problem solved.
good job pretending you're smart or that you understand what you're talking about
you tricked me for a while
Nice passive aggression faggot.
Course he could. He could push an update with a sophisticated backdoor, any nostr dev could. That update gets past app review, your app auto-updates, adeiu to your key. Just because there is a commit in github, doesn't mean that code is what's in the IPA. This is not F-droid.
That is the same with any software.
Exactly. Except F-droid (mostly).
what does f-droid do differently
F-Droid's servers download the source from Github or Gitlab and compile it on their own server. APK is signed with a unique F-Droid key for that app. Third party can then reproduce the build, the two APKs should be byte-for-byte identical. They have a system where they show the results of these independent rebuilds, or a user can just rebuild it themselves. Gets a bit tricky if the app includes non-deterministic elements that make it hard to rebuild the same each time.
thats pretty cool
that's quite a lot of steps involving multiple people, likely to get caught and lead to real world consequences even if after the fact, at least it would destroy nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzdmhxw309aex2mrp0yhx5c34x5hxxmmdqyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnvv9hxgpywa92's reputation forever
very different from one employee from the homeserver hosting provider being tricked into giving access to the account of an important person to some malicious entity
like we have seen happen many times in every big platform
worse even is that someone can say something then claim it wasn't them later
lots of broken incentives you're missing
That just reinforces my point that pasted-in nsec security is reliant on social pressures and not technical ones.
everything is like that
but of course the technology plays a big role in it, you're just larping
Lol. No. Some things can be prevented by technical means and not fingers crossed he’s a nice guy means.
you're trying to imply that publishing a confidential message unencrypted but with a preamble that says "do not read" is exactly the same as using signal because signal could technically ship a compromised apk to you and leak your message
everything is social pressure and trust at some level
you're pretending to ignore that the levels of trust required are distinct
It's not though. On Nostr I operate under the assumption that someone already has my nsec, we all should do that. Because it's entirely possible. I bet at least one person has my nsec right now, maybe a few people. I'd never know. Nostr really does rely on social pressure so why bother trying to be secret?
But if I started again on Nostr and did only Frost and bunker and White Noise and all that, in that case it'd be different. That's still a really bad experience, so I'll wait. But the tech matters, you have to admit.
All good points in this thread, but i’ll still take a key i control over some rando server managed by someone else.
If you have lots of money tied to a key i probably wouldn’t use it in mobile apps that are hard to verify… i would read the source code and compile from source and just use notedeck.
Anyone not reading the source code and compiling it themselves has to trust someone, even in the keyserver case. The server case is even harder for people because people have phones, not computers with servers.
We are already lightyears ahead in comparison to legacy social media platforms and protocols, at least users have the ability to choose their risk tolerance levels with different clients. On legacy they can read your DMs and make posts on your behalf if they wanted to.
True. It's not only risk tolerance it's friction tolerance too.
Though to be fair I should give frost/igloo/bunkers and all that another go, maybe the experience is less friction-y than before. Try living on Nostr for a few weeks bunker only, see how it goes.
pubky doesn't have self-sovereign identity?
lol, sounds like blu esky lite. when i was working with that shit i was like "ok, so how do i verify the signatures on these events" haha lol. nope. trust me bro.
pathetic.
You don't understand how pubky works. I dunno what to tell you. Read the docs.
i'm not gonna bother without a TLDR on why it's better, and if i read in that something about something that is a dressed up consensus, i gonna give it a hard pass.
i've been a student of distributed systems for a long time now, since 2013, and i know a consensus protocol when i see one. nostr doesn't have one, which is the first thing every newbie to it thinks is a deficiency and they crow about how they are going to make it better by adding a consensus to it.
no consensus in the spec means i can add any consensus i want for a specific purpose. if you bake one into the spec that interferes with the use case i have in mind, it's ruled out of the options i might choose.
the things i don't like about nostr are websockets and kind numbers and NIP numbers. those can be worked around and don't lock me into a range of architectures and exclude ones that i consider to be more useful.
Consensus is not something I look for. Not even something that piqued my interest in pubky
i have been building relays and studying the underlying stuff to do that for 18 months and one of the things i figured out was that a major advantage of it is precisely that it doesn't have a consensus.
I dunno, you say these things about pubky or atproto which are factually wrong. Like completely not the case. It's hard to discuss what's better or worse then the core facts are not agreed.
It does.
it's exactly the opposite
because no one connects to your homeserver but only to one big indexer that indexer can forge anything and grant access to anything
there's zero censorship resistance since the indexer can just kick you out and you lose everything
> indexers can be run by anyone, democratizing the process of content discovery.
what indexers will be used in practice? are pubky apps going to connect to a bunch?
what happens if I connect to pubky.microsoft but bill decides he doesn't like you anymore because you've refused to KYC? can I keep following you?
You can do this on Nostr by not signing your notes
But then you have nothing signed. Just junk data floating around
Read from trusted relays and require AUTH to write
You’d need a protocol that shows which relays are trusted and given auth. You’re reinventing pubky at that point
that is called the 10002 list
Yeah let’s just do it that way then. It’s better for regular people. Decreases foot guns
We already have a 10002 list showing which relays people use and trust. Maybe we can add a special flag, but that’s it. Start publishing unsigned notes and you’re good to go.
Notes can still be signed after the fact if you want.
Kind 10002 lists are actually more resistant than Pubky’s DHT as they can be distributed through any channel, not just a single defined method.
Mainline DHT traffic can be detected and blocked.
We’d need to combine this with some kind of “master key” and delegation system, right?
Relays can decide whether they want to allow subkeys to AUTH and write on behalf of the main key.
This is more powerful than delegation alone.
I think the only missing thing would be this aspect then. Or maybe that’s solved too. Not sure. nostr:nevent1qqsvvdezcvrrl7sge9m9jxpkejsp3vsyxmxg867j3lpxxdc8y49kpegpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv826caw
Read restrictions can also be done by you guessed it, AUTH!
And you could build a client that signs every note on pubky too. And people who like that way could use that client with each other.
Except that Nostr already works and is inherently more flexible by design.
Less is more.
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.
I don't want to have to host everything I post.
And I don't want to have to go look in everyone's hosting location if we are all taking in the same room/community.
I dislike the outbox model for that as well.
So you think no one runs a nostr relay from an on premises server but everyone is gonna run a pubky homeserver?
Okay.
Maybe some pubky people will run a pubky homeserver themselves. But all pubky people will control their PKDNS, which is the thing that matters. Homeservers can easily respawn, managed by whomever, wherever.
Pubky is for bittorrent style censorship resistance. You can sign notes but dont have to. Nostr has much weaker DNS based resistance. For nostr to be censorship resistant it needs to use public keys as relays, instead of DNS.
You can use server ip instead of DNS
Can you name one app where you have the ability to lock down who has read access to your note ?
Facebook, Instagram, twitter, I could go on
On twitter if you lock down someone to see your notes, he can just create a new account and continue to see your notes
you can make your account private on twitter. And again… instagram, Facebook, Urbit, many others.
Either way, even if there was a way around it (idk pretend to be someone else and become friends with them?), I don’t think that means you shouldn’t have it.
Nostr just loves to make excuses for poor user experience. “Someone can screenshot your post and share it so it’s pointless to have any privacy at all!”
They had the same attitude about delete functionality for a long time. It comes across as really insecure. Why are we being so loyal to one protocol that is intentionally kneecapped? This is not a marriage. We did not make vows to God to never betray or leave a protocol lol
