A new TLD for locally installed applications

[EternityForest]

Introduction

It is common for a program, especially in the open source world, to provide it's user interface via localhost as a web UI.

This is an easy, portable, and relatively future-proof way to provide a GUI, especially if you may later want remote access.

In addition, decentralized projects often work based on a proxy server on the local machine.

Currently this has several issues. The biggest being that any user on the local machine can usually access the service.

A secondary issue is that there are a limited number of ports, often requiring user-configurable ports to prevent conflict, so it is not practical to link between local applications, as they have no stable URL.

Finally, there is no way to discover and inspect these services or reveal any metadata about them to other apps in a standard way.

Use Cases (Recommended)

• Allow applications to expose a web UI in a secure way only accessible to properly authorized local users.

• Allow linking between local and remote applications in the same way web sites currently link to each other, by giving the same app the same local name on every deployment.

• Supposed decentralized functionality as in my proposal Secure local and remote access to self hosted devices without manual setup #43 in a modular way that does not rely on codifying any one way of doing P2P

• Provide a standard integration point between OS and web app, allowing for OSes to add their own functionality such as remote access.

Goals (Optional)

• Expand the functionality of the .localhost subdomain to better support modern multi-app systems.

Proposed Solution

Create a new top level domain, for example purposes here called .localapp

This TLD would support MDNS resolution, but only on the local machine. Queries would be sent using TTL=0 and never leave the device, and responses would only be accepted from localhost.

It would also support platform specific resolution methods, and transports, like AF_UNIX, so that an OS could provide a way to expose a service to other apps, perhaps with access controls in multi-user environments.

In addition, create a specific service subtype of HTTP to announce via MDNS, so that apps can be discoverable via UI such as a browser homepage.

Examples (Recommended)

A basic productivity app registers itself with the OS, and shows up in your browser homesreen. Clicking it connects over a Unix domain socket accessible only to you.

As this app now has a consistent URL, other apps can link to it, or the OS can even add deeper integrations, providing a near-native, fully local experience from a very simple and portable binary containing only a tiny web app.

A hypothetical P2P network called hashnet lets you grab a file by it's hash. The local daemon is listening for requests to anything under hashnet.org.localapp.

When it sees an mDNS request, it always points to itself, and serves the file on it's HTTP port as an IPFS gateway would.

Some organization claims a URL like sttservice.org.localapp, and publishes an API.

You install a provider app. Now any app can request speech to text services from the provider, which can be swapped at any time for another compliant app.

A remote website wants to control a device on your computer. But you use a browser that does not support WebUSB. The manufacturer makes a companion app, which allows selected websites to access the device via CORS on a localapp URL.

Alternate Approaches (Optional)

Currently, to the best of my knowledge, most alternative approaches require some kind of manual configuration.

Privacy & Security Considerations

On platforms that do not allow an app to list other apps, adding mDNS discovery would(intentionally) allow apps to communication with and discover your app.

It would also allow an app to reveal to chosen websites that it is installed. However, one should not be installing apps anyway if one does not trust them not to share data in ways they don't want.

This could provide a small amount of fingerprinting data.

Without some kind of OS specific transport and discovery, a service could be exposed to other users or daemons on the same device that the user may not want to expose the service to.

These issues can be largely solved in platform and app-specific ways like using mDNS to point to a AF_UNIX style socket that is restricted to appropriate users, by username and password, by client certificate, and by only recommending use of the app for single user systems.

Almost all these issues are also largely the same as what existing uses of mDNS already have.

In addition, apps can already communicate with each other locally in this way if they have the right network permissions, standardizing one application does not open new capability, just new popular use.

Let’s Discuss (Optional)

• Would you enjoy developing or using apps that used a web front end exposed in this way?

• What platform and app features are needed to secure this? Can it be left to up to individual apps to provide users with appropriate API key or password link authentication?

• Should some kind of mDNS record based metadata format be defined for listing apps?

• What recommendations should be in the spec to ensure that .localapps can be remotely accessed in a secure way via proxy servers and the like if desired later?

• How should it work on multi-user systems, where people might have separate instances of the same app? Should that just be out of scope?