![User banner](https://kilioa.sfo3.digitaloceanspaces.com/57/55/57550a8bbf1bb3e8d9844120d515c1698340652c7bdf28b53658310ab6267153.jpg)
![dannekrose](https://kilioa.sfo3.digitaloceanspaces.com/8b/65/8b65fbb0009605072ce4558a5444b29e74ac23f50126a02fa9359c9ea02334ae.png?format=webp&thumbnail=64)
Welcome to my little kbin instance and account.
ゲームが好きです。配信もしています。気軽に楽しくやりましょう。ゲーム以外もいろいろな趣味があります。よろしくお願いします。Playing Games. Streaming Games. Games for everyone. I have some hobbies outside of games, too. Nice to meet you.
(He/Him/His)
\#gaming #dnd #twitch #ttrpg #xbox #xboxSeriesX #games #Bilingual #casualGames #ConsoleGaming #dndj #dnd5e #adhd #日本語 #adhd
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.
@skele_tron
It’s a little older but the magazine [email protected] has a couple good ones
@trashhalo
In addition to the previous information, as a side note, it is possible for non-Kbin and non-Lemmy content to be automatically routed to a Magazine via tags and show up as a Thread if the content is federated as a Page. One example is WriteFreely blog posts. Frendica can also do this but I’m not sure on the details.
why it isn't getting sent to rabbitea.rs
If feddit.uk doesn't know about rabbitea.rs, then it won't send it there. The originating instance is responsible for sending it out, but it can only send to instances it knows are subscribed. This can result in some instances not getting new content if it originates on an instance other than the one that is the "home" for a magazine.
And surely the destination magazine must be involved somehow to run rules on like, banned users?
That depends. It depends on if the "home" instance federates out blocks. I don't actually know if kbin federates out blocks (many Fediverse platforms don't actually because it's used as a vector for harassment and dogpiling and other very harmful behaviors), but the 2 cases are as follows:
- If Kbin (or the "home" instance platform) federates out blocks, then all subscribing instances will receive the block information. Whether or not they honor it or not is not guaranteed, but for simplicity sake, let's assume they do.
In this scenario, instances that receive the block will behave as you might expect: they won't allow the blocked user to view the content in the magazine/community but will allow other users to view it. They also will not accept content into their local copy of the magazine from the blocked user.
- If kbin (or the "home" instance platform) does not federate out blocks, then other instances cannot know not to display content from a blocked account, nor do they know not to accept content created by a blocked account. The "home" instance will block such content from being displayed and added to the magazine and thus users on the "home" instance will not see the content, but users on other instances could, in theory, still see the content.
Note: This is partially why the mod_log can be viewed. I'm not 100% sure of the details, but the home instance moderation decisions should be visible on other instances (or at least by visiting the magazine on the "home" instance itself) and moderators/admins should be able to take similar actions on their own local-copy of the magazine.
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
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.
One thing that also plays a role is the size of the queues on the different instances. Kbin.social may get things pushed to it, but with queue sizes reaching 500 thousand or more, it takes time to process them.
Edit: ok, I think I get it. So if someone from a random instance posts to e.g., [email protected], and that instance doesn't know about kbin.social, it won't get pushed to this instances representation of the [email protected] 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 [email protected], 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.
Most replies here are correct. To clarify and summarize:
- The source of truth for a magazine/community is the server name that appears after the magazine name.
e.g. [email protected] <--- 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.
- 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 [email protected], 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 [email protected] 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 [email protected]. So my instance actually knows a subset of the instances that are subscribed to [email protected] 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 [email protected]. As a result, some instances won't see my new content because it wasn't pushed to them.
- 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.
For Sure. It might not be comments, but some other way the thread shows up without the magazine information. I have seen the same thing you describe but I haven’t been able to capture data on it. I have a few ideas on how to test different scenarios but I need to figure out how to capture the raw data as well to verify.
Without looking at the exact full data exchange, I can't say for certain. I don't even know if the trigger is as I think it might be.
But you can get a sense of where the information for the magazine account is by looking at this sample payload of what it looks like when a new Article/Thread is created and federated out. There is no "inReplyTo" because this is the initial thread/article, but it would point to the direct url for a previous content, not the magazine.
{
"@context":
[
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
{
"ostatus": "http://ostatus.org#",
"sensitive": "as:sensitive",
"votersCount": "toot:votersCount"
}
],
"id": "https://kbindomain/m/testmagazine/t/16",
"type": "Create",
"actor": "https://kbindomain/u/demouser",
"published": "2023-06-17T18:58:26+00:00",
"to":
[
"https://kbindomain/m/testmagazine",
"https://www.w3.org/ns/activitystreams#Public"
],
"cc":
[
"https://kbindomain/u/demouser/followers"
],
"object":
{
"id": "https://kbindomain/m/testmagazine/t/1676",
"type": "Page",
"attributedTo": "https://kbindomain/u/demouser",
"inReplyTo": null,
"to":
[
"https://kbindomain/m/testmagazine",
"https://www.w3.org/ns/activitystreams#Public"
],
"cc":
[
"https://kbindomain/u/demouser/followers"
],
"name": "Federation Test",
"content": "<p>Test for the body of the article</p>\n",
"summary": "Test for the body of the article #testmagazine",
"mediaType": "text/html",
"url": "https://kbindomain/m/testmagazine/t/1676",
"tag":
[
{
"type": "Hashtag",
"href": "https://kbindomain/tag/testmagazine",
"tag": "#testmagazine"
}
],
"commentsEnabled": true,
"sensitive": false,
"stickied": false,
"published": "2023-06-17T18:58:26+00:00",
"contentMap":
{
"en": "<p>Test for the body of the article</p>\n"
}
}
}
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.
@RainbowsAre they protected by any kind of bot protections? If so that could interfere.
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)
I edited my reply, but I believe it's because the type is a Link, not a Thread. Can you try recreating the thread but as type "Thread?"
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."
If your Calckey instance has Authorized Fetch/Secure Fetch enabled, this might prevent pulling, but I haven't tested that exact scenario yet.
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.
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.
I actually did testing on that and you can see what I wrote in this FAQ under the question what happens when someone follows a kbin magazine from a non-kbin platform. It’s the part labeled
Small update June 17 2033
https://kbin.social/m/[email protected]/t/20459/A-small-FAQ-to-hopefully-help-new-users-to-kbin
Crosspost: A small FAQ to hopefully help new users to kbin (updated June 11 17:00 GMT)
I wanted to post this here since I want to help as much as I can in my own way to people coming here for the first time. I hope it is useful and helpful! I tried to assume low knowledge with the Fediverse in my responses which I collected here from a different post and assembled into a single articl...
Crosspost: Just trying to help spread information with this little FAQ I put together specific for kbin. If the Magazine mods don't want this here, please let me know and I'll remove from this magazine. That link should point to the local-to-fedia.io thread, but if not, you can also view it at the below link to the original instance.
The original link is here: https://kilioa.org/m/[email protected]/t/266
A small FAQ to hopefully help new users to kbin (updated June 11 17:00 GMT)
I wanted to post this here since I want to help as much as I can in my own way to people coming here for the first time. I hope it is useful and helpful! I tried to assume low knowledge with the Fediverse in my responses which I collected here from a different post and assembled into a single article.
I apologize if something like this already exists and duplicating efforts. I don't mean to add to the flood of information unnecessarily.
Edit: Federation from kbin.social back to my instance is intermittent and I don't get all the replies and content so I apologize for the delays in responding!
If you want to make sure you're seeing the latest edits, please click the title of this thread to see it on the originating instance.
Question: How do I recreate the "subreddit" experience here? or What's a Magazine in kbin?
Magazines are the kbin equivalent of a subreddit. They have two large categories of content, "threads" and "microblogs". Microblogs are “posts” while threads are articles, links, and media posts. Threads are what you see on the “front page” with posts showing up in the microblogging part of a matching magazine.
Question: What are kbin "Threads" and "Microblogs?"
When you open up kbin.social or any other kbin instance at the moment, you'll be taken to the "front page" or main page which will show a list of "threads" with the following:
- Up and down vote arrows to the left
- A title, then maybe a description or some other body.
- Under each entry will be the person who added it, how long ago and which magazine it was added to.
- There will be a comment count, boost count, and the "more" button for each of these you see on the main page.
Those are "threads" and will have one of the following types:
- Article
- Link
- Photo
- Video
They will not be of type "post."
A kbin "Post" will show in the microblogs section.
I used the term microblogs because that's the menu item you have to select from inside a magazine to view "posts."
When selecting a magazine via the "Magazines" menu item at the top of the front page (or some other location where the magazine link takes you to the magazine page), it shows a new "top bar" that consists of the following:
[Site name] /m/[magazine name] Threads Microblog People Magazines.
By default, when you open a magazine page, it will have the "Threads" menu item selected. It will look similar to the front page in that it will have a list of "threads" with the up and down vote buttons to the left, a title, and some content underneath depending on the type: article, link, photo, video.
If you click the Microblog menu item, it will show a much different screen with an empty text box at the top with the built-in editor, a selection box to the bottom right with the current magazine selected already and some other options.
Below the text box you will see options for changing the ordering of the content below. The content below this box are all "posts" that either originated on this instance, or else were federated in from other platforms like Mastodon, Calckey, etc.
From a user's perspective, this is the difference between a "Thread" and "Microblog" and is a distinction I believe doesn't exist in Lemmy. (I don't actually know though, since I've never actually used Lemmy)
Under the hood, the different types - article, link, photo, video, and post - use different Activity Pub types to distinguish them. I don't know exactly for all of them, but I know kbin articles are federated as type "Page" while Mastodon, for example, sends out posts as type "Note." A "Note" is then treated as type "Post" by kbin and will not show up in the "threads" view (that's the view with the upvote and downvote buttons to the left, the nice title and content in the middle and comment counts). To view "posts", you must look at the Microblog link for the Magazine that the content was created in, or routed into if it is a new post from an outside platform.
Question: Why would I want to use a "Post" versus a "Thread?"
The why is a bit subjective so I'll try to lay out the more "concrete" differences between creating a thread (of which article is just one type) and a post.
Posts:
- Will federate to all your direct followers regardless of platform. If they are using a microblogging platform like Mastodon, this means it will show up in their home feeds just like any other post.
- Will not be seen on the "front page" by default since the default behavior is to have the "front page" show threads, not posts. A person can click the "Microblog" tab at the top to view all the posts instead, but that requires a click.
- Posts, unlike threads, will display the conversation without needing to click. You can compare by checking it out on kbin.social, but you'll notice that the threads on the front page will just have the opening title and a small description, but will not show the comments or replies to it. If you click on the microblogging tab, you'll see posts along with their replies automatically without need to click on them.
- Posts do not have subject lines. This means that typically on a platform like Mastodon, the post will show up without any content-warning masking the body.
- While threads are relatively widely supported on other platforms, posts are almost universal due to being a core part of the microblogging Fediverse.
- I don't know for sure, but I believe posts don't show up on Lemmy instances. Someone will have to correct me on that, though.
- Replying to the OP Post is more intuitive. To reply to a Post, you just have to click at the bottom of the OP's Post on the "reply" link. This is different in a Thread (if you're trying to reply to the OP and not a comment)
Threads:
- This will federate to your direct followers as well, but see below.
- Have a subject line and a body. This means on non-kbin/lemmy instances, it is likely that any content that is federated to them (Mastodon, etc) will show with a content warning and masked body.
- Will potentially show on the front page by default.
- Can show and embed media which can be displayed by default depending on an individual user's settings.
- Depending on the type, will federate in unexpected ways. Links, for example, that have a description can show on Mastodon without the description (I believe) and thus makes for unexpected behavior on non-kbin platforms.
- Threads will give you the option to add Badges to the content when you create it. I don't know when that will be fully implemented, but I suspect it will be a way for Magazine subscribers to "customize" the presentation of their thread depending on which badge(s) are applied.
- Replying to the OP's initial content can be more troublesome. For a thread that has a lot of comments on it, in order to add a comment, you have to scroll to the bottom of all comments (or all the comments on the first page of comments) to see the comment box. Replying to an existing comment on a thread is easy as the comment has a "reply" link at the bottom of the comment, but for a thread, the "add a comment" box is below all the current comments.
These are just the differences that I can think of off the top of my head. Also, if I'm wrong on any of these, I hope someone corrects me.
Question: What is the difference between an "up vote" and "boost?"
Boost is a feature of most Fediverse platforms including kbin, Mastodon, Calckey, Pixelfed, etc.
A boost is the Fediverse term for a “retweet”. What does that mean specifically?
It means that all of your followers will be sent the content you boost with the information that you “boosted” it. How this actually looks will depend on what platform your followers are using but on a microblogging platform like Mastodon or Calckey, the content/post will show up in their main timeline with other posts but with a small indication above it saying “so-and-so boosted this”.
Why is this different than an upvote?
Upvotes in kbin are what most other Fediverse platforms call “likes/favorites/stars/etc”. When you upvote something, to your followers, they typically do not know anything nor do they receive any notification. The post/content you upvote will typically not show in their home/main timeline and may not necessarily let them receive a copy of the content you’re upvoting.
It’s a bit of an oversimplification to say upvotes don’t share the content with your followers, but if you want to make sure your followers receive and can see the content, you want to boost it. That way they can see the content and also be shown new content that they might not otherwise have known about. They can also boost it again to have the content federate(be sent) to their followers as well. For sharing content widely across the Fediverse, boosting is the built-in tool for that.
You can upvote and boost the same content as well.
Added questions:
Question(s): What happens if you you follow a kbin user from Mastodon? Do you see just their "posts" or also their replies to threads? Do you see when they post an article? Can a kbin user follow a Mastodon user?
Yes to all of these. The author of any content on kbin is the user account, and thus following the kbin user account directly will federate all their content to their direct followers on other platforms. This applies to any content the user creates, but see notes above about some possibly weird behavior depending on the thread type.
A Kbin user can follow accounts across the Fediverse, too. There is no "home" feed for a Kbin user to look at all the accounts they follow across the Fediverse, but the incoming content can trigger notifications if configured to do so. Clicking on the notification will then show you which magazine the incoming post was routed to.
Question: How do hashtags interact between kbin and other Fediverse microblogging platforms(Calckey, Mastodon, etc)?
It depends on a few factors as best I can tell.
- If the content was created outside kbin and federated in from a non-kbin instance (Calckey, Mastodon, etc) the microblog post will be routed to a magazine. Magazines can be configured to “listen” for certain hashtags by the owner. If an incoming post has the hashtag, that post will be added to that magazine’s microblog section. If a magazine doesn’t match the hashtag, the post will be added to the magazine called “random” that each kbin instance has as a “catch-all” for incoming content that doesn’t fit elsewhere.
Note: There is still much I don’t know about the exact logic used to route these posts to magazines. “How does it decide where to add the post to when there are multiple hashtags which each match separate magazines?” for example.
- If the content is created on kbin and sent to followers from kbin, it behaves more or less like any other post with hashtags.
Question: What happens if you follow a kbin magazine from a different microblogging platform(Mastodon, Calckey, etc)
Actually from what I can tell, not much. Unlike gup.pe, or chirp social, magazine accounts don’t boost all the content that gets created in the Magazine. The magazine accounts always shows as zero posts and replies for me when viewing post counts from a microblogging platform (Calckey, Mastodon, etc). This means that new threads and posts to a magazine won't show up in your non-kbin home feed unless you happen to be following the individual user's account who created the content on kbin.
---
June 11 2023 17:00 GMT update
Question: How do I find and subscribe to Lemmy Communities?
I'll be the first to admit I don't know much about Lemmy. I've never used it so I've only picked up a few things here and there.
What I can say is that I don't have issues searching for and seeing communities on the lemmy instance beehaw.org. I just tested with a new community from beehaw.org and it showed up for me as expected.
I changed the leading ! into a @ in my testing above.
What I can speculate on is the following:
-
Lemmy has the ability to "allow-list" instances and restrict which instances are allowed to federate with it. If the lemmy instance in question has this enabled, I can guess that it wouldn't allow federation from kbin.social. This is speculation however.
-
Kbin doesn't support authorized fetch yet. It might not be at play here but I can't really tell.
-
If that community in question doesn't show up on that instance's list of communities, I suspect it is because that community is marked NSFW and hidden unless you are logged into that instance and have an account.
-
It might be a combination of these.
-
There might be customizations on certain Lemmy instances that might be understood by Lemmy, but not other platforms, but this is also speculation since I don't know.
Question: Why is there a "Post" type that behaves differently than "Threads"?
This is based on my exploration of the platform, not because I have any deep insight into the design.
Microblogs are where federated content from other non-kbin and non-lemmy platforms are displayed. I suspect this is because most of this is Mastodon/Calckey/Microblog content. It's the "Twitter-model" versus the Reddit model which is based around all content being a part of a subreddit. So much of this content isn't clearly geared towards a specific "magazine(subreddit)" and thus is routed into the "random" magazine unless it's routed elsewhere based on (hash)tags.
It would be like taking a raw stream of Twitter content and feeding it into reddit posts into the appropriate subreddits.
From what I understand, Lemmy takes the approach of just ignoring such incoming content that doesn't tag a lemmy community explicity. Kbin does decide to include such content and display it as "microblogs."
\\ Why does this apply to incoming content that does tag specific magazines? \\
I will say I'm not the developer so this is based on my exploring kbin and knowledge of other fediverse platforms.
I think this was a developer design and UI choice. When creating a thread on kbin, there is an expectation that the content will be "ranked" and the content will change its visibility to other users based on voting. Threads can "go viral" on kbin/lemmy without ever being boosted or even leaving that instance.
Gaining visibility of a microblog post on platforms like Mastodon and Calckey is very different. On other platforms, likes(upvotes on kbin) don't increase the visibility of a post. Boosting does. The more boosts content gets, the more people will potentially see it. It's why I suspect upvotes on kbin tried to match the microblog model initially with an upvote being a "boost" instead of a "like/favorite."
Even if someone tags a kbin magazine/lemmy community from Mastodon for example, it's still a "microblog" UI from Mastodon or Calckey, etc. Downvotes don't exist in the Activity Pub standard and a big part of the "kbin/lemmy/reddit" experience is the changing of visibility and reach of content based on upvotes. A post coming in from Mastodon could have a thousand upvotes, but the original poster's post will never show up in more places because of that.
I'm simplifying things a bit of course, but this is taking the example of all subscribers to a magazine interacting with the magazine from within kbin or lemmy only and there is externally sourced content tagging the magazine.
I apologize if I sound a bit rough or condescending. If I do, it's due to my lack of good editing skills, and not my intent at all.
I'm just a user like everyone else here, so I apologize for any errors and will correct any errors.
Thank you and I hope it helps answers some questions!