This is value judgment though, we are betting that users want a relationship with ONE hosting provider that promises them data integrity, strong consistency, etc.. all what you an I expect from a data store.
But, note two things here:
1. Unlike nswcbunkers, we don't give the homeserver our root keys, and we expect apps to know that we delegated to that Homeserver from Pkarr (like DNS), in Nostr prominent devs killed any attempt to have key delegation, we are not going to play nice with that.
2. Nothing preventing you from taking SOME of the data on the homeserver and cache them around as you wish with higher layers, and if that requires that the data is signed, we plan to get to that, but at least the straightforward usecase of just... you know follow a URL to the authority server is covered.
3. Nothing prevents us from having special service types including mirrors of the data, or literally Email address.. whatever you can put on DNS works. we are just making this new service type because it covers so much of what web2 does for as little complexity as possible. and the least mental load on users.
tons of private conversations with Fiatjaf, and I showed it to Strfry maintainer in private too, and wrote about it here for a year and
https://primal.net/e/note18q4yrj5m2ekvkceq7qn3zqrsxf2w6uq0az2rp867hvz4p5r74wxsa2xchl
First of all, Pkarr was shared with Nostr folks especially Fiatjaf from day one, the reaction was always either Nostr doesn't need it or we can't change the Identity now it is too late.
Secondly if you are willing to make a breaking change like Pkarr as the root identity, then might as well reconsider other unfortunate parts of Nostr that are bundled with the discovery layer for no reason, most importantly why would we use websockets and Nostr events as base API instead of HTTP verbs, headers, and semantics? just because Nostr made that bad decision? Why not build a datastore like WebDav and then advertise that event (PUT/DELETE) on Nostr relays?
Well, pubky core only engages with Pkarr and data stores. And it doesn't tackle discovery so Nostr can be that for Pubky or not.
But note that Pubky didn't take away anything from Nostr, anymore than Blossom takes away from Nostr, if anything wr just decided to use the tried and tested tech of web servers.
It bothers me when a social media app doesn't allow me to override users profile pictures, this is my phone god damn it.
Yes and Holepunch team didn't invent or maintain Mainline...they have an entire whole other DHT.
And we only use Mainline to map keys to web servers, then you proceed like you do after you find the IP address from DNS.
No p2p swarming, no Hypercores or even Torrent. Just http, simpler even than websocket and nostr events. If you know Fetch API you know pubky
what was the worst offenders?
It is very high risk. The work is immense and the reach is almost non existent.
This is why we didn't demand that people install pkdns to use Pubky, in fact we are doing a lot of work to allow web apps as easily as possible.
You gotta go to people where they are, I am even worried about asking users to install a key management app, and that is why there is always the option to upload your keypairs to a web app on your own risk, just to lower the barrier to test the system and what it has to offer.
I want to give every adult a sovereign domain, that can't be done on Bitcoin. I don't know what more to say.
The only thing we can do is invest in UX solutions to all the problems you mentioned. There will never be a future where everyone who wants a domain on Bitcoin can have one, so even if it is superior to ICANN (which it is not because at leas ICANN names works everywhere) it is a dead end.
You are free to use it. And good luck convincing people to buy a name that they can't use anywhere, and then they can't use your app before they buy that useless name. Namecoin existed forever man, no one cares, let's try something with less barriers to entry.
Technically 13 root servers belonging to 12 different organisations, but the structure is more complex because there are observers and stakeholders that have some voice and observers status, from governments to private sector and businesses etc.
There track record is very good, and ther is no close second in terms of being a good custodian of the commons they oversee.
It is a n extraordinary claim that some other organisations should be equally trusted. And even then, why would we move from what we already trust.
I know it has value, Bitcoin can't scale to satisfy that demand though. ICANN or a reinvention of it is the only way at serious scale.
This is why pkdns was an ambition not something we actively tried to sell to people, convincing users to do any of this is pretty hard. Luckily app developers can add support Pkarr and Pubky by embedding it in their apps without asking users to change anything on their system.
Didn't expect many people to get as excited as you about it, but maybe one day browsers and popular DNS servers like 1.1.1.1 will support it natively, and users will get it without much configuration
Sure Pkarr should have used Hyper DHT, all 340 nodes (64 unique IP) of them https://github.com/Nuhvi/crawl-hyperdht
It was rhetorical, of course ICANN is better, anyone who disagrees shouldn't be considered a serious engineer.
nostr:note1p88j5w83pvq6whqak8armcxurtsfd8a049qvgzsqupammyrvx2zsaurl9e
Not even close. Sure once you Know the key, the key can tell you what alias it wants to be called, and you save it in your bookmarks/phone book as such, but that is marginally better than say http title element.
the actual problem is the inverse lookup, how do you find the key by a human memorable name that you heard on Radio or a concert or whatever... that is simply impossible yo solve without either ICANN or Namecoin
Pubky is definitely inspired by RemoteStorage and the general Unhosted.org philosophy. I believe we do things that RemoteStorage does not do though. Most importantly; Pkarr instead of web fingers, and the paginated listing API making Pubky an ordered key value store, not just a filesystem.
I want to make pubky so good that no indiehacker can be bothered setting up a backend to validate an idea.
They would tell early adoptors; Just sign in with your pubky and come with your own backend, and that wouldn't be too much to ask. Maybe even attractive to users who know that their data won't disappear if the developer got distracted by another side project.
he graciously mentioned my name in the acknowledgement section https://logperiodic.com/rbsr.html
Iroh dev here.
The core of iroh is p2p QUIC with dial by node id and very good NAT hole punching, so you almost always get direct connections.
We need a global mechanism to publish some information (a relay URL and optional direct addresses) for an ed25519 public key.
We have multiple mechanisms, one of them pkarr.
So far it works really, really well. Both speed and reliability is comparable to DNS, but we don’t have to run infrastructure. It is just nice in terms of operations even if you don’t care about p2p for ideological reasons.
See https://docs.rs/iroh-net/latest/iroh_net/discovery/index.html
For the record, the reason Nostr has Negentropy is because Iroh team popularised the Range-based Set Reconciliation paper in the community.
nostr:note1qtctn5htzmvgawt793dph79klpj5zcnrlyx7wvnns968nz9wcehqzcey7d
There are around 1000 known PDSs in AtProto, how many Outbox relay are there in Nostr?
I need to read more. But my intuition says, the old owner already had all shares necessary to generate a full valid signature, so that is impossible to verifiable lose.
The only scenario that makes sense to me, is if the company from the start setup the key shares with a trusted 3rd party that assures the new owner that the previous owner doesn't have enough shares to sign on their own. maybe that is what you meant all along.