There is a standard for sharing tweet style information and for threaded type information between websites.
You have software which implements the tweet standard (Mastodon), the threaded standard (lemmy) and both (KBin).
You'll notice some communities will be community@kbin.social or community@kbin.cafe, etc.. this indicates they are not local to the website your using and those addresses are KBin instances, its just your website has a copy of the information.
KBin is newer than Lemmy, it has a fairly simple responsive design that works well on mobile. Lemmy has a REST api so its easier to build mobile applications, a lot of people seem to expect/need to access websites via mobile applications.
The key difference is Lemmy is developed by Tankies, they think China's genocide of Ughurs is justified and they administer lemmy.ml.
It’s also worth considering that kbin currently has around 600 stars on GitHub, Lemmy has 11k. Kbin is written in PHP, Lemmy in Rust. PHP is older and more mature as an ecosystem than Rust, but Rust is really popular. I’ve heard few people say nice things about PHP.
Take from all that what you will, but to me it says kbin will grow more slowly. Also if you use an app to browse you’d hardly know the difference between Lemmy or kbin anyway
PHP has a lot of rough edges and somewhat archaic paradigms (OOP), and thus not liked by many, especially those who got used to more modern languages and its features.
Also PHP lacked type safety for a long time, which is almost only disliked by young inexperienced programmers, who think typing int instead of var is scary because their teacher said so.
Pure OOP is now archaic, but the principles are still used. More modern OOP languages incorporate functional programming concepts and are more of a hybrid. C# is probably the best example of a language with strong OOP and good functional support. Java is also heading that way slowly.
Functional programming is gaining steam again, but in its pure form, it’s not as useful in many domains. A hybrid approach of take all the best ideas and use whatever fits best with the problem at hand is going to become the next paradigm, but I don’t think it has a name.
"Pure paradigm" programming languages are really just toys for research and experimentation, IMO. I remember taking various courses on these sorts of things and, for example, the OOP prof would say "one of the cool things about pure OOP is that there are no loops or if statements. Now, here's how you go about faking a loop or if statement using pure OOP, because it turns out you really need that to accomplish anything."
In the real world you'll want to use whatever works best, which often means a language that contains a bunch of features from different paradigms merged together. Ideally in a rational and well-structured manner, but given how much usage Python gets that's clearly not a fundamental requirement.
You also have to balance the ability to get shit done makes a language more widely used, see perl. Eventually things also need to get modified, so languages that are easy to follow become popular, see perl losing popularity.
Archaic by the sense of some people really want to replace it with something new, which will be as groundbreaking as structured programming was. While functional programming has its merits, it's not the catch-all solution as its evangelists claim. It's more of a tech hype around a pretty useful paradigm, but unfortunately people want to use it like a Swiss-army knife, while it's more like a hammer or a screwdriver. I personally prefer multi-paradigm programming languages like D.
It’s relevant in open source because folks like you who are proficient in PHP are less likely to contribute to the project because it’s just not fun for you to work in that language.
PHP also seems to be really unpopular in general. I’m not insulting it as I’ve never used it but no one that has seems to have many nice things to say about it in my experience
Is there an app for kbin? I’ve been using Jerboa for lemmy and like it. Browsers and web pages don’t feel right on mobile. But I do like the idea of kbin being connected with mastodon.
Github stars is not a good metric, firstly because KBin is hosted on codeberg but mainly because a healthy project has lots of unique contributors and regular updates/enhancements.
KBin has 79 open Pull Requests, while Lemmy has 29. From a visual check PR's seem to be older than 2 weeks. Its hard to say one is "healthier" than the other, without scraping information into a spreadsheet.
Secondly Rust is new and has a lot of hype surrounding it, as a result you get a lot of people using it on random projects.
Languages have strengths and weaknesses and developer ecosystems build on the strengths.
For example if I was writing a web application with a database backend I would choose C#, Java or Node.js because there are loads of libraries, tools and frameworks to make it really easy.
Rust is gaining a lot of adoption by embedded system users (replacing C mostly). Lemmy is the only Rust based web server project I am aware of. Which means the level of work to do anything and to keep it updated falls on the Lemmy devs rather than spread out amongst a larger community.
Everyone loves to insult PHP but it has a niche in webservers and won't disappear anytime soon. KBin effort will thus be spent on KBin.
So will posts in a kbin magazine also appear on the lemmy front page? Or do I have to specifically seek them out and subscribe to them for them to appear in my subscribed feed?
If your instance already discovered then, then they should be available in all feed. If you subscribed to them, then they should also be in subscribed feed.
I think by default you don't see the domains of the instances & users, but at least for kbin there's userscripts that enable them, making it easier to differentiate where a user or community / magazine comes from. Generally though, as long as your instance hasn't defederated from the kbin instances, the threads should just appear like all the other instances.
If I can piggyback with a question: Does anyone know how “Read” status for posts is stored and accessible on both softwares? I know that it’s stored and it would be cool if it was private, but I’m guessing it can be collected and used.
This information exists wherever your account exists. It’s nonfederated data, similar to things like your email address, hashed password, and 2FA master key. No other instance has any need to know what notifications you’ve viewed, so they are never made privy to that information.
To clarify: federation is not like P2P where everyone gets a copy of everything. Federation only shares exactly what needs to be shared for the software to function. In the case of Lemmy, this boils down to the following data:
User profiles
Communities
Posts
Comments
Votes
Follows
Blocks
Private Messages
Some of you may be raising eyebrows at this list. Does this mean that anyone can see your votes & PMs at any time? No, not exactly. There’s two big things to keep in mind here:
When possible, the smallest possible amount of federation is used (e.g.: votes are only sent to the instance where the post/comment is, Blocks/PMs only get sent to the instance where the other user is, etc.)
Unless it’s something the website shows, only instance admins can view the data that gets federated with it. Your PMs may not be secure, but they’re not exactly out on Google either.
At worst, here’s what information can be captured by a random bad actor running their own evil instance:
Your username
Your public bio
Your home instance
Your moderated communities
Your moderation history
Your comment history
Your post history
Your votes specifically for posts/comments belonging to the bad instance
Your follows specifically for communities belonging to the bad instance
Your PMs specifically to users belonging to the bad instance
Your blocks specifically of users belonging to the bad instance
The majority of this information is already publicly searchable on your home instance’s website. Pretty much all of the scary stuff requires you to actually directly interact with the bad guy’s instance. If you’re about to vote or follow something sketchy, consider double-checking who runs the instance before you attach your name to it (that’s what the rainbow link is for).
After reading these comments since I also wanted to know the differences, I have determined I am still “technologically challenged”. I basically understood the punctuation.
You know you are old when you think there should be something like a “Technology and Federation for Dummies”!!
Lemmy and Kbin basically just use the same protocol for exchanging information.
Both are similar in that they interpret and present that information in a way that looks similar to Reddit which is why you can see a community on Lemmy as a magazine on kbin and vice versa. In addition Kbin also can interpret it in a way that resembles twitter.
They both started with the protocol but the way they store, serve, and present the information from the protocol is different. For example, I think Kbin stores the information that shows who upvoted what, but I don’t think Lemmy does.
The part about PHP and Rust, the differences of which is the better code?/foundation?
Most of my confusion lies with which instance is the better option as a whole. Is PHP not as reliable as Rust even thought Rust is new? I can not read code so I have no idea what any of that means.
Apologies for my ineptness. I would like to understand better.
I disagree with that analogy. There’s a very noticable difference between how the cars goes (and sounds) among those fuel types. They may all get you to your destination, but the experience is moderately different.
And maybe that actually makes it a good analogy. I’m not really sure.
Ahhh. Well what’s better overall is gonna be fairly subjective. Php in itself was made for serving web pages with dynamic content. It came first so there’s a lot of resources to learn it, more established libraries, and there are more people who know how to code with it. Ernest having experience with PHP is likely a big contributor in his choice to use it
Rust is more efficient in terms of performance because it’s purpose was to replace C, a language that is “close to hardware” (not really but for the purpose of this explanation just assume it). Meaning a coder can deal with things manually that PHP normally does for them. This is a double edged sword because manually doing things allows you to find efficiency in things that something like PHP would miss, but it also gives a lot more opportunities to mess something up.
So in terms of performance I would say
Perfectly Written Rust > PHP > Badly written Rust.
The subjective part comes from how well you think the Rust is coded in Lemmy. So just choose which one you like more.
Lemmy stores who upvoted what but does not make it easily available to everyone like kbin does - you can set up a Lemmy instance to grab upvoted and read them from the DB if you are so inclined, or you could just look at kbin to see the same info
People should really mention the protocol used more often.
These services can work together because they support the ‘ActivityPub’ protocol. Any service that supports ActivityPub can communicate with any other service that does.
They are two separate projects with similar goals (implement a Reddit clone). They both use the activitypub protocol, so they can generally interoperate. Other activitypub based services, such as mastodon, can also interact with either Lemmy or kbin, but in a more limited and clunkier way.
Lemmy was started first so there are more servers and more users, kbin is more recent.
Kbin saw more relative growth in comparison recently though. How well they can communicate with each other always depends on the implementation. For example, I think the microblogging in kbin could definitely be more fleshed out to be able to communicate better with actual Mastodon. Right now it goes more in just one direction.
We can see the posts on both platforms (except for the case of de-federation).
Competition is an odd topic for open source software. For example, whilst mastodon, kbin and lemmy are all competing for attention, they are collectively making the activitypub ecosystem more attractive.
A similar thing happens with linux: Oracle, red hat, canonical etc all compete for market share, but pay for developers to work on the wider linux ecosystem (the kernel as well as GNOME and other apps etc)
They’re what is called federated. They use the same protocols which allow each to see the other. The best comparison I’ve heard to describe it is like how you can read emails irrespective if someone used Google Mail, Yahoo Mail, or Microsoft Outlook, or whatever email sending software.
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.
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.
Add comment