Systems and frontend developer with a tendency for over-exertion. Often tired. Art enjoyer.
I’m better at communicating in person than online, so I may seem quiet here, language and cultural barriers aside.
Still trying to find my footing, too. Moved a bunch between very religious areas with zero LGBT visibility growing up, and that’s just no good at all.
Recently discovered cooking comes naturally to me. Mostly vegetarian.
Mostly SFW here.
🔞: @Qazm
🦋: @qazm.bsky.social [@bsky.brid.gy]
@scott@authorship.studio 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.
@foone@digipres.club That raises a question: Are portals subject to reaction forces? If not, a deflector would still be required and solid ‘fuel’ may be less usable.
@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.