Replies (16)
Stuff you publish to your homeserver doesn't have to be signed, so your key doesn't have to be hot.
If one wants to verify if you really said something they have to connect to your homeserver and ask.
This supposedly means that you can do access-control better, since there is no way to distribute your content beyond your home server.
Also because they don't do signatures they don't need a canonical event format, so the content that comes from the homeserver can be of any shape. They like the concept of serving arbitrary files.
Nostr keys can't publish to the BitTorrent DHT, because they use a different signature algorithm.
DHT is also much slower, and more susceptible to attack. On Nostr you can get the relay list entry from anywhere and then chain from there to the final version.
Of course but if pubky's selling point is dht ... adding this to nostr is trivial. Clients could check dht in parallel to using the "whatever" approach. Checkmate Pubky.
Also, there is nothing preventing signing of homeserver data, it can be done at app level, or client level, or indexer level, or server level, because all you need to do is delegate keys, or identity-bind them. These are only possible because of the pkdns aspects.
We already have a noise lib, and working on identity-binding, so Pubky will also have signing, private data, private message, etc.
This open-ended set up is why barely anyone gets it at first glance, I think.
Nostr enforces signing JSON and sending/getting from relays. Which is in comparison, obviously, easier to grasp.
But being easy to understand, doesn't mean it auto-magically fits every web use case. The "simple" upfront constraints of websockets, JSON and needing signatures for everything require quite the set of complex of work around for 90% of things here, lol.
Being easy to grasp is what gets so many devs on board and the ver common desire for interoperability results in simple rules. In the end, nostr might have the critical simplicity needed to spark an explosion of projects that pubky so far has not managed to inspire.
And maybe nostr will end up being more complex than pubky by necessity from its limitations, yet had it started out with that complexity, it would never have reached any adoption at all.
Well, they are also trained to act like some sort of auto-immune disease instead of actually believe other designs can exist or be better.
Yes, Nostr is "simple" by omission of required protocol, not by elegance.
Have you read the message? He was suggesting that "better" might not be a timeless property. A protocol can fail because it fails to inspire because the "marketing team" is literally one narcissistic nerd.
lol no one cares what you think about me, you need to actually matter to have a reputation
This is a genuinely underappreciated tradeoff in the homeserver model. Moving signature verification from the client to the server means you can actually do proper access control -- sealed sender, private groups, ephemeral content -- stuff that's nearly impossible with pure NIP-01. The cost: you lose the ability to independently verify authorship. That's not a trivial loss for a censorship-resistant protocol. But maybe it's the right tradeoff for the 90% of use cases that need social features more than auditability. The interesting question: can you bridge the gap with optional client-side signatures on top of homeserver posts?
And by not imposing any shape to the data, it most likely means there's no API for searching data by some specific content field (as we have with one-letter event tags).
I think there's just fetching by path (like folders) and anything beyond that would have to be made custom by homeservers that care (similar to NIP-50 extensions). This aspect seems limiting.
Why do you think there are any limits to any of this stuff? It is just a pile of various unenforceable best practices that people converge on.
Look into our semantic social graph and nexus indexer. It's a freeform open graph for coordination.
I see, there's a need for an indexer to aggregate content from homeservers and then make endpoints available for fetching filtered data, like these:
https://nexus.pubky.app/swagger-ui/.
There are pros and cons to doing it this way. Offering a reference implementation full of features from the start has its advantages. Requiring a big server is one disadvantage in comparison to non-indexer Nostr relays.
Pretending you don't need scaled servers is not the same as not actually needing them.
For Nostr, atleast, it depends on what it wants to be. I myself don't understand what people expect from Nostr relays.
I would like Nostr to be free public relays that hold events for just 2 to 3 days, unless you pay them or are an influncer that brings traffic that could be of use for the operator somehow. <- This doesn't need scaled servers.
Though it looks like most of the current users and apps expect big relays and blossom servers to store events and media for free forever, which is an illusion.
What you want is incompatible with reality, as you have already noted ;)
