Should programming.dev defederate from Meta if they implement ActivityPub? - programming.dev
programming.dev
I’m not suggesting anything, just want to know what do you think. Here is a link if someone don’t know what Meta’s Threads is: https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/ [https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/]

I am not one for policies restricting choice but I fear the situation where Meta sets up instances that become big, say like Lemmy.world. Then one day when their instance is popular, they decide to charge other instances to federate with Meta’s instances.

Big corps like YouTube, twitter, Meta, etc are known to offer services at a loss to grow their service and then drop the hammer and demand payment to use what people already rely on.

I feel a policy that prevents federated corp instance from profiting early on from FOSS, self hosted, and volunteer federated servers is something to think about - though I do not know the best approach.

I like what Open Source software does with their licensing approach where you are free to view, use, and contribute but if you take you must distribute the source code to others. Some outright ban usage for profit without a license.

Obviously licensing applies well for software to prevent abuse, and I would like a discussion about what Terms of Use policies can prevent volunteer work from being abused - if any are desired.

see the following cross-post from: https://programming.dev/post/427323

Should programming.dev defederate from Meta if they implement ActivityPub?

I’m not suggesting anything, just want to know what do you think.

Here is a link if someone don’t know what Meta’s Threads is: https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/

  • LvxferreEnglish
    47·
    1 year ago

    In my opinion, “watch and see” is a good approach towards potentially hostile entities. Meta is not “potentially” hostile - it is a hostile entity already, due to its backstory of EEE (embrace, extend, extinguish), and it should be told to fuck off right off the bat. It will not contribute with the Fediverse in the long run.

    Their strategy is potentially along those lines:

    1. Create its own instance (let’s call it “Metadon”). Play by the rules at the start. Get a rather large userbase.
    2. Introduce policy, code, and monetary changes to Metadon; things that don’t piss off the users, but make it harder for admins of other instances, that’ll need to either play along or defederate Metadon. Over time smaller instances will bleed to death, with Metadon absorbing their userbases.
    3. Once Metadon controls a good chunk of the Fediverse, it pulls off the plug, because it’s now in a position to piss off the userbase to further Meta’s goals. “We’re going to defederate everyone else for protection of the users. Think on the children!” Then it starts reintegrating into Facebook and WhatsApp, including crap like “you need a Faecesbook account to use Metadon”.

    And we can’t really rely on “everyone doing the right thing”, because most people won’t. Cue to the users still using Reddit because they don’t care about things in the long run; it would be the same here, plenty users will use Metadon if it throws them a big enough of a bone.

    • NaibofTabr@infosec.pubEnglish
      25·
      1 year ago

      In my opinion, “watch and see” is a good approach towards potentially hostile entities. Meta is not “potentially” hostile - it is a hostile entity already,

      This is a very valid point. We don’t need to wait to see if Meta, the company that created tracking pixels, will behave as a good actor. They are already proven to be a bad actor and should be treated as such.

    • varsock@programming.devOPEnglish
      7·
      1 year ago

      agreed!

      And with Meta’s resources and reach, they could stand up a Lemmy.world equivalent easily. Play nice, break their arms jerking each off the Fediverse. And once enough of the instances are reliant on the Meta instance, cut off everyone who won’t pay to federate.