Ideas in Computing

We're laboring under a false dichotomy between arcane but scriptable and introspectable CLIs and easily explorable but opaque GUIs. It should be possible to use an inspect-element like tool to easily dig into the internal structure of GUI programs and to easily write scripts and record macros to automate actions with them.

Research OSs like Temple OS, Oberon, the Xerox Star OS, and the Lisp Machine OSs made no distinction between programming and day-to-day use. A well made human-computer interface should be easy and intuitive to use for someone with no interest or knowledge in programming, but should just as readily lend itself to people who want to dig deeper. Early computers like the Xerox Alto were designed to embody this principle and GNU Emacs is the only program I know of that even comes close to it.

The nicest thing about writing Emacs Lisp, typesetting web pages, and writing software on Plan 9 is that the source code for everything is always at my fingertips. Operating systems should be made such that source code is installed and easy to find along with package binaries, a desktop environment could be made to take advantage of this; the closest I know of is the FreeBSD distribution helloSystem. It uses PyQT to build all its applications, I think this might be better achieved if the desktop environment and core applications were built with Common Lisp and McClim.

TempleOS has a command to build an ISO file from an install. The BSDs and Plan9 ship with everything needed to build a system from source. With Emacs I can stick my init.el on a now machine, launch Emacs, and it will install all of my packages automatically, no work needed. I should be able to idempotently configure everything about my OS from a single file, ideally Lisp. Nix comes closest to achieving this but its language is confusing and the fact that it's all tacked on top of a Unix-like system makes it all really ugly and hacky. Guix is promising, but isn't really there yet. Doing this right would require the cooperation of every program on the system to read their config data from a centralized Lisp data structure. This might be achieved at a small scale by using Guile or ECL to embed a Lisp runtime.

We're getting pretty deep into the 21st century and transferring files between two computers sitting right next to each other is still a pain. It might be possible to create a P2P protocol to chat and transfer files between any two computers on a network or just physically close to each other (ideally via Wifi rather than Bluetooth). It should take 0 configuration, just install a program and see nearby devices with that program installed show up. We might also be able to use it to negotiate ssh connections or file-system mounting.

XMPP is the closest thing we have to a messaging protocol that doesn't totally suck, however its ecosystem is so bad that it doesn't really stand a chance of becoming popular right now. XMPP is an extremely modular protocol with functionality split up into extensions called XEPs. The downside of this is that since most XEPs are not core components of the protocol, their implementation is inconsistent between clients. In my experience the only XMPP client that implements enough XEPs to be functional as a nice, modern chat application is Conversations on Android with Gajim on Linux/BSD being a close runner-up.

In order to remedy this I propose we create a library – ideally written in a natively-compiled, memory-safe language like Golang, Rust, or maybe Common Lisp – that implements all the essential functionality of a modern XMPP client including group chats (MUCs), HTTP file upload, OMEMO encryption and key synchronization, publish-subscribe feeds, and voice and video calls. This library could then be used to make the creation of fast, native, and feature-rich XMPP clients much easier.

Libxmpp is just one small step in my long-term plan to create a truly universal and user-controlled messaging platform capable of lasting the next 30 years; a synchronous analogue to email.

The state of GUI development with free software kind of sucks right now. Unless you want to use something ancient like FLTK or reinvent the wheel with X or Wayland graphic primitives, you're basically stuck with QT or GTK. QT is nice because it's relatively light and pretty portable, but it's written in object-oriented C++ which dramatically increases the difficulty of creating new language bindings for it. GTK is written in C so there are bindings to nearly every language, however it's not very portable and it's managed by the Gnome developers who don't seem to care at all about people who don't use and write applications for Gnome on GNU/Linux. Both toolkits absolutely suck at backwards compatibility. Contrast this with Win32 which, while Windows only, worked just as well 20 years ago as it does today. Themeing QT and GTK applications is a huge pain and there isn't really a way to programatically interact with them like with AppleScript and Cocoa.

I'd like to create a cross-platform, easily themeable (think winamp) GUI toolkit with a focus on accessibility and future-proofing, likely written in C but ideally simple enough to be implemented from scratch in other languages, especially Common Lisp. I know very little about how existing GUI toolkits work so this project is pretty far in the future and may just be a pipe dream.

As I understand it GTK and QT use a medley if boutique protocols to load themes and interface with things like screen readers and source browsers, however I think this stuff could be made dramatically simpler and easier to work with by exposing the UI over 9p, just like Plan 9's Acme text editor.

Recently Karl Voit started working on a formal standard for org-mode with the aim of increasing its adoption as a markup language independent of Emacs. As an avid user of org-mode – I'm writing in an org buffer right now – I would really like to be able to simply send people org files instead of exporting them to pdf or odt first.

This meshes nicely with a problem I've noticed in the FOSS side of things: an almost complete and totally lack of lightweight word processors and note-taking applications like TextEdit.app or Notes.app on MacOS. I think that this provides an excellent opportunity to create a lightweight word processor that implements most of the functionality of org-mode in a way that normal people can take advantage of.

This will take time to become a real thing, however I've started work on the initial component, a parser library and command line tool for org files, à la cmark or discount for markdown.

Building off the org-mode word processor idea, it would be great if there was a totally peer-to-peer way collaborating on a document.

I'm thinking something along the lines of Atom's Teletype, but implemented in a way that Emacs users and users of the aforementioned word processor could collaborate on an org document or project without having to create an account somewhere.

Of course, being able synchronously to edit documents stored on a central server would still be a good idea, and could perhaps be adapted to make website publishing really easy, along the lines of the activitypub-based blogging systems.

It might just be a matter of exchanging ed(1) commands through a TCP socket.

Per-document chatrooms might be useful, ideally with a way to be accessed from a bog-standard IRC client for the sake of making this all work seamlessly in Emacs. Given that Emacs runs on a single thread we'd probably use an external program and just communicate with it over a socket or dbus or whatever.

A self-hostable webforum that doubles as an elegant web frontend to mailing lists. Users should be able to interact with all conversation functionality either through the web interface with a local account or via email with their existing address. Having to create a new account for each forum I want to participate in is annoying and the centralization of such activities under Reddit and Facebook is obviously bad. Furthermore, instances of this software should be able to federate with each other via Lemmy's ActivityPub API.

Because of how this software would integrate with email infrastructure, ideally one could use it as a low-effort way of setting up a mailing list with a web UI and excellent search. I'm tired of bleeding my eyes out looking at marc.info and all the other horrifically unusable mailing list archive sites; Sourcehut's list component is the only one I've found that does it right. Content should also be accessible over RSS and Atom and maybe NNTP in order to give new life to all the Usenet newsreaders languishing unused.

More ambitiously, this could lead into an all-in-one self-hostable email server program that does SMTP, IMAP, POP, WKD, CalDAV, CardDAV, mailing list creation, and webmail; in addition to Fediverse integration.

Linux's desktop environments are built atop the Freedesktop project's XDG spec for how programs should behave in the context of a personal computer. By and large, the specifications and the tools that implement them (eg, the xdg-utils package on most systems) are low-effort, poorly-integrated knockoffs of the half-assed ideas shat out by Microsoft. Having experimented with Plan 9 and Haiku OS, everything about the Linux and BSD desktops feels poorly integrated.

When using traditional Unix-clones like FreeBSD or Slackware modern desktop environments and associated tooling feel really clunky. I'd like to create a desktop environment (that is, a window manager with integrated settings applets and core applications) designed to integrate natively with the existing Unix system. The XDG mime-type handling functionality could be replaced by something akin to the Plan 9 Plumber. I'd probably start by using FVWM and writing a bunch of little GUI programs to configure subsets of its functionality along with various system resources.

Emphatically not a computer thing to build, I need another page for this lol.