commit 3ee9ee0486250aede9c040f0e8163eeab1f5ca31
parent b5659fa07286f97ce27d78c8f6edfe97ac5f97d2
Author: Andrew Laack <andrew@laack.co>
Date: Sat, 25 Apr 2026 21:13:10 -0500
Incremental
Diffstat:
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/posts/wip/protocols-over-applications.md b/posts/wip/protocols-over-applications.md
@@ -1,24 +1,26 @@
# Reasonably Hostable Protocols Over Applications
-Motivated by Joshua Blais' blog post about using the internet as if it was 1999 [1], I wanted to discuss problematic applications and protocols and why they are wolves in sheeps clothing.
+## Date: 2026/04/25
+
+Motivated by Joshua Blais' blog post about using the internet like it's 1999 [1], I wanted to discuss problematic applications and protocols and the characteristics that make them bad.
## Zulip
-Zulip [2] is an instant messaging program that looks like a bastion of freedom, but it is not. Historically, I have been tricked into thinking free software is the epitome of user freedom, but it is not. Free software is necessary but not sufficient.
+Zulip [2] is an instant messaging program that looks like a bastion of freedom, but it is not. I was previously tricked into thinking it was because it is free software, which I thought was the epitome of user freedom, but it is not. Free software is necessary but not sufficient.
-Try to find a third party zulip client for Linux. You will not. This is what happens when you use applications and not protocols. There are three primary alternatives to Zulip:
+Try to find a third party Zulip client for Linux. You will not. This is what happens when you use applications and not protocols. Let's consider three alternative protocols that facilitate instant messaging:
1. IRC
2. XMPP
3. Matrix
-Try to find third party clients for any of these three protocols and they will abound. This is because they are designed to allow users to make decisions about how they interact with data. Similar to how we build interfaces in software to guarantee consistent interactions with data, so too should the systems we interact with define such elegant interfaces, albeit these interfaces should be much more stable than those of software which can change more flippantly during refactors.
+Look for third party clients for any of these three protocols and they will abound. These protocols were designed to give users the freedom to decide how they interact with their data and the data of others. Similar to how we build interfaces in software to create consistent interactions with data, so too should the systems we interact with define such elegant interfaces, albeit these interfaces should be more stable than those of software.
-The point here is I value having the freedom to choose how my data is displayed to me. I want vim-like keybindings in the terminal most of the time. I sometimes want something more like Lagrange [3] which allows me to apply tasteful styling to information with the ability to render images and play videos, things terminal emulators ought not to do, but some still try [4].
+The underlying principle is the freedom to choose how data is displayed is a freedom worth having. I want vim-like keybindings in the terminal most of the time. I sometimes want something more like Lagrange [3], allowing me to apply tasteful styling to information with the ability to render images and play videos, things terminal emulators ought not do. My preferences likely differ from yours sufficiently as to warrant us using different presentation layer software, this is okay when using simple protocols.
## Bluesky
-The Bluesky social network is known for using the AT Protocol. People frequently misunderstand the social network, believing it is decentralized, which it is not, and believing it is federated, but this is only technically true, but not meaningfully so. Until recently, only the Bluesky organization was running a shared heap for social interactions on the network.
+The Bluesky social network is known for using the AT Protocol [4]. People frequently misunderstand the social network, believing it is decentralized, which it is not, and believing it is federated, but this is only technically true, but not meaningfully so. Due to limitations in the AT Protocol, true federation with BlueSky using your own relay server required 4.5 TB of storage in 2024, growing since then [5]. This is was an undue burden that most people wouldn't be willing to accept, and has since grown.
The AT Protocol specifies all contributing nodes to the network must maintain a copy of the entire shared heap. This imposes computational and storage costs that are unreasonable to most. As of 2024, this required 5 TB of storage, only growing since then [5].
@@ -50,6 +52,10 @@ Currently, video hosting is a strange pain point. Videos are large in storage an
Real time calling and video conferencing are ephemeral to me. I don't want to have a recording on conferences in the future. The only point of significance is I don't want others to have any either. As such, I find Jitsi meet, and other free software programs similarly permissible. Ideally, there would be a protocol for this, but there are not very many ways to interact with video streaming data so the benefits of protocol extensiblity are minimal.
-# References
+## Citations
-[1] - https://joshblais.com/blog/using-the-internet-like-its-1999/
+[1] - [https://joshblais.com/blog/using-the-internet-like-its-1999/](https://joshblais.com/blog/using-the-internet-like-its-1999/)
+[2] - [https://zulip.com](https://zulip.com)
+[3] - [https://github.com/skyjake/lagrange](https://github.com/skyjake/lagrange)
+[4] - [https://en.wikipedia.org/wiki/AT_Protocol](https://en.wikipedia.org/wiki/AT_Protocol)
+[5] - [https://alice.bsky.sh/post/3laega7icmi2q](https://alice.bsky.sh/post/3laega7icmi2q)
