We really shouldn’t take this Meta thing lightly.

They could offer the slickest interface and keep people locked to their friends. That interface can use protocols that make it difficult/impossible for non-Threads instances to play ball (ooh this cool new feature is only available through the Threads app; Oh, mybasement.world.ml.xyz can’t read that content). There are many ways to Embrace, Extend, and Extinguish, we’ve seen Meta do it before (e.g. XMPP), and I’m sure we haven’t even thought of some ways Threads could EEE.

I think defederation from Meta’s instances is probably our only option to protect what we have.

  • In #Flancia we'll meet@social.coop
    2·
    1 year ago

    @CrazyDuck

    1. Developers in the chat space in G had decided to implement their own protocol for Hangouts, the “next generation” chat app. The consensus seemed to be that going with an in-house protocol would provide enough extra freedom to allow G to implement and ship features faster (whereas innovation on top of XMPP was deemed relatively hard).
    • In #Flancia we'll meet@social.coop
      2·
      1 year ago

      @CrazyDuck

      1. XMPP was, back then, considered unfit for the transition to mobile as it was a very ‘chatty’ protocol and that kills battery on mobile devices. I’ve heard this has been solved/worked around since? But I haven’t looked into how this was achieved, if at all, and whether we could have taken that route instead back then.
      • In #Flancia we'll meet@social.coop
        1·
        1 year ago

        @CrazyDuck of course moving to a proprietary protocol doesn’t mean that federation must die. Indeed we kept federation alive for users for a while by bridging gTalk (legacy, still supporting federation) and Hangouts (proprietary). It was the dream of at least a few (myself included) to open up the Hangouts API and/or build federation on top of it, but it was not prioritized – I take part of the responsibility for that, even if I was just an individual contributor: I could have done it as a 20%.