Notices by Qazm (qazm@tiggi.es)

@rysiek A small criticism on this point: Multiple Relays or AppViews doesn't mean separate networks. Relays connect to PDSs and that doesn't require authentication afaik, so if you run your own relay, you by default have the same content except where the PDS went down.

(Running an ATProto Relay is prohibitively expensive for most people and Bsky could at any time lock down their own PDSs though.)

@dansup Is it possible to filter activities by the author's profile info? Can filters prevent a user from becoming "known" to the instance (for the purpose of them appearing as search suggestion and such)?

@dansup Do you have documentation on the details of comment control yet? Is it only automatic-allow for specific groups or does it support an interactive mode where e.g. the comment can be submitted, but interactive approval is required (according to some filter)?

Something that I think would help *a lot* with connections to less moderated huge instances would be to set a first-comment(s) approval mode for them: If someone comments/replies from such an instance, those comments are collected and can be allowed/rejected by moderators in a view that shows their overall comment history. Plus a button to approve the commenter in general.
This could also be combined with a word/phrase filter to require manual approval, with the same option to exempt accounts.

I'm aware this would need a lot of UI, also to communicate that a made comment is 'pending approval' or something like that, but it could fix the 'whack a mole' problem of purely reactive moderation when connecting to large instances as a small instance.

@lanodan @larsfrommars KYM says it's from ネコとネコの終わらない夜, a three-page yuri oneshot.

@lanodan Hm… perhaps something to do with a denoising capacitor in the charger that's not disconnected from mains, but I'm no expert. Is this a charger with reversible plug?

@HistoPol @stux @latsss

I saw this late, but yes, if you block that domain, that only blocks and hides accounts and posts from there.

You'll still be able to see replies from users elsewhere made in response to posts on threads, and you'll also still see when someone else mentions threads users.

@scott I don't think so. Other Hubzilla or Friendica instances that receive a Hubzilla post over AP can still boost it over there, right?

The reply control from your instance won't stop Mastodon users from replying either (though it will stop you seeing those replies, and to some extent will reduce the visibility of replies).

I think it all comes down to what's outlined in https://foggyminds.com/display/c6ef095f-1165-ce77-d6de-73f618365846 (saw that post a little after my reply above) and open federated social media in general being built around own-access-choices rather than data control, outside of posting modes with very limited reach which *should* be implemented with more privacy than they are.

@scott In short, it's just like blocking one-by-one but as batch-action. Admins can also block domains using wildcards, I think.

However, either would not work to block specific software. You would indeed have to use an instance in limited federation mode, where each connection is checked one-by-one, to avoid federating with Friendica and Hubzilla instances that could copy your posts over to other protocols.

@lrhodes @gvelez17 @shiri @snarfed.org

If the bridge forgets about the block somehow, then the follow may be restored on the AT side if Eta's PDS pulls Delta's AT repository from the bridge to refresh/catch up after a disconnect and doesn't see the block, yes.

The bridge can probe whether Delta blocks Eta over AP at least if Delta's instance requires Authorized Fetch, so when possible, it should probably do that at a low frequency to keep its records straight.

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

@lrhodes @gvelez17 @shiri @snarfed.org

An interesting aspect of blocks on Bsky is that they're non-destructive, so they don't actually cut follow-relationships (but essentially fully suspend them) and are pretty reversible. I think that's an implementation detail though and neither AT nor AP really prescribe this one way or another.

Non-destructive blocks are a bit nicer with shared blocklists, since that means less "spiky" computing and that block lists can't do as much damage if they become unreliable.

@lrhodes @gvelez17 @shiri @snarfed.org Yeah.

Each PDS publishes its local users' block lists (and changes to that should be part of its outbound AT firehose), so the bridge can send blocks to Bsky. (edit: A PDS should also honour blocks when someone views a profile, which afaict bypasses some streaming aspects.) On the fedi side, it should notice them at least through authorised fetch, but there's probably some activity pushed for changes there too.

The main "issue" is that it's a push vs. pull and collation boundary, so the bridge must bookkeep this info locally and can't just translate volatile network requests on demand.

Edit: Well, that's single users blocks at least. Bsky's moderation lists can since recently also be subscribed to as blocklists. I assume that works similarly, but translating them across to AP would mean flattening them in an n*m operation.

@gvelez17 @lrhodes @shiri @snarfed.org I think it can work as long as the Bsky PDS is compliant with blocks, since blocks themselves can be bridged. The main difference is that third parties can see blocks too over there, iinm.

@thomasfuchs @gilhova IIrc it's because Mastodon didn't go with the AP format for replies (which would have had them listed by URI in the parent post and pushed updates to that proactively).

Not doing that saves some computation (Mastodon is heavy compared to other fediverse software), but indirectly leads to these and other UX problems unless compensated through less efficient means.

@kaia Pinterest has the most unhinged SEO. When they copy a photo, they'll literally take the entire page text too and paste it invisibly on their website if they can.