←back to thread

The terminal of the future

(jyn.dev)
299 points miguelraz | 3 comments | 11 Nov 25 20:11 UTC | HN request time: 0s | source
Show context
skissane ◴[11 Nov 25 23:39 UTC] No.45894420[source]▶
My personal opinion-psuedoterminals should be enhanced to provide some mechanism for sending out-of-band data, like the existing TIOCPKT but on steroids. Maybe something like… if both ends support it, they can exchange JSON-RPC messages over this out-of-band channel, with it being possible to discover if the other side supports this or not. Possibly this is just a new TIOC* ioctl

Why? Well one reason is escape sequences are really limited and messy. This would enable everyone to gradually and backward-compatibly transition to a more modern alternative. Once you have a JSON-RPC channel, the two ends can use it to negotiate what specific features they support. It would be leveraging patterns already popular with LSP, MCP, etc. And it would be mostly in userspace, only a small kernel enhancement would be required (the kernel doesn’t have to actually understand these JSON-RPC messages just offer a side channel to convey them).

I suppose you could do it without any kernel change if you just put a Unix domain socket in an environment variable: but that would be more fragile, some process will end up with your pty but missing the environment variable or vice versa

Actually I’d add this out-of-band JSON-RPC feature to pipes too, so if I run “foo | bar”, foo and bar can potentially engage in content/feature negotiation with each other

replies(2): >>45894471 #>>45895203 #
1. zzo38computer ◴[11 Nov 25 23:46 UTC] No.45894471[source]▶
I think JSON would not be the good format for this; it is too limited and requires escaping. DER or SDSER might be a better format; numbers can be stored efficiently in binary, no escaping is needed, you can use any character set (not only Unicode), binary data can be stored directly (rather than needing to encode as hex or base64), etc.
replies(1): >>45894563 #
2. skissane ◴[11 Nov 25 23:57 UTC] No.45894563[source]▶
If one were adding this to the kernel, maybe rather than stipulating a specific protocol, assign them magic numbers; maybe JSON-RPC could be protocol 0x4a534f4e. An app could ask the kernel “which protocols does the pty master support?”, and get back a list of integers. And then it could ask to open a sidechannel for protocol 0x4a534f4e. So the kernel doesn’t even have to get in the business of mandating a specific protocol (whether JSON-RPC or CBOR or 0MQ or whatever), it just opens side channels with a meaningless (to the kernel) integer to identify its protocol.
replies(1): >>45894721 #
3. zzo38computer ◴[12 Nov 25 00:14 UTC] No.45894721[source]▶
I think that might work OK.

Passing the process ID and user ID might be helpful to improve security of the terminal emulator, too. If the sidechannel is a UNIX socket then it will do this (with SCM_CREDENTIALS), as well as pass file descriptors (with SCM_RIGHTS).