add libp2p.direct

[aschmahmann]

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)
  • Cloudflare
  • Letsencrypt
  • <UPDATE THIS LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY! REMOVE THIS LINE!>

• This request was not submitted with the objective of working around other third-party limits

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description of Organization

Interplanetary Shipyard is an engineering collective of the core maintainers of the most commonly used IPFS and libp2p implementations and public goods infrastructure.

The libp2p project enables universal connectivity between nodes across different network positions by supporting a wide range of transport protocols.

I am one of the directors of Interplanetary Shipyard and I am submitting this on behalf of Interplanetary Shipyard which will be operating the infrastructure in support of the libp2p project.

Organization Website:

https://libp2p.io/

Reason for PSL Inclusion

We are seeking inclusion in the PSL for per-user origin isolation and security.

We are giving distinct subdomains to libp2p users, basing them on their peer identifier (roughly a cryptographic hash of a public key) that will look like <peerID>.libp2p.direct. As a result, foo.libp2p.direct and bar.libp2p.direct are owned by different users, similar to how various web host subdomains work.

The main use of these domains will be exposing Secure WebSockets and HTTPS listeners, for improving connectivity options for libp2p nodes running in Secure Contexts on the web.

We have no purpose for PSL inclusion other than per-user isolation of HTTPS and Secure WebSockets permissions and connection limits in browsers.

In particular, we've already been discussing rate limit increases with Let’s Encrypt and while we were planning on waiting to apply here until after being granted an increase they were sufficiently convinced that we would get approval here that pre-granting us a rate-limit we would get anyway would be a waste of time on their end. This submission is not aiming to circumvent those limits.

We understand that libp2p.direct will have to keep registration terms longer than 2 years to remain in the PSL. As of this submission, libp2p.direct expires in 2027, and checking + renewing their registrations is something we do regularly for the domains of the various public infrastructure projects and websites we maintain.

Number of users this request is being made to serve:

The libp2p.direct service is one we are providing to the libp2p community (https://libp2p.io/) as a whole, however our first integration is into go-libp2p and the most popular IPFS implementation (https://github.com/ipfs/kubo). There are hundreds of thousands of libp2p nodes in the wild and while many wouldn’t benefit much from a certificate, a whole lot would. IPFS’ Amino DHT alone has tens of thousands of publicly reachable server nodes (stats) which could benefit from having individual per-peer domain names and certificates. However, even giving those tens of thousands of nodes per-peer domain names and certificates would enable millions of users to interact with those peers from browser environments.

There are no past issues or PRs relating to these PSL entries.

We do operate the dweb.link IPFS Gateways on behalf of the community which was added to the PSL in #766.

DNS Verification via dig

$ dig +short TXT _psl.libp2p.direct @8.8.8.8
"https://github.com/publicsuffix/list/pull/2084"

$ dig +short TXT  _psl.libp2p.direct @1.1.1.1
"https://github.com/publicsuffix/list/pull/2084"

Results of Syntax Checker (make test)

============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[simon-friedberger]

The main use of these domains will be exposing Secure WebSockets and HTTPS listeners, for improving connectivity options for libp2p nodes running in Secure Contexts on the web.

I'm lacking the background here. If this is mostly used by libp2p, what exactly is the browser isolating for you?

[aschmahmann]

Thanks @simon-friedberger for the quick response.

• Browser vendors, such as Chromium have internal limits on the number of concurrent resources such as connections or objects per origin and usually separate limits for all origins sharing the same eTLD+1
• In short, talking to multiple libp2p peers sharing same domain can quickly reach these limits, unless libp2p.direct is marked as eTLD (added to PSL), and limits are applied per unique node <peerid>.libp2p.direct (eTLD+1), and not per entire swarm
• Additionally, there is ongoing work enabling people to use HTTP within the libp2p ecosystem that will run into some more traditional limits like cache eviction criteria which I can go into more if needed

Let me know if you need anything else on my end

[groundcat]

Checks:

Expiration (Note: Must remain >2 years at all times):

The domain name libp2p.direct has a registry expiry date of 2027-02-23T06:20:26Z, according to WHOIS records, indicating it is currently in good standing. Please ensure it is renewed in the coming years to maintain a validity period of more than 2 years at all times.

DNS _psl Entries (Note: Must remain in place):

The DNS entries appear correct based on checks with multiple public DNS servers. Please ensure they remain in place at all times in the future.

• Response from 8.8.8.8: "https://github.com/publicsuffix/list/pull/2084"
• Response from 1.1.1.1: "https://github.com/publicsuffix/list/pull/2084"
• Response from 208.67.222.222: "https://github.com/publicsuffix/list/pull/2084"

Sorting:

The sorting appears to be correct.

Basic Security Check:

VirusTotal observations obtained show all clear.

Email:

A nonpersonal email address is used.

[simon-friedberger]

Browser vendors, such as Chromium have internal limits on the number of concurrent resources such as connections or objects per origin and usually separate limits for all origins sharing the same eTLD+1

Is this for libp2p running in the browser then?

[simon-friedberger]

• Expiration (Note: Must STAY >2y at all times)
  • libp2p.direct expires 2027-02-23
• DNS _psl entries (Note: Must STAY in place)
• Tests pass
• Sorting
• Reasoning/Organization description
• Non-personal email address

[aschmahmann]

Is this for libp2p running in the browser then?

Yes, this is to support libp2p in the browser. Technically <peerID>.libp2p.direct addresses will be assigned to non-browser nodes, and browser libp2p nodes will connect to them over Web APIs such as the WebSockets API. libp2p nodes running in the browser context do not have access to raw TCP and UDP ports, and can only use transports provided by Web APIs.

[simon-friedberger]

This sounds a bit odd, I would expect something like this to authenticate with things other than TLS and cookies since you're already using a fairly opaque ID and therefore, there must be some other channel that communicates who to talk to, right?

Edit: Feel free to point me at some docs. :)

[aschmahmann]

Fundamentally the problem is that in order to do any kind of networking activity in a web browser you need to use one of the Web APIs supported transports. These include:

• HTTPS → Not usable without TLS certs signed by a CA
• Secure WebSockets → Not usable without TLS certs signed by a CA
• WebRTC → Has a number of bugs impacting usability in general (Tracking - WebRTC browser bugs libp2p/js-libp2p#2592) and is also not supported in Web Workers
• WebTransport → Not supported at all in Safari, and has a number of bugs in Chromium and Firefox impacting usability (Tracking - WebTransport browser bugs libp2p/js-libp2p#2572)

So realistically, in order to deliver connectivity to users in web browsers today having TLS certs signed by a CA is an important part of the story. While we realistically need these domains and certificates to improve the usability of peer-to-peer tooling in browsers today, we are continuing working with groups like Igalia and browser vendors to improve the story for peer-to-peer networking and self certifiable addressability on the web.

You can see more at connectivity.libp2p.io and learn more about the specifics with Secure WebSockets.

I would expect something like this to authenticate with things other than TLS

To go a little more into the details here, the CA certificates (and TLS processing of them by the browser) are not relied on by users for authentication since the PeerIDs enable self-certifiable authentication without relying on the operators of the libp2p.direct DNS for connection authenticity. Instead what will happen today with a Secure WebSocket libp2p connection is that there will be a second security handshake (using TLS or Noise) that leverages the PeerID and is accessible to the javascript in the browser.

there must be some other channel that communicates who to talk to, right?

This is frequently true and many users discover the addresses associated with a given peerID with routing systems such as the Amino DHT (based on Kademlia - libp2p kad spec), Peer Exchange based on a pubsub topic, or putting the routing system behind an API like https://specs.ipfs.tech/routing/http-routing-v1/. However, to interact with a system like the Amino DHT from a web browser we run into the same bootstrapping problem. How can you talk to the DHT nodes without a compatible transport?

This is what brings us back to needing per-peer domain names and certificates.

Thanks, and let me know if any other information is needed.

---

Side note: I see on GitHub you work at Mozilla, independent of this PR if there’s interest in making this self-certifiable addressing more natively usable in browsers definitely hit me up. My email is visible in my profile.