Let’s say a user wants to join a dedicated /kbin instance for audio fiction. There are a variety of magazines on that instance, by genre, title, new releases, etc. It’s a nifty theoretical instance. 😉

But this user wants to do more than just interact with the magazines and people on that instance. They want to use their account on this /kbin instance to follow accounts not on that server. So maybe @fraser@m.universetoday.com because they are quite interested in Astronomy, @effinbirds@mastodon.social because they like funny birds talking shit, and @ernest@kbin.social because they are interested in learning more about /kbin. Again, they want to follow all three of those accounts with the account they made on this not-so-mythical audio fiction-centetric /kbin server.

Can they? How do they search for, find, and follow those accounts because those accounts are not (yet, at least) “connected” to the unnamed (it’s hotaudiofiction.social) /kbin instance?

And if they can, how would they see the posts from those un-connected accounts? Like, where is the “timeline” view in /kbin?

  • evoterra@kbin.socialOP
    1·
    11 months ago

    @QuinceDaPence

    Using https://hotaudiofiction.social/u/@[email protected] (when logged into said instance) throws a 404 for me.

    HOWEVER… using https://kbin.social/u/@[email protected] when I’m logged into that instance does not.

    Which is good news. I mean, bad news that we have a misconfig or something not setup correctly (yet), but good that it works! Off to figure out why not. And, hopefully, figure out what sort of timeline we have here on /kbin!

    • Pamasich@kbin.social
      1·
      11 months ago

      Using https://hotaudiofiction.social/u/@[email protected] (when logged into said instance) throws a 404 for me.

      It works now, and I believe that’s general fediverse behavior.

      From what I’ve read, it’s normal that a first attempt at accessing a user or magazine from a not-yet-federated instance WILL fail. But your instance will start federating then, and subsequent attempts are most likely going to succeed (as this one did for me).

      I don’t know though if this behavior (instance starts federating after failed access) happens when accessing the url directly too, or if it’s specifically built into the search (the magnifying glass in the top right).

      So no, it’s not a configuration error I think.