All network services I'm aware of speak a language that is geared towards machines. Some are pure binary protocols that are indecipherable to (most) humans without translation while others (REST, SMTP) are a bit more readable, but they are all intended for machine consumption.
A Humane Network Service Interface (HNSI) flips this script and is designed to be used primarily by humans with provisions to support machine consumption.
What do I mean by network service? A network service is a computer program that is shared on a network for others to use. A webserver provides a network service over the HTTP protocol, an email server provides a network service over the SMTP protocol. There are many other types of services and protocols, and programmers do interact with them directly using tools like curl and jq, but most people never interact directly with these services but instead use software like web browsers and mail clients to communicate with these shared network services.
Interacting with a HNSI is essentially like interacting with any text-oriented program or command, the only difference is that you must connect to the service on a shared system as opposed to running a program or command on your own computer. Once a connection is made there's two primary modes of interaction:
* One-shot
* Conversation
A one-shot service accepts everything it needs to provide the service at once, and provides it's reply in a single response. A conversational service expects there to be some back-and-forth, accepting a piece of input from you and providing a piece of output back, along with a prompt or some other form of follow-up request for input until one side of the conversation disconnects. Some services will function in both ways, behaving in a one-shot fashion if all the input it needs is provided up-front while behaving in a conversational fashion if additional input is needed.
In this way these services function much like many unix programs, a pattern adopted by my own set of Pouch tools as well.
With no additional work a HNSI can be used by a person as-is, connecting to the service from a terminal and using it directly. Where these services really shine is when they are integrated with other software to do things they were never designed to do, things that you in particular want to use them for.
Programming with a HNSI is simply a matter of "recording" a direct interaction and playing it back from your own program. This might not sound like a big deal, but compare it to the experience of integrating with a typical network service.
In a typical networked application, any network service is completely distinct from the normal user interface. For example, let's say you use a website to keep track of recipes. You interact with this via a web browser and add recipes by clicking a button that opens a new recipe card where you type the ingredients and steps and then click another button to save it. To view your recipes you click a menu and select an item from a list and a table of recipe names is displayed.
If this application provides any network service to integrate with at all, it will likely be in the form of a REST API. Adding a recipe via the API has nothing in common with how a recipe is added via the normal application, instead you assemble the recipe in a particular data structure format (probably JSON), then you send that data to a specific URL using the HTTP protocol. This HTTP request likely requires authentication, so before you can send this HTTP request you'll likely have to make a request to authenticate some credentials (often against a completely unrelated network service with it's own data formats and address schemes) to get a token you can use to get authorization to perform your HTTP request to store the recipe data.
Before you can do any of that you'll need to study the documentation for the REST API, because using the application teaches you nothing about using the API. This is the case for all network services I'm aware of, the service and the usage of it are two completely separate concerns and working with one provides virtually no knowledge of working with the other.
So how would this example differ with an HNSI?
Your first experience would likely conversational. After connecting to the service and identifying yourself, a list of recipes is displayed and you are prompted for what you'd like to do:
1. Pizza
2. Cake
3. Lasagna
4. Sandwich
(a)dd, (r)emove, (v)iew, (q)uit >
Typing "a" and pressing enter returns a series of prompts to create a new recipe:
New Recipe
(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete> Mac and Cheese
Mac and Cheese
(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete > i
ingredient name: salt
ingredient unit: tsp
ingredient amount: 1
Mac and Cheese
Ingredients:
1 tsp Salt
(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete > c
1. Pizza
2. Cake
3. Lasagna
4. Sandwich
5. Mac and Cheese
(a)dd, (r)emove, (v)iew, (q)uit > q
Now let's say you want to write a little program to import all of your existing recopies from a file on your computer. Once you've read a recipe from the file you'll need to create a new recipe using the service and upload the recipe data. Uploading this data is virtually identical to using the service directly, so you already know what to do so there's no need to learn a completely unrelated way of interacting with the service as is the case with the web-based application and it's REST API.
This not only makes integrating with the service simpler, it encourages services to be simpler as well. Combining the user interface with the machine interface places some back-pressure on complications. Nobody wants to use a piece of software that is hard to use or tries to do so much that it's impossible to remember how to use it. Services that accommodate the humans that work with them also accommodate the humans who program with them creating a beneficial relationship for everyone involved.
I could write more about this but I think I'll wait until I experiment with it a bit and confirm my suspicions and assumptions.
Jason J. Gullickson, 2026