The current behavior (I’m using the web client) as it is displays self-post as (kbin.social) under the thread title. Not sure if it is the result of a fallback behavior.
On mobile it gets really awkward because the URL address bar would truncate to the domain + TLD (the full URL is only down once the user double press the address bar which makes it cumbersome and adds an extra layer of step) and for certain topics such as metatalk the user viewing the thread would have a higher chance of confounding it kbin metatalk instead of maybe lemmy.world meta talk, etc.
it should be where the magazine is from, not where the user is from.
While I’m not entirely sure about why things are set up the way they are, I guess that it was done on purpose seeing your response. Now, if explaining the why’s and how’s of this design is too much of a sensitive topic, I’m okay with dropping my questions and just going along with the ride 👍.
If it’s possible as a compromise, how about consider displaying both “the origin of the magazine” (instance) and the “name of the magazine”, rather than the existing format where kbin.social appears after the title, followed by just the “name of the magazine” (omitting the original instance from which it hails).
For example, the current layout is:
TITLE(kbin.social)
PREVIEW OF BODY TEXTUSER, 33 minutes ago toNAME_OF_MAGAZINE_WITHOUT_ORIGINAL_INSTANCE(likemeta)My suggestion is to include an option for displaying it like this (I do understand that it might be a clutter to some, but it would be a nice feature for others facing the same qualms as I do):
TITLE(kbin.social)
PREVIEW OF BODY TEXTUSER, 33 minutes ago toNAME_OF_MAGAZINE_WITH_ORIGINAL_INSTANCE(like META@LEMMY.ML)To provide some context, I came across a post on either
mainormetaon the front page. It hadkbin.sociallisted below the title along with the “name of the magazine,” but the original instance name was missing. I was about to express my confusion since it didn’t align with my experience on kbin.social, but upon double-checking the URL, I realized the post was not related to kbin.social at all. This “issue” generated by the behavior seems to mainly affect mags likemainandmetaposts, but considering these posts do often appear on the front page (since I’ve enabled other instances todiscovermore exciting content), I think that it’s issue worth exploring.Hopefully in the meantime, I’ve figured better ways to work around this issue (to verify the instance of the magazine) on mobile ( apart from checking the address bar), which are to