Email Compose Screen As A Primary Computer Interface

concept: The compose email screen as primary “command line” and scripting interface

send an email to “notes@localhost” to take a memo

send an email to browser@local to fetch a news page

send emails to cron and etc to configure automated processes and configure servers

advantages

1. can be used over high latency low bandwidth networks such as sat phones
2. every “command” is logged dated, searchable and immutable (aside from delete)
3. has a built in model for permissions and capabilities objects
4. built in encryption and highly advanced compound document format SMIME and mime multipart
5. huge ecosystem of utilities for managing, syncronising and backing up email
6. integrates with the actor model in an obvious way (messages can be messages)

7. correspondences with programs are asynchronous and threaded rather than session based; they do not require an “always on” connection to do anything long running. results are delivered reliably, not just if you hppen to have a stable connection

cons are… the things wrong with email; spam, spoofing, google/microsoft monopoly. etc. which is irritating especially because some of that seems fixable to me with some slight modifications to the email clients and protocol

like, for instance, email could totally have a “friend” system like every single messaging app and social network in existence, in which you individually approve who is allowed to contact you.

and cryptographic signatures need to be on by default and verified - no spoofing

such a system could dovetail nicely to an object capability type of system as a generalisation that includes one entity (such as a person or program) being allowed to “request” things from another.

and then a thread representing a revokable sequence of capabilities

there’s a lot of other pain points with a system like this that i can attest to as having some experience with a system like this in the 1990s called “Juno” which i am sure i am the only one who remembers.

My proposition is that email clients as they exist today aren’t good enough to be a primary interface to a computer or network but there’s a bunch of obvious and less obvious improvements that could be made to them to make this nice

as much as we dislike them how they are being used now, one of the things an (entirely local, hype free) llm could do is assist with properly formatting commands, along the lines of the advanced autocomplete feature it is- for systems that require fiddly formats and an explanation of what a command will do

there’s lots of other client side ide style assistance ui that can also be employed here to avoid the “shot in the dark” feeling of sending an email command and waiting for an error

note also email already has mature provisions for dealing with calendars and calendar invites, and contact cards.

please note that webOS and palm pre had a very interesting notion of a contact card oriented UI, in which all the correspondence with a particular person or entity, from all the various possible communication channels (phone, sms, twitter, email, etc) are consolidated into the contact card rather than balkanised into 100 “branded experiences” like with apps

if we expand a contact orientation out a little bit a contact could correspond to your self host server, with channels corresponding to all the various services it supplies.

your history of setting up that server organised under its contact card, filterable per service

@misterdave@tilde.zone no absolutely not it’s completely different and how darw you imply that ;)