Addresser App

Imagine that you could address anything on your system -- public or local -- just by a URL. The URLs happen to have been designed to support this. However, the world still lives primarily just in the http(s)://, rather than supporting a variety of protocols. It may well be, that the reason for this is the browser developers, who had chosen to go the path of virtualization of everything with WebAssembly, so that in the future people could run any binary code in the browser as a virtual machine. However, the reality is that code runs faster and requires less memory, when run directly on the machine. Every instance of V8, or docker, or vbox, or KVM, etc. requires extra memory and resources.

Think about it: the browser is primarily a UI Protocol, defined by W3C, yet its most used feature is not the browser, but the address field! (to locate)

So, the idea is that we could split the address field feature from the browser project as a separate project, that allows any operating system user to dock an address field to their task bar, and call the applications directly from it.

Operating system window managers already have something like this -- you look up for an app with Finder in MacOS, with Application Finder in XFCE4, Search & Lookup tools in Windows, etc., however, it seems there is no popular open source project equivalent to Chrome or Firefox, that would be competing with these operating system utilities, which currently do not have a well-thought-out addressing and lookup paradigm.

Incidentally, the design of "URL" hints of the possibility, that such "Addresser App" could have appropriate schemes defined to locate anything -- from specific processes by procecess ID (e.g., proc://), to memory locations (e.g., ram://), to running UI apps (e.g., app://) within the system, as well things outside the system, like ordinary URLs.

This way, the idea of "Install-less software" could be implemented by changing the people's habit of searching -- from search using browser Address Field, to search using the OS address field, and then, specific namespaces, for example, Telegram (telegram://), etc., could simply auto-install the default open source required software to open those links. An operating system-level indexes and search capabilities could be created to integrate the data for user's benefit of ease of discovery through the "Addresser App".

Think of the "Addresser App" as a replacement for "Finder App", that integrates both the web and local resources, with "batteries" included for aggregation and analysis of all data accessible to the system, and displaying the locations not limited to the web locations. So, for example, if you are in a specific window of Blender, you may have its address shown, when the window is active, for example, it could something like app://Blender/process:1/window:2, or if you have MS Word doc open, it could be smth like app://MSWord/process:1/window:2/page:3, or maybe a an address of Telegram message, like app://Telegram/process:1/window:1/group:1/message:1.

The question that would remain, is who and how would issues new protocols-names behind the ://. Usually, it is the client-server or peer-based system code what (specific build id), is what defines the factual communication protocol. So, perhaps the schema part of the URL should refer to such build IDs, that would be discoverable via the application package managers (and perhaps app stores).