I would like to believe that, but there are some usecases where they are useful. An example would be advertisement over audio. I can't plug a product identified by 52 characters. And these situations will happen all the time, there won't always be a way to share a url or qr.

Another reason to use ICANN is for organisations. You can't sell your company's public key, but the domain is an automatic property of the new owner. I think even if we only use keys, we will reinvent registrars for these use cases.

The point isn't control. Having short names complicates things and makes it much harder to be permissionless and censorship resistance. Because it requires some mechanism to decide who owns what, and that boils down to either central authority, or a consortium, or miners of a block chain.

So, no, not only is Pkarr not like zeronet, we don't even encourage vanity addresses, we want keys to be like phone numbers, you own it, people alias it, and everyone is sovereign and happy.

regarding #2: Pkarr is like DNS it in itself doesn't store data.

but users can point their Pkarr to where their hosting providers are. We also propose a specific API for and HTTP server not too different from WebDav to enable writing arbitrary files in users data stores. So typically a user will sign up to a homeserver, just like they sign up to Google drive for example, and point their pkarr to it. If the hosting provider is misbehaving, the user can point to another hosting provider since they have control over the keys.

Regarding #1 the demo app sends the signed packet to a relay that relays it to a large network of distributed hash table DHT. the only reason you send it to the relay, is because browsers don't support UDP, if you are using native app, that relay is not needed. But even in browser it is still better than Nostr relays, because all pkarr relays are equal, even if you run your own unknown pkarr relay, people will still find your data, because you all eventually publish the data to and query it from the DHT which is what is common and connect everyone, no need for both of us to write and read from common Nostr relays, so Pkarr relays are not cause for centralisation at all, they just support browsers temporarily until they eventually support Pkarr.

as for #3, the format is DNS packet encoding, we didn't reinvent this wheel, it is a very good encoding and very apt for this use case and allows us to leverage all DNS semantics and existing parsers in any language.

If you used Libp2p and thought this is garbage;

1. you are definitely right.

2. Checkout Iroh guaranteed it will "just work"

disclosure, Iroh uses Pkarr to find nodes by their ID because they don't have a DHT themselves, but their holepunching is impeccable and they are artisans and mind their crafts very well.

nostr:note1g72frpre57ld5dcfxhlr4cpulqcl6dhkvjxr657ly843amek3m8spza2uk

I am curious though if you might me misunderstanding pubky and thinking we want to put all data on the torrent network with p2p etc.

That is NOT what we are doing. We strictly use Mainline to find the Homeserver (which is the Outbox in Nostr world, except it is a normal https server like WebDav). All data is on that server, we don't use Torrent at all.

Others might choose to use WebTorrent for some use cases like peertube, but we don't think personal mutable data has enough demand for torrent to be helpful, and obviously not reliable

This a common question: if you need to use a bridge between browsers and Mainline DHT then how is this better than Nostr relays?

1. Native apps obviously are a thing, and arguably they are giving the web a run for it's money, so why dismiss that?

2. relays/resolvers for Pkarr are not only useful for browsers, they also add some reliability and reduce the load on Mainline which then becomes like the DNS root servers

3. Finally to your point, the upside is that you as an app developer can use your own relay to support your browser customers, and I can use my own relay to support my users, and both our relays are going to magically connect, not by gossiping with untrusted strangers, and not by forming private swarms, but by simply using Mainline as the backbone.

This is correct, even when one makes the most conservative bet they can think of, they still have to build the thing.

For the record, I am never asking anyone to build stuff for me, or use my work, I only aim to explain what IS.

What you ought to do is whatever the hell you want really.

nostr:note1t3d7wnxs8vdrzj4vquyg0lhszrwm0jcntzza37k2jz0tcnq5thuqsgvrta

Let's say the chances are 100%, would that matter if the protocol is simple enough that anyone can pick it up and continue working on it?

So, if you see is over complicating stuff, fork our work and keep it simple. I will appreciate that pressure.

which 3 or 4 relays should I query to know what are your preferred servers? how can I possibly know which relays did you post your list on?

wouldn't that by default force us all to post and read from the same 3/4 relays to have reliable resolution? wouldn't that make them target? and what happen when they censor you or go offline? where do I go to find you now?

if you try to solve this, you will end up reinventing DHTs, but you have ZERO chance of making a DHT even 1% of the size of Mainline.

So your options are:

1. use Mainline DHT

2. make a worse more vulnerable version of Mainline DHT and use that instead.

Yes, if you ship your app in a virtual machine you have to live by their rules :)

I could have hardcoded the relay IP instead of domain, but then it wouldn't have worked within https apps.

If you dislike this dependency on ICANN, build native apps, and or help us convince browsers to support pkarr TLDs (will take years).

Nodes will rate limit them, nodes that don't have rate limits will keep dropping older data.

It is a sloppy network, you should never expect the DHT to give you perfect reliability.

But just like you don't query the DNS root servers directly, you don't need to query the DHT directly, you can use relays with bigger cashes and more robust rate limiting and only rely on the DHT for things you haven't seen before.

obviously that also means that you shouldn't update your Pkarr too often, because long TTL is a big part of the reliability and scalability

Miguel already created one a while back. I think it is against our vision where users don't see keys much, instead using their local aliases. https://github.com/miguelmedeiros/pkarr-vanity-keys

This is mine pubky://pxnu33x7jtpx9ar1ytsi4yxbp6a5o36gwhffs8zoxmbuptici1jy

you can put it in the pubky Explorer and see the files I have so far.

it can look like any http url where the TLD is a public key instead of an ICANN granted tld.

Browsers don't support it currently, but you can embed a client in your apps that query and intermediary (relay) to query the DHT for you and return the information about any endpoint you are looking for.

Then you can make normal http requests to http endpoints.

that is more or less what happens in @synonymdev/pubky npm module, you can try it yourself if you have a URL to query, which I can share some with you.

All open source software has leadership whether you recognise it or not.

The question is, is this leadership more of a risk than it is a benefit.

An anarchic leadership reduces the risk of things changing too fast that only large corporations can keep up.

But it also increases the risk of paralysis and implementing ideas that almost everyone agrees is best, because no one has the power to pursue anything decisively.

We think our way of doing things allowed us to design things from first principles and have a very minimalist and well reasoned architecture.

If you listen to us more often, you might be convinced that we are very protective of the simplicity of the core protocol, pushing most of complexity to higher layers or optional APIs, exactly because we want to build one foundational layer on top of another, as opposed to spontaneous house of cards.

These are routing nodes, they have in-memory storage and they only store two things:

1. routing table to nodes closer to a target info hash (basically a hash table automatically sharded)

2. small packets of arbitrary (and other non arbitrary but less relevant to Pkarr) data in an LRU cache.

Nodes churn all the time and even when they don't churn if their cache is full your data might be evicted.

so it is great for censorship resistant routing, not so much for data durability let alone storage of large blobs.

it is easy to think that we are using Bittorrent, since we are using its Mainline DHT, but we are Not.

No p2p storage at all. Just a good old web server, but the censorship resistance come from the fact that you can always point your public key to another hosting provider if you got censored or deplatformed.

In fact, because it is just DNS packets over Mainline, you can use SVCB records to point to mirrors of your data, so even if your main host is taken down, http agents can be smart enough and failover to reading from your configured mirrors.

Happy yo answer your questions.

But the simplest and closest analogy is DNS and WebDav.

Pkarr is a censorship resistant DNS.

Our Homeservers are a nicer WebDav, in many ways, none of which are revolutionary or unfamiliar to web developers.

Some aspects might feel disgusting to Nostr devs, like the fact that data is not signed at client side (not at the protocol level) but we think that is a good thing as it allows for better key management and usage of tried and tested alternatives like good old sessions with cookies.

you can however ignore the homeserver and just put your npub in Pkarr. we just believe that homeservers allows decades of web development to be put to better use.

As you can tell, Pubky core doesn't answer the discovery question, unlike Nostr which starts from discovery then tries to bend relays to be hosting providers with Outbox model.

For discovery we think crawlers and indexers are the normal solution, just like they were for the early web.

But there are plenty of apps that can be built without discovery, and our strategy is to spend the least amount of complexity to achieve the most leverage, before moving to more complex and frankly harder problems in principle (like censorship resistant global search).

I disagree with this, I think phone numbers, and even browser address bars autocomplete prove that subjective local naming of keys are enough for the vast majority of use cases.

I don't need to type your pubky from memory every single time, in fact I don't think I remember the exact handle of every twitter user I follow or the domain of every blog I like to visit.

Even when contacts and bookmarks are not enough, duckduckgo takes me the rest of the way.

human readable names are not worthless but they are not nearly as valuable as people make them sound, and when they are absolutely necessary, ICANN is fine.

Onion addresses prove my point too.

depends on what they are doing and what paths are users giving them access to, but there is no enforcement of sandboxing like in say IOS or something.