-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How replies get bridged, and how opt in/out applies #894
Comments
In general, replies to normal fediverse posts don't get sent to Bluesky at all. Apart from opt in/out, if you reply to something on the fediverse, the bridge will only send that reply to Bluesky if one of these is true:
If you reply to a normal fediverse post, and none of those is true, the bridge won't send your reply to Bluesky at all. And yes, opt in vs opt out definitely still applies. If you haven't opted in, or you've opted out, the bridge won't send your reply to Bluesky even if any of the above are true. |
I think I didn't make it clear enough. In Mastodon, if follow someone and look at their post to see the replies, a request goes to the instance for the person who made the post and it returns an array of all the replies. I assume something similar must happen in bluesky to see all the replies to a post.
Does bluesky user B see the replies to fediverse user A's post, including fediverse user C who has not opted-in? It doesn't have to be the originator of the post who opted-in to the bridge. It can be any single account that replied. In Mastodon there is an API to get all the ancestors and descendents of that post in the conversation. That API returns all the posts and all the profiles of all the participants in the conversation -- all collected by the Instance of the one participant who has opted into the bridge. The bridge if it makes status context API requests needs to filter the array and check if each one has opted in or else filter it out before passing it to bluesky (thank you for starting a new issue for this! ) |
Ah, I may see the confusion. Bluesky works fundamentally differently from the fediverse. It only uses its own internal infrastructure and indices, specifically its AppView tier, to display posts and replies. When someone on Bluesky clicks through to a post bridged from the fediverse, Bluesky doesn't fetch the post and its replies from the bridge. It only shows the post and any replies that the bridge explicitly sent it. In this case specifically, the bridge wouldn't send C's reply at all, both because it's not replying to or @-mentioning a Bluesky user, and because C hasn't opted in. (Btw, the bridge doesn't use Mastodon's API at all. It uses ActivityPub, the federation protocol that all fediverse servers use to communicate with each other. That protocol also generally doesn't fetch posts or replies on demand, it only sends them proactively, ahead of time.) |
This may be a matter of terminology. I think the Mastodon APIs are their use of ActivityPub Here is what I was specifically referring to:
The thing that got me thinking about this is that I saw what I remember as a bluesky bridge doc or post on that site that was a justification of the bluesky bridge needing to use opt-out specifically because if it didn't, it wouldn't be able to show most replies to a post (because most wouldn't have opted in - so they need opt-out) |
@snarfed Sounds like bluesky (because of its centralized post stores) doesn't make the equivalent of Mastodon's fetching all the replies to a post from a single poster's instance. And your comment in your first reply about replies is reassuring. |
Thanks! Glad to hear it, and glad I was able to help. Thanks also for the link. Mastodon's API and ActivityPub are definitely different things - I'm very familiar with them, I've written lots of code that use both - but you're right, you were thinking specifically about the API, which Bridgy Fed doesn't use. |
From @bantryblues in #878 (comment) :
The text was updated successfully, but these errors were encountered: