Where’s the Command-Line for the Internet?
Perhaps you’ve noticed recently that the input box on all major browsers has become a convenient onramp for search engines, namely Google? When was it decided that the only way to navigate the internet was with a search company in between you and your destination? The input box should be a command interface instead of a de facto search bar for Google. I know what I’m looking for, and I don’t need to search Google for weather only to be shown a clickable link to take me to weather.com. Rinse and repeat- because I perform that same function a lot. But we’ve become so accustomed to using that input that we do exactly that. Once the search results appear, we even lazily click on the top link… which is often a paid result (Ad).
Search engines don’t do anything, do they? I mean sure, they organize data and make things accessible. And to my fellow engineers at search companies, I know you do a lot. Let me clarify… what I mean is that you ask a search engine something and it responds with results that it thinks may answer your query. Google has implemented certain functions like arithmetic and conversions and has also begun to add flight tracking and other things. Wolfram Alpha, perhaps the first functional search engine, had an idea to do more than return results, but to act as an intelligent engine capable of determining what you meant… not just what you typed. In fact, Wolfram Alpha’s slogan is “computational intelligence.”
The input box should be a command interface instead of a de facto search bar for Google.
The internet is full of smart users who don’t need a dumbed-down Omni-find-anything function, right? And the internet is like a giant operating system, right? Things are organized into folders and such, we just call them websites. Are you with me yet?
So why don’t we re-engineer the input box on web browsers to function as a command line that is capable of doing more than sending a search query?
Primitive Functions
The command line could support lots of primitives right out of the box like interpreters in programming languages such as python and ruby do. Primitives like simple arithmetic, string manipulations, setting variables, and even piping output to other functions like grep or filters. If you don’t know what these things are, that’s OK! You’ll figure it out. Heck, we could even emulate or run programming languages right in the browser! Learning to program and using the internet could be the same thing.
Additional primitive functions could include any common functions that provide utility such as unit conversions, current time and date, and basic programming constructs.
Authorities
With primitives out of the way, it would be time to set up Authorities. Authorities are based on common services that we “go to” on a regular basis, such as Wikipedia. If I want to view the Wikipedia article about Martin Luther King, Jr, I can get to it by invoking this function:
=> wiki Martin Luther King Jr
The wiki command has been linked to the established authority Wikipedia as the default for this function. Invoking the wiki command passes the function input to the current implementation of Wikipedia’s entry API.
The InternetAPI Standard
While we’re at this, let’s build an interface for the APIs of the internet. Every service and/or website can implement this interface for browsers to call when a user wants that service. It can be thought of as the entry point to the site. After all, you don’t go to wikipedia.org to check the home page. You go there to search for something. The interface can be incredibly simple to start since most users are just trying to search anyway.
Here’s a simple Protobuf-esq representation of the InternetAPI interface. Each service would need to accept the query itself and any optional arguments which it can later parse and use to fine-tune results and navigation. This would allow consistent function invocation in the format:
=>{function} {query} {additional arguments}
Combing functions with primitives could allow us to build our own search filters similar to Google’s site:, filetype:, :allinurl, and more.
Configurable
The browser implementation should also allow users to bind their own internet APIs to the functions if they want to override default behavior…
A popular package manager for developers, Yarn, uses a config file to bind commands to its own inputs. Here’s what a quasi configuration file might look like based on a package.json sample for use with Yarn (and other tools):
The first value, the part before the colon, { search | wiki | weather } is the function alias, and the part after the colon would the unique internet API descriptor to call.
Decomposing the first line, typing:
=> search German Shepherds
Would call the (Google|Bing|DuckDuckGo) Search API with the keyword term “German Shepherds” which is bound to the input variable $input.
Typing:
=> weather
Would simply show the weather based on my current location- because we have designed that in the function binding.
Checking the weather for a specific location would just require invoking the overloaded function that accepts an input parameter:
=> weather Aspen, CO
Not long ago Web Browsers only allowed direct URL into the input box. Chrome brought us a new world in which the box also functioned as a search proxy for Google. Once that use of that was cemented and its utility validated, all browsers followed suit. The search input has now become ubiquitous with web browsers. Now is an opportunity to transform the internet into the operating system of the future, starting with the browser command line and standardizing interaction via the InternetAPI interface and redesigning the way we interact with websites.
