A #PHP developer who, in his spare time, plays #Tabletop and #VideoGames; if the weathers nice I #Climb rocks, but mostly fall off of indoor #Bouldering ones.

Pronouns He/Him
Blog https://realmenweardress.es
Photos https://pixelfed.social/pieceofthepie
Keyoxide https://keyoxide.org/606B2E3C103A443663DA82716B37390F365AADAA

  • 1 Post
  • 19 Comments
Joined 10 months ago
cake
Cake day: August 23rd, 2023

help-circle








  • This is actually due to the way these platforms work. When a user comments on a comment or post on their instance it will be shown on their instance. It’s then sent on to the owning instance of that comment or post. That owning instance then forwards it on to all interested parties (magazine instance, commenters instance).

    Any instance in that chain can refuse to forward or broadcast that message due to a block, but the users own instance will likely always show that post. Ideally they would not do that and would be made aware of a block but that is a bit of a grey area in ActivityPub implementations.









  • Mmm. Looks like you’ve stumbled across (or at least highlighted) a bug in the way kbin federates out links in it’s content. I thought I’d covered the various cases but apparently didnt.

    When a post is made to kbin (or federated into it) that contains !magazineName@instance it does a best effort to make links that will work for users on that instance, but it appears that best effort applies to the outgoing federated content too - and it shouldnt, or at least, it should do something different.

    I’ll get a bug ticket in.

    EDIT. For now I’d recommend that where possible you use fully explict links i.e. [{@|!}community@instance](https://instance/{m|c}/community)