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.<zbase32 public key> 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.
This is great. I'd like to see it expanded to include everything I need to do to get a fully functional code out. No need to recode http, or mainline dht but any new protocol that pitches decentralization MUST offer a way to not use any of its own code if it wants to win. And implementers must have enough details to be interoperable with one another.
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.
Pkarr has design documents if you want to implement it from scratch, but you are better off just using Uniffi.
The same can be said about Pubky core client. If you think about it as an upgrade of FetchAPI or an extension to it, then really there is no reason to avoid a good maintained and evolving reference implementation.
It is not like Matrix sdk where it is so massive and complex that you have to take it as is and can't do much with it except build the exact same app.
It is more like Curl. At least I hope it becomes as reliable and useful.
I am never going to build on top of a stack that I cannot understand to its core. And never going to build in a "decentralized" stack that is fully centralized in just one code base.
I am not saying that apps that use pubky must get together. I am saying that multiple (hundreds) implementers of the protocol behind pubky need to exist.
Otherwise, this is not decentralized at all.
This is no censorship resistance if we are all using the same code.
But didn't I just tell you that it is literally Mainline DHT + a DNS parser + HTTP client?
If you don't want to use our implementation don't. I am not a sales person.
I saw a question about the value proposition and tried to answer it. If you understood it, then mission accomplished.
> Mainline DHT + DNS Parser + HTTP Client.
Yes. You told me, but I want to know EXACTLY how you integrate them all. I want to know all of the encodings so that if I code another implementation, your implementation must be able to see and parse my records.
At this point, there is no value proposion. It's just a bunch of jargon that doesn't clarify why this is better than other DHT-based approaches out there. As you probably know.... Many people have offered solutions in this space and ALL of them fail to deliver an actual decentralized DNS system. In fact, all of them just pitch a re-centralization on themselves via a web of new confusing nomenclatures. Which your proposal seems to do as well. I am giving you the benefit of the doubt, but the more I hear, the more I think you don't actually have anything actually decentralized.
I am also surprised to see how difficult getting information on this proposal has been. It almost looks like you don't want people using your thing.
I don't need you to give me the benefit of the doubt. You are welcome to call me full of shit.
you are however just wrong on both accounts.
1. All the details of how pkarr works is documented exactly where I said they are, go to pkarr.org and open the design directory, if what is there is not enough to build your own implementation and interop, I would be surprised but happy to patch that.
2. Pkarr is decentralised, TODAY. It is not a matter of opinion, it is just a fact. There is nothing in hell anyone can do to censor you, and if I published something on a mainline, ther is nothing anyone can do to stop you from resolving my information. If synonym as a company disappeared today and all our infra died, Pkarr won't stop working.
It might be hard to get enough documentation about the overall Pubky narrative and vision, but Pkarr is not only clear as hell, at least two external teams adopted it and built on top of it without much help from us and not even for the same purpose we are using it for.
Pkarr works and it is censorship resistant, this is a falsifiable claim. You are free to not care to read until you are convinced, but if you want to prove that it doesn't work as claimed, go for it.
The reason I am being aggressive here is because Pkarr was purposefully minimalist and I resisted so many proposals and requests to add complexity, and it has been praised by many for being so minimal and straightforward. So your claim that I am adding a web of new confusing concepts is just weird as he'll:)
all due respect of course 😄
This Markdown is all you need to implement your own Pkarr client and publish or resolve any Pkarr packet https://github.com/pubky/pkarr/blob/main/design/base.md
If you have a Mainline client that supports BEP0044 and this markdown didn't help you publish and resolve to and from our implementation, I will publicly apologise and fix what is missing
> Now you can build on top of such stack, I am sure you could come up with 100s of micro apps ideas
Will each app just put their data in a subdirectory of a user? If so, that reminds me a lot of GunDB! @Martti Malmi
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.
Is there a concept of giving access only to specific files / directories then?
yes, authorising a 3rd party app involves approving a request for given abilities on given resources. Normal stuff.
So basically you're saying you can do 100 censorship resistant micro apps, based on off your npub? This is next level stuff ...
I'd like to setup my own pkarr-type service. Do I need pkdns or just pkarr or is more required. If you can give me a high-level checklist I'll try and set it up and submit PRs as I go.
tell me what are you trying to build and I will try to help point you in the right direction
Oddbean new post about login | logout