Skip to content

Global navigation

Home

Issues

Pull requests

Discussions

Codespaces

Explore

Marketplace

© 2023 GitHub, Inc.

About
Blog
Terms
Privacy
Security
Status

Volland
/

pkarr

Navigate back to

Volland

pkarr

Volland

/

pkarr

Type / to search

Command palette

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Cancel

Create saved search

Create new...

New repository

Import repository

New codespace

New gist

New organization

Issues

Pull requests

You have unread notifications

Account menu

Volland

Volodymyr Pavlyshyn

Create new...

New repository

Import repository

New codespace

New gist

New organization

Loading...

Your profile

Loading...

Your repositories

Your projects

Loading...

Your stars

Your sponsors

Your gists

Loading...

Loading...

Loading...

Settings

GitHub Docs

GitHub Support

Sign out

Code

Pull requests

Actions

Projects

Security

Insights

Settings

Additional navigation options

Volland  /
pkarr  /

Clear Command Palette

pkarr

Public

forked from Nuhvi/pkarr

Pin

Watch

0

Notifications

Participating and @mentions

Only receive notifications from this repository when participating or @mentioned.

All Activity

Notified of all notifications on this repository.

Ignore

Never be notified.

Custom

Select events you want to be notified of in addition to participating and @mentions.

Fork
5
Fork your own copy of Volland/pkarr

Starred
0

Lists

Star
0

Lists

Notifications

Participating and @mentions

Only receive notifications from this repository when participating or @mentioned.

All Activity

Notified of all notifications on this repository.

Ignore

Never be notified.

Custom

Select events you want to be notified of in addition to participating and @mentions.

Notification settings

Fork your own copy of Volland/pkarr

Unstar this repository

Star this repository

Public-Key Addressability for Mortals

app.pkarr.org

License

MIT license

Code of conduct

Code of conduct

Security policy

Security policy

0
stars

5
forks

0
watching

Activity

Public repository
· Forked from Nuhvi/pkarr

Open in github.dev
Open in a new github.dev tab
Open in codespace

Volland/pkarr

main

Switch branches/tags

Branches
Tags

View all branches

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Cancel

Create

1
branch

0
tags

Go to file

Add file

Go to file

Create new file

Upload files

Code

Local

Codespaces

Clone

HTTPS

SSH

GitHub CLI

Use a password-protected SSH key.

Open with GitHub Desktop

Download ZIP

Branches

Tags

This branch is up to date with Nuhvi/pkarr:main.

Contribute

This branch is not ahead of the upstream Nuhvi:main.

No new commits yet. Enjoy your day!

Open pull request

Sync fork

Latest commit

Nuhvi

move js implemntation to https://github.com/Nuhvi/pkarr-ffi

…

aa677b4

Nov 20, 2023

move js implemntation to https://github.com/Nuhvi/pkarr-ffi

aa677b4

Git stats

173

commits

Files

Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

design

refactor(relay): client and server shared code

September 24, 2023 13:57

docker/relay

Add docker image.

October 3, 2023 11:09

pkarr

docs: link to z32

October 26, 2023 00:04

.gitignore

move js implemntation to https://github.com/Nuhvi/pkarr-ffi

November 20, 2023 20:33

Cargo.lock

feat: switch to z32 to avoid GPL license

October 25, 2023 23:56

Cargo.toml

wip: basic structs and blocking request

September 23, 2023 12:37

LICENSE

add MIT license

June 14, 2023 22:02

README.md

Update README.md to mention DNS packets and fix the size limit

November 4, 2023 10:32

relays.txt

Added relay.pkarr.lnrouter.app to relays.txt

November 4, 2023 08:25

View code

Drop to upload your files

Drop to upload your files

Pkarr
TLDR
DEMO
TOC
Architecture
Clients
Pkarr enabled applications.
Existing applications
Relays
Republishers
DHT
Expectations
Why?
leverage
Roadmap
FAQ

README.md

Pkarr

Public-Key Addressable Resource Records

The simplest possible streamlined integration between the Domain Name System and peer-to-peer overlay networks, enabling self-issued public keys to function as sovereign, publicly addressable domains. This system would be accessible to anyone capable of maintaining a private key.

Where we are going, this https://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy resolves everywhere!

TLDR

To publish resource records for your key, sign a small encoded DNS packet (<= 1000 bytes) and publish it on the DHT (through a relay if necessary).

To resolve some key's resources, applications query the DHT directly, or through a relay, and verify the signature themselves.

Existing applications unaware of Pkarr make normal DNS Queries over HTTPS (DoH) to Pkarr servers.

Clients and Pkarr servers cache records extensively and minimize DHT traffic as much as possible for improved scalability.

The DHT drops records after a few hours, so users, their friends, or service providers should periodically republish their records to the DHT. Also Pkarr servers could republish records recently requested, to keep popular records alive too.

DEMO

Try the web app demo.

Or if you prefer a CLI

TOC

Architecture

Expectations

Why

Roadmap

FAQ

Architecture

sequenceDiagram
participant Client
participant Relay
participant DHT
participant Republisher

Client->>Relay: Publish
note over Relay: Optional DHT Relay
Relay->>DHT: Put
Note over Relay,DHT: Store RRs (resource records)

Client->>Republisher: Republish request
note over Client, Republisher: Notify Hosting provider mentioned in RRs

loop Periodic Republish
Republisher->>DHT: Republish
end

Client->>Relay: Get
Relay->>DHT: Get
DHT->>Relay: Response
Relay->>Client: Response
note over Relay: Optional DNS over HTTPS server

Clients

Pkarr enabled applications.

Native applications, can directly query and verify signed records from the DHT if they are not behind NAT. Otherwise, they will need to use a Pkarr server as a relay.

Browser web apps should try calling local Pkarr server at the default port 7527, if not accessible, they have to query a remote server instead. Eitherway, these apps should allow users to configure servers of their choice.

Clients with private keys are also capable of submitting signed records either to the DHT directly, or through Pkarr server, to update user's records when needed.

Existing applications

To support existing applications totally oblivious of Pkarr, users will have to (manually or programatically) edit their OS DNS servers to add one or more Pkarr servers to proxy DHT records as DNS over HTTPS.

Relays

Pkarr relays are optional but they:

Trustlessly relay requests from Web apps and applications behind NAT or firewall, to the DHT.

Offer a DoH interface for applications that aren't aware of Pkarr at all, so they can resolve something like https://<key> as usual.

Relays are very light and cheap to operate, that they can easily run altruistically, but private, and paid relays are possible too.

Republishers

Services and hosting providers mentioned in Resource Records of a user, are incentivized to republish these records and keep them alive on the DHT, for the same reasons they are incentivized to gain that user in the first place.

DHT

Pkarr will use Mainline_DHT as the overlay network.
Specifically BEP44 for storing ephemeral arbitrary data.

Reasons for choosing Mainline include:

15 years of proven track record facilitating trackerless torrent for people around the world.

Biggest DHT in existence with estimated 10 million nodes.

It is fairly generous with its retaining of mutable data, reducing the need to frequently refresh records, thus reducing traffic.

It has implementation in most languagues, well understood (by many smart people, that may be willing to guide us), and stable enough to make a minimal implementation from scratch if we need to.

Expectations

To ensure a good chance of scalability and resilience, a few expectations need to be set straight:

This is not a storage platform

Records are ephemeral, and without refreshing them regularly they will be dropped by the DHT.

Popular records may or may not be refreshed by the DNS servers as they get queries for them.

This is not a realtime communication medium

Records are heavily cached like in any DNS system.

You are expected to update your records rarely, so you should expect servers to enforce harsh rate-limiting and maybe demand proof of work.

Records are going to be cached heavily to reduce traffic on the DHT, so updates might take some time to propagate, even if you set TTL to 1 second.

In case of a chache miss, traversing the DHT might take few seconds.

Why?

Why would you need resource records for keys

In pursuit of a sovereign, distributed, and open web, we identify three challenges:

Distributed Semantics Everything expressed as keys and metadata
Developing interoperable semantics for verifiable metadata about a set of public-keys that form a digital identity, complete with reputation, social graph, credentials, and more.

Distributed Database(s) Anyone can host the data
Verifiable data alone is insufficient; a host-agnostic database is essential for an open web, as opposed to walled gardens.

Distributed Discovery Where is the data?
But before that, you need to efficiently and consistently discover the multiple hosts for a given data-set.

Addressing Distributed Discovery first makes the most sense for several reasons:

The difficulty of these three challenges inversely correlates with their order.

The marginal utility of solving these challenges positively correlates with their order.

In existing and emerging open social network protocols, users do tolerate limited interoperability between clients, second-class identifiers controlled by hosting or domain servers, inefficient or non-existent conflict-free replication between data stores, and the absence of local-first or offline support. However, their most common complaints involve unavailability, censorship, deplatforming, and difficulty in securely managing keys.

Distributed Discovery offers the greatest assured leverage by abstracting over current and emerging solutions for (1) and (2) as they compete, complement, and develop independently, all while maintaining the same long lasting identifier, so you don't have to start from scratch or be locked in.

leverage

Solve the most issues...

Pkarr solves unavailability by turning public-keys to resolvable URL: resource locator.
Pkarr solves censorship and deplatforming by allowing users to conveniently change DNS records to point to other providers or platforms. While there are other ways to do that, it is never as reliable and authoritative as DNS.
Pkarr help with key management by enabling users to maintain a long lasting identity tied to one key, rarely used, and hopefully kept offline at all times.

Finally, by solving censorship and deplatforming ina sovereign way, the need for signed data becomes less urgent, and we buy more time to figure out the UX of signing everything everywhere all the time.

with least work

Pkarr doesn't need to bootstrap anything or invent anything, instead using 15 years old battle tested Distributed Hash Table with millions of nodes, and good old web servers.

Roadmap

Implement a web DHT relay.

Implement client-side tools for making queries and validating responses.

Implement a web app to represent the UX and DX of client side.

ClI - publish and resolve resource records.

Add optional caching and republishing of records on GET requests.

Implement a standalone republisher and test keeping 100s of thousands of records alive.

Reimplement everything in Rust once the JS implementation is tested with some scale. << we ar here

Add the DNS over HTTPS features and documentations for adding Pkarr relays in OS and browser's configurations.

FAQ

Why not human readable domains on a blockchain?

Introducing scarcity to names, arguably the most subjective and personal thing in our lives, serves noone except rent seekers. We already know how to use phonebooks, we just need to upgrade small numbers, to bigger sovereign keys.

Why not GNU Name System?

The GNU net is exciting and impressive, but I didn't have enough time to test it or understand how hard it would be to build a PoC on top of it.

GNU name system seems to support Petname system natively, which means it does require more storage and bandwith from the DHT than a 1000 bytes max size enforced by Mainline DHT. I believe that petnameing should be left to application layer.

Luckily GNU net uses ed25519 key as well, so there is always a path for migration if we are careful.

Why not [insert ad hoc solution] instead?
Open social networks often attempt to solve discovery natively within their network of participants. However, this approach has several issues:

It may conflict with participants' (usually service providers) self-interest in keeping users locked in.

Their infrastructure would need to become a gossip overlay network, which may not be desirable.

Achieving consistency and load balancing would require further optimization, effectively reinventing a DHT.

If an overlay network is developed that surpasses the performance of a 10-million-node DHT with a 15-year track record, Pkarr should still be capable of utilizing your network as a backend, either as an alternative or alongside existing solutions.

Edit repository details

Description

Website

Topics (separate with spaces)

Include in the home page

Releases

Packages

Deployments

Save changes
Cancel

About

Public-Key Addressability for Mortals

app.pkarr.org

Resources

Readme

License

MIT license

Code of conduct

Code of conduct

Security policy

Security policy

Activity

Stars

0
stars

Watchers

0
watching

Forks

5
forks

Releases

No releases published

Create a new release

Packages

No packages published

Publish your first package

Languages

Rust
99.3%

Other
0.7%

Suggested Workflows

Based on your tech stack

SLSA Generic generator

Configure SLSA Generic generator

Generate SLSA3 provenance for your existing release workflows

Rust

Configure Rust

Build and test a Rust project with Cargo.

Docker image

Configure Docker image

Build a Docker image to deploy, run, or push to a registry.

More workflows

Dismiss suggestions

Footer

© 2023 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Docs

Contact GitHub

Pricing

API

Training

Blog

About