@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.

@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.

@wahming

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.

@wahming

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"
        }
    }
}

@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.

@RainbowsAre they protected by any kind of bot protections? If so that could interfere.

@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)

@Brome

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?”

@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.”

@Brome

If your Calckey instance has Authorized Fetch/Secure Fetch enabled, this might prevent pulling, but I haven’t tested that exact scenario yet.

@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.

@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.

@Noki

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

@Valhaitham

@Valhaitham

I just searched for your magazine from fedia and it showed up right away.

I used @ magazine @kbin.social (no spaces) in the main site search box.

The same for Calckey.
Make sure you add the leading @ before the magazine name and domain.

@V699

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

https://kbin.social/m/kbinDesign/p/321387/why-the-choice-to-call-the-groups-magazines#post-comment-558994

@Jerry

I see a lot of magazines on your instance now.

@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.

@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
I think the most responsible way would be to expand object storage support beyond the current AWS-hosted S3 storage to support the different hosting services who offer compatible storage. There is already an issue for it and I hope it gets added relatively soon officially. (There is a patch that does seem to add it)

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