I’m not sure I completely understand the differences. Are they seperate or somehow connected?
Also I’ve read you can view kbin instances on Lemmy somehow. How does that work if they’re two different things?
I’m using Liftoff is it somehow possible to view kbin instances on there?
Do you mean that their API’s are similar or the same? That’s why they can interconnect?
Not APIs, they use the same communication protocol. Like email does, or like websevers do with HTTP (HyperText Transport Protocol).
Yes and no. It’s not just the protocol but also the fact that Lemmy and bin both are fairly similar in function, making interoperability / connectivity much easier. kbin is probably even a little closer to Reddit in its native desktop layout than Lemmy, which most Lemmy apps also are following. It’s one of the reasons why I went with kbin instead, but I also have a beehaw account which I primarily use for mobile testing, as kbins API isn’t released yet, which means there’s a distinct lack of proper mobile apps at the moment. Here’s how my regular frontpage looks like at the moment, with a couple userscripts.
Thanks for a reminder that I should look into userscripts for kbin. — For now, I’m using the Stylus extension (in desktop Firefox & Chrome) to apply custom CSS. Nothing fancy yet, just simple overrides to remove some margins and padding to make the “compact” view more compact.
https://kbin.social/m/kbinStyles
Simply put, the difference between a protocol and an API are that a protocol is how you communicate, while an API is a way for software to not just communicate with a server but get it to do things as if the software were a human using different, less efficient means.
Let’s take pre-Elon Twitter for example: Twitter’s API allowed automated programs to tweet things without simulating a browser, “clicking” on “new tweet”, putting text in the text box and then “clicking” on “send”. Instead they could directly send the text and identification info to a part of Twitter’s API. This communication with the API happened through a protocol, most likely HTTP/HTTPS, because protocols have in-built ways to handle communication failures, encryption, etc.