Skip Navigation
Linux @lemmy.ml
Cyclohexane @lemmy.ml

Which communication protocol or open standard in software do you wish was more common or used more?

Whether you're really passionate about RPC, MQTT, Matrix or wayland, tell us more about the protocols or open standards you have strong opinions on!

356 comments
    • Communication: Matrix
    • Browsing: I2P
    • Communities: ActivityPub / Mastodon
    • Software Forge: Fogejo + ForgeFed
    • OS: Linux
    • Money: Monero

    Since they meet at least one of,
    if not all of the following:

    • Decentralized / Federated
    • Sensorship resistant
    • Privacy respecting
    • Open source

  • Others have said already, but XMPP and RSS. Also, nobody mentioned NNTP yet.

    I wish everything was accessible by NNTP and we had better NNTP clients. NNTP is like RSS but for forums (so, Lemmy, Reddit, or anything where you could reply to posts). Download for offline reading, read in your client, define your own formatting, sorting, filtering, your client, your rules.

    If Lemmy was accessible via NNTP, I could just download all posts and comments I'm interested in and reply to them without any connection, and my replies would get synced with the server later when I connect to WiFi or something.

  • I'd love to see more adoption of... I2C!

    Bazillions of motherboards and SBCs support I2C and many have the ability to use it via GPIO pins or even have connectors just for I2C devices (e.g. QWIIC). Yet there's very little in the way of things you can buy and plug in. It feels like such a waste!

    There's all sorts of neat and useful things we could plug in and make use of if only there were software to use it. For example, cheap color sensors, nifty gesture sensors, time-of-flight sensors, light sensors, and more.

    There's lmsensors which knows I2C and can magically understand zillions of temperature sensors and PWM things (e.g. fan control). We need something like that for all those cool devices and chips that speak I2C.

    • I2C is a bit goofy though. As a byproduct of being an undiscoverable bus you basically just have to poke random addresses and guess what you're talking to. The fact lmsensors i2c detection works as well as it does is a miracle. (Plus you get the neat issue where even the act of scanning the bus can accidentally reconfigure endpoints)

      • Yeah, the lack of proper discoverability on i2c truly sucks. You have to just poke random addresses and hope for the best to see if an i2c device exists on the bus. It's a great standard but I wish it would get updated with some sort of plug and play autodetection feature. Standardized device PID/VID system like USB and PCI would be acceptable or a standardized register that returns a part string. Anything other than blindly poking registers and hoping you're not accidentally overvolting the CPU or whatever because the register on your expected device overlaps with the overvolt the CPU register on the same address of a different device.

    • If you have an unused VGA port, you can use the DDC pins for I2C. Be sure to add ESD protection if you do this. An I2C isolator would be even better.

      I2C is really not meant to be used over cables. It has a very limited common mode input voltage range and it can't handle much capacitance on the bus.

      • Except that in the case of VGA (and DVI, HDMI, and DisplayPort) the i2c interface is intended for use over the cable. All of those ports have a pair of i2c pins and corresponding wires in their cables. The i2c interface is used for DDC/EDID which is how the computer can identify the capabilities and specifications of the attached display. DDC even provides some rarely-used control functionality. Probably the most useful of which is being able to control the brightness of the display from software. I use the ddcci module on Linux and it lets me control my desktop monitor brightness the same way a laptop would, which is great. I have no idea why this isn't widely used.

        Edit:

        This i2c interface is widely used to control the lighting on modern graphics cards that have RGB lighting. We've spent a lot of time reverse engineering these chips and their i2c protocols for OpenRGB. GPU chips usually have more i2c buses than the cards have display connectors, so the RGB chip is wired to one of the unused buses. I think AMD GPUs tend to have 8 separate i2c buses but most cards only use 4 or 5 of them for display connectors. There is also an i2c interface present on RAM slots normally used for reading the SPD chip that stores RAM module specifications, timings, etc. This interface is also used for RAM modules with controllable RGB lighting.

  • FTP

    Seriously guys, let's share files the old fashioned way. Without bullshit.

    • I'd like to interject for a moment. What you're referring to as FTP is, in fact, smelly hot garbage.

      For context, I wrote this while waiting for a migraine to pass. I was angry at my brain for ruining my morning, and I like to shit on FTP. It's fun to be hyperbolic. I don't intend for this to be an attack on you, I was just bored and decided to write this ridiculous rant to pass the time.

      I must once again rant about FTP. I've no idea if you're serious about liking it or you're just taking the piss, but seeing those three letters surrounded by whitespace reminds me of all the bad things in the world.

      FTP is, as I've said, smelly hot garbage, and the infrastructure built to support FTP is even worse. Why? Well, one reason is that FTP has the most idiotic networking model conceivable. To see how crazy it is, let's compare to a more sane protocol, like HTTP (for simplicity's sake, I'll do HTTP/1.1). First, you get the underlying transport protocol stuff and probably SSL. The HTTP client opens a connection from some local ephemeral port to the destination server on port 80/443/whatever and does all the normal protocol things (so syn-synack-ack and Client Hello - Server Hello+server cert - client kex+change cipher - change cipher - encrypted data). FTP does TCP too! Same same so far (minus SSL, unless you're using FTPS). Next, the HTTP client goes like this: 

       undefined
          
GET /index.html HTTP/1.1
Host: www.whatever.the.fuck
# a bunch of other headers

      and you know what fucking happens here? The fucking server responds with the data and a response code on the same goddamn TCP connection. You get a big, glorious response over the nice connection you established: 

       undefined
          
200 OK
# a bunch of headers and shit

HERE'S YOUR DAMN DATA NERD

      So that's nice, and the client you're using to read this used that flow (or an evolution of that flow if you're using HTTP/2 or HTTP/3). So what does FTP do? It does one of two really stupid things depending on whether you're using active or passive mode. Active mode is the default for the protocol (although not the default for most clients), so let's analyze that! First, your FTP client initiates a TCP connection to your server on port 21 (by default), and then the server just sends this: 

       undefined
          
<--- 220 Rebex FTP Server ready.

      ok, that kinda came out of nowhere. You're probably using a modern client that saves you from all of the godawful footguns, so it then asks the server what it supports: 

       undefined
          
---> FEAT
<--- 211-Supported extensions:
<---  AUTH TLS;SSL;
<---  CDUP
<---  CLNT
# A whole bunch of other 4 letter acronyms. If I was writing an FTP server, I'd make it swear at the user since there are a lot of fun 4 letter words

      There's some other bullshit we don't care about right now, although highlights include sending the username and password in plain text. There's also ASCII vs binary mode. WE'LL GET BACK TO THAT. :|

      So then we want to do a LIST. You know what happens in active mode? Your computer opens up some random fucking TCP port. It then instructs the FTP server to CONNECT TO YOUR GODDAMN COMPUTER. Your computer is the server, and the other side is now the client. I would post a more detailed overview of the FTP commands, but most servers on the internet disable active mode because it's a goddamn liability. All of the sudden, your computer has to be internet facing with open firewall ports, and that's just a whole heap of shit.

      I'm probably not blowing many minds right now because people know about this shit. I just want to mention that this is how FTP was built. The data plane and control plane are separate, and back in 19XX when this shit was invented, you could trust your fellows on ARPANET and NAT didn't exist and sure HAM radio operators here's the entire goddamn 44.0.0.0/8 block for you to do packet switched radio. A simple protocol for simple times, back before we knew what was good and what was bad.

      So, active mode sucks! PASV is the future, and is the default on basically all modern clients and servers! Passive mode works exactly the same as the above, except when the client goes to LIST, the server opens some random TCP port (I've often seen something like 44000-44010) and tells the client, "hey you, connect to 1.2.3.4:44000 to get you your tasty data." Sounds great, right? Well, there's a problem that I actually touched on in my last paragraph. Back when this dogshit was first squeezed out in the 70s, everyone had a public address. There were SO MANY addresses! 4 billion addresses? We'll never use all of those! That is clearly not the case anymore. We don't have enough addresses, and now we have this wonderful thing called NAT.

      Continued in part 2.

      • PART 2.

        NAT, much like the city of Phoenix, is a monument to man's arrogance. Fuck NAT and fuck FTP. If your FTP server is listening directly on a public IP address hooked up directly to a proper router, then none of this applies. If you're anything like me, the last company I worked for (a small startup), or my current company (many many thousands of employees making software you know and may or may not hate, making many billions of dollars a year), then the majority of your servers are living in RFC1918 space. Traffic from the internet is making it to them via NAT (or NAT with extra steps, i.e. L4 load balancers).

        A request comes in for $PUBLICIP TCP port 21 and is forwarded to your failure of a boxen at 10.0.54.187. Your FTP server is a big stupid idiot and doesn't know this. It thinks that it's king shit and has its own public IP address. Therefore, when it's deciding what ADDR:PORT it's going to tell the stupid FTP client to connect to, it just looks at one of the adapters on the box and says "oh, I'll tell this client on the internet to connect to 10.0.54.187:44007" and then I fucking cry. The FTP client is an idiot, but the IP stack on the client's home/business router is not and says "oh, that's an address living in RFC1918 space, I shouldn't send that out over the internet" and they don't get the results of their LIST.

        So, how do you fix this? Well, you fix it by not using FTP. Use SFTP USE SFTP USE SFTP FOR GOD'S SAKE. But since this world is a shit fucking place, you have two options. The best option is to configure your FTP server to lie about its IP address. Rather than being honest about what a fool it is, you can tell it to send your public IP address to the client rather than the network adapter IP address. Does your public IP address change? Fuck you, you get to write a daemon that checks for that shit, rewrites your FTP server config, and HUPs the bastard (or SIGTERMs it if your server sucks and can't do a live config reload).

        Let's say that you don't want to do that. Let's say you work at a small company with a small business internet plan that gives you static IPs but a shitty modem. Let's say that you don't know what FTP is or how it works and your boss told you to get it set up ASAP and it's not working (because the client over in Bendoverville Arkansas is being told to connect to a 10.x.x.x address) and it surely must be your ISP's fault. So you call up Comcast Business/AT&T/Verizon/Whoeverthefuck and you complain at their technicians for hours and hours, and eventually you get connected to a human that knows what the problem is and tells you how to configure your stupid FTP server to lie like a little sinner. The big telco megacorps don't like that. They don't want to waste all those hours, and they don't want to hire too many people who can figure that shit out because it's expensive. You wanna know what those fucking asshole companies did?

        Continued in part 3.

    • In that case, I'd like to chime in and add NFS to this list. The often overlooked jewel of the glorious past days. /j

  • I’m really into CloudEvents because I love event-driven systems, and since events can come from, or be consumed by, so many different services, having a robust spec is super duper useful.

    • So what problem is this solving? What are some event-driven systems that need to interoperate? Seems like even if you have a common encapsulation method, you still need code to understand and deal with the message body. Just seems like an extra layer around a JSON blob.

356 comments