Websockets are a web technology that provide a new way for a website or webapp (running in your browser) to communicate with a server. In this case, it is one of the ways the Lemmy webapp can communicate with the Lemmy server.

There have been a few different web technologies used over the years to achieve this, with websockets being relatively new. One advantage websockets have over other solutions is it allows bidirectional communication between the website and the server, and it can hold the connection to the server open for long periods of time to watch for new data coming in. This allows a developer to build powerful and dynamic applications.

It seems like Lemmy v0.17 server-side code has a fundamental issue with how it handles open websockets connections. It was a known issue, was low priority, but suddenly became a big issue when Lemmy rapidly grew with Reddit refugees. Rather than track down the root cause, it was determined to be easier to simply remove the websockets feature in v0.18.

The issue can manifest itself eg when you are browsing by “All”, the website holds open persistent connection to the server to receive all new post submissions so it can show you them without you needing to refresh the page. However the websocket connection will also get flooded with extra posts whenever the Lemmy server syncs with a community from another instance. That is why you might occasionally get suddenly flooded with dozens of new posts from a cooking community from a different instance, including posts from days ago.

The sports results issue is different. It only happens when you click on a post to open it. I haven’t looked at the code, but I’m not convinced it’s a websockets issue. From what I have read, the consensus is “it’s probably a websockets issue, and it should be fixed with the removal of the use of websockets in v0.18”. There were hundreds of changes do the server code between v0.17 and v0.18, so it could be that one of the other changes fixed that bug.

They’re an “always open” connection between your client and the setver. HTTP works by the client sending a request with a return address and the server sending a reply to that address. Wbsockets then create a “socket” connection to the client that can send data at any time without having to open a new connection, negotiate the protocol, and send all the return address/header information/ etc.

Since the socket is already open, no new context is needed and small bits of data can be sent back and forth quickly.

A socket is a dedicated tube for communications back and forth between server and client (the website) all within a single connection. A socket is nice because it’s an easy interface for sending arbitrary data either direction without the client needing to know to explicitly request information from the server. That makes it easier to have a application which responds to changes rapidly. The way Http worked traditionally didn’t allow for servers to push data because Http has a single request and response per connection and clients usually have no ports open (required to receive connections), meaning clients need to request data.

Websockets are a technology built on top of later versions of http and allow a “fake” socket interface which allows servers to push data without the client explicitly requesting it as long as the webpage is open. In this case the server was either sending back the wrong information to the wrong users or the client got mixed up about what to do with the data the server was sending. Either way the bugs lemmy was seeing isn’t intrinsic to Websockets and was purely an implementation issue. The downside for Websockets is it can be a lot of information and heavy overhead to support if not implemented carefully, in lemmy’s case the developers decided to give up on it rather than spend time trying to fix it due to the sudden increase in users and demand on servers. It could potentially return in the future, hopefully in a more polished state.