snarfed
Local reply to bridged account should also be bridged
When you reply to someone on your network, and the in-reply-to post was bridged into another network, your reply should be too. This was already supposed to be working, but looks like it regressed or never quite landed, and evidently we don't have a good enough test for it. Should hopefully be an easy fix. Thanks Laurens!
Solid start on this in the in-reply-to-bridged branch, but there's more to do.
Maybe a part of this and I'm sure you're aware, but I think sometimes posts in-reply-to a bridged post doesn't get bridged only because the post it's in reply to maybe hasn't been bridged yet. If someone is writing a thread with each response in quick succession, it feels like this check might happen before the send task has been performed?
I 2024-05-18 16:31:55.486436+00:00 It's a reply... I 2024-05-18 16:31:55.486571+00:00 ...skipping, in-reply-to post(s) are same protocol and weren't bridged anywhere
Examples: Post 3 in a thread, bridged. Post 4 in a thread, not bridged.
I may be hitting something similar: https://fed.brid.gy/bsky/tamschi.bsky.social The events seem to be arriving at the bridge out of order and sometimes multiple times.
Screenshot (bright)
The lines kept reordering themselves when I refreshed for a while. In this case, it settled on a state where boosts appear below the replies they're of.
@hybridhavoc interesting! Thanks for reporting, that's definitely possible, will look.
@Tamschi true! That's https://github.com/snarfed/bridgy-fed/issues/1012. Apologies, you're definitely right that that's a bit confusing. We currently retry on failure a few times, and sometimes backfill missing windows of events. It takes a surprising amount of work to guarantee in-order or exactly-once processing in a distributed system, and ActivityPub itself doesn't require or expect it, so it's not a high priority for us right now.
I'm running into situations where I (on Mastodon) am only seeing the first post of a thread by someone on Bluesky, and I'd like to figure out if it's this issue.
How fast is "in quick succession"? For this thread by a Bluesky account opted into the bridge, I see a six minute difference between posts 1 and 2, but my Mastodon server still only received the first post.
Thanks for investigating! I wouldn't worry too much about the timing theory here though. I know this isn't working, it seems pretty easily reproducible, and I expect I can fix it without worrying about timing.
I think this ^ did the trick! Example native reply that got bridged: https://bsky.app/profile/snarfed.indieweb.social.ap.brid.gy/post/3kvrrf5isxp62
This fix will work for self replies (ie threads), but not necessarily for replies to other people. Afaik if you reply to someone natively on the fediverse, your instance delivers that reply to them, but not to your followers. So, BF will never see your reply, so it can't bridge it into Bluesky. I guess that's one for the docs.
Thanks for fixing this issue! 🙂
Afaik if you reply to someone natively on the fediverse, your instance delivers that reply to them, but not to your followers. So, BF will never see your reply, so it can't bridge it into Bluesky. I guess that's one for the docs.
I don't believe this is accurate. At the very least on Mastodon, non-private replies you post are delivered to all your followers regardless, it is just the home feed that typically doesn't display them. If I click someone's profile on my single-user Mastodon server and navigate to the "Posts and replies" tab, I see all their replies including to people I don't follow.
I think this ^ did the trick! Example native reply that got bridged: https://bsky.app/profile/snarfed.indieweb.social.ap.brid.gy/post/3kvrrf5isxp62
This fix will work for self replies (ie threads), but not necessarily for replies to other people. Afaik if you reply to someone natively on the fediverse, your instance delivers that reply to them, but not to your followers. So, BF will never see your reply, so it can't bridge it into Bluesky. I guess that's one for the docs.
Huh, threads always worked for me, even before that patch. IG bridging native fediverse reply from other people is not possible
https://bsky.app/profile/AmyIsCoolz.social.atiusamy.com.ap.brid.gy/post/3kto3owetrwf2
Here's a post from quite a long while back (There are more like this on my profile)
Thanks for fixing this issue! 🙂
Afaik if you reply to someone natively on the fediverse, your instance delivers that reply to them, but not to your followers. So, BF will never see your reply, so it can't bridge it into Bluesky. I guess that's one for the docs.
I don't believe this is accurate. At the very least on Mastodon, non-private replies you post are delivered to all your followers regardless, it is just the home feed that typically doesn't display them. If I click someone's profile on my single-user Mastodon server and navigate to the "Posts and replies" tab, I see all their replies including to people I don't follow.
I believe this is also the case on *key and maybe possible Pleroma/Akkoma too
Hah, I had a whole comment drafted on this, since I'd posted a test reply from Mastodon and BF hadn't received an AP inbox delivery of it, but I checked one more time and the inbox delivery showed up, just delayed a bit.
(Specifically this native fediverse reply, which eventually did get bridged to Bluesky.)
AS2 audience targeting + AP inbox delivery is complicated, and I'll never claim to fully understand it, but it sounds like Mastodon and others are probably more promiscuous in delivering replies to followers than strictly necessary. Which is probably good! The fediverse has enough of a missing reply problem, so that (along with inbox forwarding) hopefully helps minimize it.
I assume this is the same issue: https://tomkahe.com/@tom/112685499859422147 (https://bsky.app/profile/tom.tomkahe.com.ap.brid.gy/post/3kvufefrk2kl2) AP Post (Bridged) -> AP Reply (Bridged) -> AP Reply (Not Bridged) -> AP Reply (Not bridged)
It looks like both of us are running Mastodon (or mastodon fork) and all replies are marked as public
Ooh, interesting race condition! Thanks for reporting. Reopening, will fix.
So the first missing reply here, https://social.wake.st/@liaizon/112685458249358226 , got delivered to us first as an inbox forward by tom.tomkahe.com. An inbox forwarded activity can't include an HTTP sig from its actual author - in this case, https://social.wake.st/@liaizon - because the forwarding instance doesn't have the author's private key. In this case, Mastodon includes an LD Signature) (more background) from the original author, which works, but it's niche and not well supported, and difficult for other projects like Bridgy Fed to verify. I put some effort into trying (https://github.com/snarfed/bridgy-fed/issues/566#issuecomment-1936399383), but even with talking to a Mastodon dev, I was never able to figure out their JSON canonicalization.
Anyway. The race condition is that we got the inbox forward, dropped it, but still recorded that we'd already processed it, so when we then got the real delivery from social.wake.st, we didn't try to process it again. Should be an easy fix.
Just for my understanding, this issue should cover any bridging direction, right? Because the problem I'm seeing, where I follow a Bluesky profile from my Mastodon server and when they post a thread I only receive the first post, is also still happening as of earlier today.
@jfietkau https://github.com/snarfed/bridgy-fed/issues/1047#issuecomment-2195287066 is specific to replies originating in the fediverse. Looks like yours is different. I think I see it, thanks for reporting!
Let me know if you need a separate GitHub issue for it or more examples or anything else. 🙂
OK! @TomCasavant @jfietkau I think both of these bugs are now fixed. Example Bluesky thread that got bridged successfully: https://bsky.app/profile/snarfed.bsky.social/post/3kvwobprmfj2c => https://indieweb.social/@[email protected]/112690494457527329
Thanks again for reporting, I really do appreciate it!
Note to myself, re b87b4aa, the narrower fix would have been to add all non-HAS_COPIES bridged protocols for the author here:
https://github.com/snarfed/bridgy-fed/blob/a619a4156a094d388d932f21eca29188f5897ea9/protocol.py#L1287