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

  • 2 Posts
  • 50 Comments
Joined 1 year ago
cake
Cake day: June 3rd, 2023

help-circle
  • @azezeB Some suggestions

    1. Dead By Daylight. 5 people with one being the Killer so you can rotate that if desired.
    2. Halo Infinite multiplayer can do 12 person parties for the “Big” map modes.
    3. I believe Lego Fortnite also lets you have up to 8. It’s more Minecraft and not a Battle Royale at all.
    4. Lethal company modded can support more than 4. That could be lots of fun.
    5. Retro FPS like Quake from various years. Just as a small distraction

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


  • @ReverseModule

    As someone who really enjoys PeerTube, I also feel like the technical barriers to it being as popular as other platforms are a bit tougher to overcome.

    I would love for it to be more popular. I also know it’s really hard to convince content creators and live streamers to embrace it.

    I love PeerTube. I have been trying to help the projects however I can. I also know that the economics of moving to PeerTube is quite different. Very few people make money microblogging (Twitter). Very few people make money posting to Reddit.

    Streaming on Twitch or YouTube, or making content for YouTube can and for many people does bring in money, though. Creating an ecosystem where viewers are willing to pay, while increasing viewer counts of content so that sponsorships can be more common, all while trying to slowly convince people that we should be supporting things financially that up to now has been “free(not really, but experientially it ‘feels’ free)” is a lot of work.

    I plan on supporting PeerTube as much as I can in the future. I want it to grow. Maybe someday, it will get there. I can hope.





  • @McBinary

    I run a personal Pixelfed instance as well as a kbin one. I think the “easiest” or most sustainable would be if there was a pixelfed instance also stood up at the same time a new kbin instance is started which had some kind of SSO for the kbin and pixelfed instance.

    The challenges I see with this:

    1. Media storage space for a place like Kbin.social could grow pretty fast, especially if people really started uploading videos.
    2. Bandwidth concerns may or may not be an issue, but certainly would need to be carefully considered.
    3. Moderating the pixelfed side could be a lot of work, especially if people start only using the pixelfed site and not posting anything to kbin. It becomes like Imgur and moderating images, especially when people are uploading non-OC constantly, adds greatly to the work-load.

    I’ve done a little testing to see how embedding/linking to images on a pixelfed instance would work (without any special integration) and it works.




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



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