GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Qazm (qazm@tiggi.es)'s status on Wednesday, 14-Feb-2024 15:18:57 JST Qazm Qazm
    • L. Rhodes
    • Golda
    • shiri
    • Ryan Barrett

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

    In conversation Wednesday, 14-Feb-2024 15:18:57 JST from tiggi.es permalink
    • AP-AT-Bridge Group repeated this.
    • Embed this notice
      Qazm (qazm@tiggi.es)'s status on Wednesday, 14-Feb-2024 15:19:01 JST Qazm Qazm
      in reply to
      • L. Rhodes
      • Golda
      • shiri
      • Ryan Barrett

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

      In conversation Wednesday, 14-Feb-2024 15:19:01 JST permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.