Threads seems to be beginning to test ActivityPub federation, and since Kbin can be used for microblogging, this affects kbin.social. What are your thoughts on federating or defederating with them?

  • gnuplusmatt@reddthat.com
    6·
    11 months ago
    • They should pay the hosting costs of any server they pull data from
    • not run ads against the content that comes from other instances
    • Any changes they want in activity pub should be in the form of an MR on activitypub itself, and they must respect the protocol maintainers of the project if their MR is rejected. If they implement AP features outside of spec, they should be summarily defederated. We do not need another Jabber/XMPP vs Google situation
    • Any instance is free to federate/defederate with threads
    • Froyn@kbin.social
      4·
      11 months ago

      Wow, had not even thought of that.
      RIP to any server that federates with them and has to pay for the bandwidth they’re going to need to service Meta’s users.

    • atocci@kbin.social
      4·
      11 months ago

      That’s not really how ActivityPub works though, there’s no pulling. They wouldn’t be accessing kbin and downloading it’s data, it’s a push system. We would be pushing copies of our data out to Threads like we do now with all the other ActivityPub services. Threads would then distribute that data to it’s users with no extra work on kbin’s part. It would just be one more instance in addition to the thousands of instances already out there.

      People bring up the XMPP Google situation a lot also, but I think it’s a bad analogy for this. Google’s adoption of XMPP brought people into the protocol and Google abandoning it took those same people away. Those who were using it before Google could still use it after Google. Anybody who left XMPP to follow Google did it because XMPP failed to adapt to the features people wanted. Thats why we have Matrix now instead.