You haven’t created a bug, and you have it correct. If a Piefed user blocks a remote Piefed user, and that remote Piefed user attempts to reply to them in the UI this is what happens:

• UI shows reply button regardless of block status (no template check)
• Local routes check in_reply_to.author.has_blocked_user(current_user.id); fails if block known locally.
• User blocks are not federated by PieFed, so local instance often unaware
• If block unknown locally, reply is created and federated
• Remote instance (where block exists) rejects reply via create_post_reply check, may send Delete activity back
• Creates “ghost reply” scenario: appears locally but not on remote instance

Piefed has no means of federating blocks. In fact, they have some TODOs to actually implement federated blocks:

• No sending code: app/user/routes.py:811 has a TODO comment # federate block with placeholder ellipsis, and app/post/routes.py:1384 has a similar TODO.
• Only moderation bans are federated: app/shared/tasks/blocks.py:ban_person sends Block activities exclusively for site/community bans, not user‑to‑user blocks.
• Incoming blocks are handled: app/activitypub/routes.py:1520‑1526 processes incoming Mastodon‑style blocks (without a target field) and creates local UserBlock records, but there is no corresponding outgoing federation.

So as it stands now, Lemmy and PieFed experience the exact same thing. I guess Piefed users just don’t notice.

Added more context in separate reply with a link. But basically they’re saying it is a fine way to handle it, not adding comments if blocked on piefed but on lemmy, because it shows that you can’t reply on piefed.

So like most issues brought up brushed aside completely.

And now why I’m both curious and not curious to see if it actually does some of the user control stuff properly if a user is doing it on lemmy not piefed (the reputation/attitude thing where you get pushed by the system for not behaving properly)