Pubky core is like Nip01, it is like DNS and WebDav, and it is more or less what I just described.

Now you can build on top of such stack, I am sure you could come up with 100s of micro apps ideas. Others will too. Your data (the public parts) will be available to them and theirs to you. If you also want every developer to interop with others, get them in a room I guess. Pubky core is not any more responsible for that than the spec of Websocket is responsible for Nostr clients understanding each other.

There is no magic for interoperability, and I don't personally consider it my mission, I want censorship resistant DNS, and a data store with an open API. Higher level abstractions will churn like hell, but at least the data will be there for anyone motivated enough to reverse engineer it and squeeze some value from it.

If you are willing to implement Mainline DHT from scratch, go for it. But if you are OK with using an off the shelf implementation here is how to implement Pubky from scratch:

1. Encode a DNS reply packet containing the endpoints you want, for example www. A 3600 IN vitorpamplona. com

2. publish that packet using Mainline PUT mutable rpc method using an ed25519 keypair.

3.on a different machine, make a GET query with Mainline for the Public key from step 2

4. once you resolve the encoded packet parse it and find www.

congratulations, now you made https://www. into a proper url, now either implement HTTP from scratch, or use your favorite HTTP library to fetch the web page.

there is of course more to it like work on a home server that stores your data for you and republishs your packets on Mainline periodically and offer a simple but open api, etc.

but the main thing here is what I described above, if you don't think that is valuable, then that is fair.

If you don't want to start from scratch, then you can do what I just described using this GUI https://app.pkarr.org , or if you can tolerate rust, you can go to https://pkarr.org where you can read more about the system, but also use the examples in the pkarr directory to publish and resolve packets and get a feeling for the speed and reliability.

so, does a censorship resistant DNS that can fade in the background and be taken for granted by web developers and make all the rest of web technologies usable in a more sovereign way and offer a credible exit from cloud hosts, does any of that sound interesting?

happy to answer more questions.

DHTs had a horrible PR past decade. Some like Fiatjaf and others only experienced them trhough and libp2p which is rightfully shit. Others who know better think that it is not viable to use a DHT as a database, missing the entire point, which is that a temporary censorship resistant routing table is better tha no censorship resistant table at all.

I just went on to validate if it works, knowing that if it doesn't, nothing else will and we can just stop lapping.

Sorry, but we will never bootstrap a million nodes of anything ever again.

Finally some people are skeptic of DHTs vulnerability to Sybil attacks, and I am writing something about that to end this FUD once and for all, but even if they are right, the question remain, compared to what? Because there literally is no second best within the same order of magnitude even.

Not even some things, the only thing we sign (yet) is just a very short lived authentication token, which you send it to your homeserver and get a good old cookie (session) in return, and you use that going forward.

In fact we also have a 3rd party authorization spec(and working code), so you can allow a web app to obtain that session without uploading the keys to that 3rd party app.

We will properly go even further and make your root key only used once in the beginning, then use a delegated key for logging in when you get signed out... but we haven't went that far yet.

For now, you use your key as often as you sign in to Gmail... very rarely

Correct, in that sense Pubky keys are a bit better than Nip5 for individuals, since even with DNSSEC, you don't get the same sovereignty.

The very fact that we insist on identity sovereignty puts us at a disadvantage vs. say Bluesky where people pretend that they own their DID, but they don't.

So if we can't avoid the onboarding cost of managing a root key, at the very least we owe it to ourselves to minimise that UX cost to the least necessary.

More importantly using your pubky root key as nsec goes against our philosophy of keys longevity.

If you can of course put an npub in Pkarr packet as TXT record, but I don't think Nostr will integrate that.

But maybe you can derive an npub from your pubky seed or something, I just don't see much benefit from that.

Thanks.

As much as I love the free hype, I will pour cold water on this though, I don't think just because you can take the same seed and generate two public keys on two separate curves, then you can call that working with nostr.

You can't resolve a secp key from Mainline, not really my choice, just reality.

I do, it is mostly my fault 😀 .

Happy to answer questions.

This is zionism and this is how the western media support genocide. The soldier is confessing war crimes and CNN wants thinks the story is how much war crimes affect zionists appetite! https://nostrcheck.me/media/930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9/e3815336448caf25d2c3d8d1f83c0e7e5d48cda2a6aab7da2b96e56e5c13bc74.webp

If anyone is interested, I am working on custom reqwest::Resolve and rustls::CertificateVerifier that allows reqwest to make https calls to Pkarr (pkarr.org), so anything that has TLD that is an ed25519 key, can have secure connection like ICANN TLDs.

Unfortunately, it will take forever for browsers to adopt that if ever, so a hack is necessary in the meantime.

I don't think it will work in browsers, I wish I was wrong though

We are entering the era of "zionism started with good intentions but lost its way".

That is utter bullshit, of course. zionists never had intentions other than ethnic supremacy through terror and genocide.

But at least delusions about the past are less harmful than delusions about the present.

What is NWC?

You can make HTTPs (TLS) request to a Pkarr top level domain, without relying on ICANN at all.

(I know because I tried it)

Nostr clients that don't highlight Nips and add a Hyperlink to read more, why are you like that?

But that's the point, this regulation kills any competition, unless the competition enforces e2ee like you said, and then most users will stay away because they will keep losing their encryption keys.

That is not feasible for apps where data is more valuable than ephemeral chat.

imagine if Google Drive started encrypting by default, the amount of people that will lose their data (when they never asked for encryption in the first place) will kill the app.

They can and are trying so hard to make that illegal too, it is not like existing laws aren't as equally absurd.

What if I am running extremely tiny business that just happens to serve a very distributed client base? Are those businesses just unfeasible legally anymore?

Of course not, people will keep doing that, but because they are small they are not a target.

I hate this whole thing it is depressing.