Notices by AP-AT-Bridge Group (activitypubblueskybridge@venera.social), page 4

@jamie @snarfed.org @activitypubblueskybridge
I am not against the people of Threads or BlueSky my opinion is the management of relationships between these two very different worlds, a world of enormous capital based on profit thanks to advertisements and a free and voluntary world which seeks tranquility
1/2

@tness16
@snarfed.org @activitypubblueskybridge

Assuming the big door in this context is to join an ActivityPub server, I know several people who came here when Twitter blew up and weren't warmly welcomed. Lots of people telling them they were doing it wrong, etc. So, they left and went to places like Threads or BlueSky. This is giving them a chance to be on their instance of choice (BlueSky) and still follow their friends who did stay on ActivityPub.

@snarfed.org @activitypubblueskybridge @fedidevs @fediversenews

You have this totally the wrong way round and are not respecting user privacy. If you're making big changes like this the default should be opted out, not opted in with a choice to opt out.
Don't be a dick like Facebook et.al do the right thing from the start.

Also we Europeans have stronger data protection laws and I suspect you're breaking them.

#respectuserprivacy
#GDPR

@Curator @snarfed.org

You may want to reconsider your "Fuck off" comment while on mastodon.art:

https://mastodon.art/about/more#code-of-conduct

@petrescatraian techbros understand consent challenge (impossible)

@snarfed.org @activitypubblueskybridge @fedidevs @fediversenews
@javido ¿ Nosotros aquí en tiflo como quedamos con esto?

@lrhodes @gvelez17 @shiri @snarfed.org

The bridge can't really filter in this direction, since afaik AT firehose subscriptions and repository fetch are anonymous(-ish). Rather, it's Eta's PDS (and optionally feed algorithms on the way, but only as optimisation) that enforces the bridged block. Delta's instance should also stop sending posts to the bridge, as AP does not use a firehose, but only if there are no other (not-blocked) bridged Bsky followers.

A meaningful desync happens only when the block is rescinded: The bridge may have to automatically re-follow Delta as Eta to restore consistency, since I don't think you can 'remove a follower' on AT.

What happens with a follow in the other direction depends on whether there are separate block and unfollow activities generated by Mastodon. If yes, then no desync happens and Delta('s software) can choose whether they still follow Eta after the block is gone. If blocking does imply unfollowing in AP, then the bridge would have to translate AP blocks into AT block-and-unfollow.
Delta would then not follow Eta after the block is gone, unless Delta('s instance) re-follows Eta explicitly.

Maybe there's some inconsistency detection and cleanup scheme built into one or both of the protocols, too, in which case the bridge should make use of that where possible. I'm not aware of such a mechanism, though.

@dsalo

+1

@hazelnot @snarfed.org reporting you to your server admins for violating rule 7 on your server...

Bridges are a dime a dozen (literally there are so many out there already and this is open source so good luck de-federating them all without just joining a whitelist server), the fediverse doesn't work the way you think it does, bridges probably don't work the way you think they do, and dogpiling on someone for sharing their project for feedback, especially for offering a polite feature to exclude yourself from the bridge which no other bridge I've seen offers just makes it clear you're an asshole.

@baralheia @snarfed.org that's pretty much already native with how a bridge works.

When a Bluesky user goes to follow you, you'll get a follow request from that user:instance@bridge (or similiar format username).

A lot of the confusion and freak out comes from people (a) not knowing how bridges work and (b) taking vague offense because they don't like Bluesky and think that the whole fediverse should conform to their personal standards

@snarfed.org @activitypubblueskybridge @fedidevs @fediversenews honestly, we probably need another project like #fedipact to track things like this. I don't want to keep an eye out for every scraper/indexer/bridge project, I just want to pick an instance where my admins defed and opt everyone out. As a bonus, this would place pressure on projects to be opt-in only, so they don't get blocked on sight by whole communities.

@snarfed.org

Opt-in only, or I #DomainBlock

What is that again?

bsky.brid.gy?

So noted...

I want *nothing* to do with #Bluesky

#NoBridge has been added to my profile

cc @activitypubblueskybridge @fedidevs @fediversenews@venera.social

@blake
Where have we signed up for the bluesky TOS?

What gives this guy the right to copy our content we make for the fediverse available on a commercial network?

No one has consented for this.

Bridges need to be opt in.

@fediversenews @fedidevs @activitypubblueskybridge @snarfed.org @snarfed

@warteschleife I'm still on the fence about this, but if Bluesky suddenly becomes partly dependent on Mastodon content, it may well force moderation … or I guess they'd be defederated. @sam @zatnosk @snarfed.org @activitypubblueskybridge @fedidevs @fediversenews

@the_roamer @zatnosk @snarfed.org @activitypubblueskybridge @fedidevs @fediversenews Undecided on this but we had bridges / gateways to a lot of federated networks on the usenet and users did not consider this a problem with consent in principle. You don’t have to use it and your instance can block it.
However, blueky could easily become one of the too big to block instances on the fediverse, but with a different culture concerning moderation (and archiving), and that may become a problem.

@SuperMoosie @byjp @zatnosk

Considering each instance can have its own terms of service, this is a legal space that is largely untested currently. My thoughts are that the legality will boil down to "follow each instance terms", but it's an amazingly complex thing even there. And I say this even as an instance owner who thinks that bridgy should be explicitly opt-in either per-post, per-user, or per-instance.

Per-instance, to me, kind of makes the MOST sense for having an 'opt-out' tag in the bio -- each instance owner is then making their own users aware of the policy and can give them advance notice if they don't wish to be included. Just having a global "we can have your information even if you're unaware of it" policy is half the problem of the current tech industry snarfing up damn everything as if it's theirs to use, causing all the LLM garbage issues today.

Hell, the fact I'd have to end my wifi SSID in _at least_ two weird tag things, and one of them MUST be the last one, to avoid my wifi SSID, BSSID, and location getting snarfed by mapping cars (google, MS, etc) is just part of this. I have to take up limited characters in my bio for each service I want no part in? I have to make my SSID ugly just so a corp won't use info I didn't consent to them using? While I like the idea of being able to follow friends of mine who are on AT instead of fedi, and refuse to use fedi, it's not worth it being so open; I always figured there would be an opt-in mechanism, not yet more opt-out stuff.

C'mon like, haven't we seen how many times people offering only opt-out are shown the distaste for this? =/ 'bridge' or not, it's still technically a specialized service, it's not transparent just because things are duplicated both ways.

@eishiya @byjp you should know that Bluesky, once they start federating (which this is directly related to)... is the fediverse as well.

Please do not confuse Mastodon/ActivityPub with the whole fediverse. The fediverse is a wide array of servers and there are many bridges between different protocols out there already.

And on the topic of consent, this is a purely public system. Consent within the fediverse is opt out, when you post publically you are automatically consenting to anyone receiving and transmitting your post however they wish. If you do not wish to provide that consent, you make your post private.

Bridges are a natural part of federation and are key to it's survival as it makes all relevant platforms less likely to collapse.