@HamSwagwich

This is a result of the original design. Kbin, up until just before the peak traffic hit, was using boosts as upvotes and favorites/likes were just below the post/thread (where boost sits now). Lemmy does it the way it is now (likes = upvotes) so Ernest changed it to match Lemmy behavior. But just as he changed it, he hadn’t changed the calculation for reputation to match when the server nearly melted down and he has to spend all his time just trying to keep the site alive by himself.

@Treedrake

Most replies here are correct. To clarify and summarize:

1. The source of truth for a magazine/community is the server name that appears after the magazine name.

e.g. kbinMeta@kbin.social <--- the source of truth is kbin.social.
2. ActivityPub and the Fediverse is a "Push" model. What does this mean?

Imagine subscribing to a real-world newspaper or magazine with home delivery(few these days will actually remember this, but try to imagine at least). You will get all new issues delivered to you from the moment you became a subscriber, but you don't get copies of all the newspapers or magazines they have ever printed delivered to you. You only get things moving forward. That's the same with the Fediverse. After you subscribe or follow something, you will get all the new content moving forward, but not what has been created so far.

1. To extend #2, it's a "push once" model. What does that mean? It means that if I create content from my instance (which is not kbin.social) to the magazine kbinMeta@kbin.social, my content will get pushed to kbin.social. Kbin.social, however, will not "re-push" that content to everyone that kbin.social knows is subscribed to the magazine.

So how does my new content that I created in kbinMeta@kbin.social show up on other instances that are not kbin.social? I thought you said your content only gets pushed once?

Correct. However, it's not quite as simple as my instance pushing just to kbin.social. Strictly speaking, (and this is based on experience with other platforms, not specifically how kbin works since I haven't verified this for kbin 100%) when I create the content, my instance will push to kbin.social and all other instances (not users) that my instance knows are also subscribed to specifically kbinMeta@kbin.social. So my instance actually knows a subset of the instances that are subscribed to kbinMeta@kbin.social and will push the new content to each of those other instances. My instance, however, won't necessarily know all the other instances that are subscribed to kbinMeta@kbin.social. As a result, some instances won't see my new content because it wasn't pushed to them.

1. As a result, to let users know about this potential gap, not only does it mean that older content doesn't automatically show up, it also means that not necessarily all new content will show up either.

Note on #3: I haven't fully verified this. This statement is based on how other, non-kbin instances handle federation. This is how "likes" work across platforms like Mastodon, Calckey, etc. I see no evidence (yet) that this is any different for kbin.

@mpro

Welcome and I hope things are not too overwhelming.

It’s not quite the FAQ I think you’re looking for, but this little one might help with a few things. I’m working on more and hopefully will have a third one soon.

https://kbin.social/...

Good luck and cheers

@peroleu

This is a great question and certainly confusing for those not used to the federation aspect.

A quick explanation:

If the magazine has a domain name at the end of it that isn’t the same as your kbin account, then it means that the magazine’s “home” is on a different instance.

Example:

technology@fedia.io

That means that all the instances (servers) will push content and updates to the “home” instance and receive updates and content from the “home” instance.

When an instance (server) subscribes for the first time to a magazine on a different instance, it will start to receive new content from that moment forward. However, older content isn’t pushed out to the newly subscribing instance. You can think of it as subscribing to a newsletter or something. You won’t automatically be sent copies of all the older content but you will get new things moving forward.

You can have older content show up by manually entering the direct link to the older content into the search bar on your home instance (in this case kbin.social) but it’s a manual process.

That why the message shows up about “may not be complete” since it doesn’t know how much total content there is on the remote instance.

This topic (called “backfilling posts/contents”) is one that has been discussed on the Fediverse for some time.

@Brome

EDIT: I believe actually it's because the thread is of type Link. Did you create it as type "Link?" If so, try recreating it as type "Thread."

@kill

Do you have your notifications enabled in the Settings tab of your account? If you click on your account name and select Settings, on the General tab underneath the Writing and Privacy sections should be the notification section to choose what to enable.

@Treedrake

You're welcome!

Yes, it is working as intended. The idea is that each instance is responsible for pushing content once, then it's the responsibility of the receiving instance to process and display the content to the relevant users/accounts.

As a side note, if everything was "re-pushed" out, the load becomes even more on the "source of truth" for larger communities with wide federation and a lot of new content generated locally and remotely. I could see this being leveraged to take down servers by simply spamming really large communities (with large federation) with small content forcing the "source of truth" to now "re-push" the content to every server that is knows about for every single new comment, or reply, or post.

@HarkMahlberg

The technical details will determine what can and can't be done, but from the Mastodon documentation:

https://docs.joinmastodon.org/user/moving/

Moving your account is the same as redirecting your account, but it will also irreversibly force everyone to unfollow your current account and follow your new account, if their software supports the Move activity. Your posts will not be moved, due to technical limitations. There is also a 30 day cooldown period in which you cannot migrate again, so be very careful before using this option!

Depending on if k/m/bin receives a "Move" activity, it may be possible to update user blocklists based on the information in the "Move" activity. However, "Move" activity is generally only sent to existing followers. (I don't know all the details on that) Activities are generally sent to an instance to handle, not individual user accounts, though, so I suspect this might not be as big of a hurdle as it might seem.

Short answer: Maybe. Depends on how they "Moved". It wouldn't be simple to implement, however I don't see anything preventing it in this particular case. You should open an Issue for feature request for it. I recommend including the above piece from the Mastodon documentation, however in your issue.

@V699

This is from a while ago. Here is the explanation.

https://kbin.social/...

@operator

Hi! This little FAQ might help out with that if you're interested. I tried to assume low knowledge of the Fediverse so I hope it makes sense.

https://kbin.social/...

@fiofiofio

Not that I've heard. I hope someone does work on a directory since it's going to just get even more busy I think. For reference, the first 3rd party kbin server as part of this recent migration is less than 2 weeks old and until then it was just the main English one, the main Polish one, and a dev one or two. The Lemmy servers have been around for many months.

@Treedrake

Edit: ok, I think I get it. So if someone from a random instance posts to e.g., technology@beehaw.org, and that instance doesn't know about kbin.social, it won't get pushed to this instances representation of the technology@beehaw.org magazine?

Correct. It's only "pushed once" by the instance that the creator's account is on. Of course it will push to the source of truth, but it will only push to other instances it knows are also following that magazine since it doesn't necessarily know all of the instances that follow that magazine. In your example, yes, if the creator of the content (which in this example is an account not on beehaw.org) posts to technology@beehaw.org, their instance will push to beehaw.org and others, but if it doesn't know that kbin.social has any followers of the magazine/community, it won't push to kbin.social.

One other possibility is that the 3rd-party instance does know about kbin.social (for example), but has blocked (defederated with) kbin.social OR kbins.social has blocked that 3rd-party instance, my expectation would be that such content won't show up on kbin.social's "copy" of the community.

@ThatOneKirbyMain2568

Thank you for sharing. There needs to be a lot more for sure added to kbin.

As for the ideas, I haven’t searched for these yet, but you can see which ones have been submitted and which ones have code changes already waiting for review here:

https://codeberg.org/Kbin/kbin-core/issues

The Pull Requests have some code changes waiting for review.

@lavender

That’s a good question. I think I’ll start linking to my Pixelfed account if I start using more images and upload there. Time to test some things.

@the8thbit
The issues on codeberg are a good place to discuss since they don’t “move around” so to speak.

The matrix room can help some with feedback but my opinion is we should be pushing more details-oriented comments to codeberg for better tracking. Matrix suffers from things rolling off and losing visibility.

@timetravelingnoodles

This is due to the nature of the Fediverse mostly. Kbin, lemmy and other platforms all exchange data with each other using a standard that's meant to be flexible, but has a lot of ambiguity. As a result, to accommodate the vastly different platforms (not just kbin or lemmy which are the Reddit-like platforms), some of the design decisions end up with behavior that doesn't quite fully mimic the large social media platforms that many of them try to emulate.

In this regard, upvotes are actually using what's known as a "Like/Favorite/Star" to represent them. These by design, are a way to let the creator of the content/post/thread/microblog/etc know that you "like" their content. In kbin, instead of showing it as a number of "likes" or "favorites" as on other platforms, shows as the number of "Upvotes" on a thread, or post. Lemmy also uses "Like/Favorite/Star" for upvotes.

@Brome

You're welcome! Sort of. In general, Calckey and others (Mastodon as well) don't handle non-Note-type data very robustly. Those are used a lot with groups and Calckey doesn't really understand groups very well. It's know and it's on the road map, but I don't think this one example is a high priority at the moment (Link-type threads)

@wahming

I haven't fully tested this hypothesis, but it's based on what I do know.

I believe that when a comment/reply is federated before the main OP thread/article, it "looks at what it's a reply to" and tries to fetch the "parent" thread. But (and I haven't verified so I'm not certain yet), when it fetches the parent Thread, I don't believe that contains the "group/(magazine)" information, just the "thread content/post" part. It's because magazines are not the author of the Article/Thread, the user account is and so a reply would be to content that the OP account created without reference to the Magazine.

When new content is federated and pushed out at creation time, that does have the associated Magazine information, even though the author is still the user account that created the Article/Thread/Link, etc.

@chris

This is by design. ActivityPub is a push model and it's a Push-once (in general).

What that means is that the instance that the creator/author of the content is on will push the content to all the other instances that it knows are subscribers to the "account/magazine" that the content is being pushed to.

What that means is:

• Feddit.uk will push the content to Feddia.io because that's the "destination" account/magazine.
• Feddit.uk will push the content to any instances that is also happens to know subscribe to the magazine "ukdtt"
• Fedia.io will not re-push the content to all the instances that subscribe. That's the responsibility of the instance that the content "originated" from, not Fedia.io

@skele_tron
It’s a little older but the magazine kbinfaqs@kilioa.org has a couple good ones