Skip to content
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

Closed
snarfed opened this issue Feb 21, 2024 · 6 comments
Closed

How replies get bridged, and how opt in/out applies #894

snarfed opened this issue Feb 21, 2024 · 6 comments

Comments

@snarfed
Copy link
Owner

snarfed commented Feb 21, 2024

From @bantryblues in #878 (comment) :

Will the bluesky bridge examine each fediverse reply to a fediverse post before sending all those replies to bluesky?

Suppose:

1. fediverse account A opts-in and is followed by bluesky account B

2. 100 fediverse accounts reply to a post from account A

3. account B at bluesky asks to see the replies to a post on the fediverse account they follow

Will the bluesky bridge check all 100 replies and only send replies from accounts who have opted-in?

That is an issue that was used as justification for needing opt-out -- is the plan to send requests for each reply and only send on the ones the bridge already has opt-in for?

IMPORTANT POINT ABOUT BLOCKING BRIDGE DOMAIN Blocking the bridge domain doesn't prevent the bridge from getting replies from people who have not opted-in. - it will get all the replies and will need to filter out the ones it doesn't have permission to send

@snarfed
Copy link
Owner Author

snarfed commented Feb 21, 2024

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:

  • You're replying to a bridged Bluesky user's post
  • Your reply @-mentions a bridged Bluesky user
  • You're replying to your own post, and at least one person on Bluesky follows you via the bridge

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.

@bantryblues
Copy link

bantryblues commented Feb 21, 2024

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.

  1. fediverse user A opts-in to the bluesky bridge
  2. bluesky user B follows fediverse user A (by using the bluesky bridge)
  3. fediverse user A makes a post in the fediverse
  4. fediverse user C replies to fediverse user A's post (fediverse user C has NOT opted in to the bluesky bridge
  5. bluesky user B sees fediverse user A's post (because they follow A).
  6. bluesky user B does whatever they do to see the post and replies to the post

Does bluesky user B see the replies to fediverse user A's post, including fediverse user C who has not opted-in?
(this isn't one of the cases you listed above)

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! )

@snarfed
Copy link
Owner Author

snarfed commented Feb 21, 2024

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.)

@bantryblues
Copy link

bantryblues commented Feb 21, 2024

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:
https:///docs.joinmastodon.org/methods/statuses/#context

/example.com/api/v1/statuses/[post id]/context

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)

@bantryblues
Copy link

bantryblues commented Feb 21, 2024

@snarfed
I think this issue should be closed.

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.

@snarfed
Copy link
Owner Author

snarfed commented Feb 21, 2024

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.

@snarfed snarfed closed this as completed Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants