this post was submitted on 06 Jul 2023
1355 points (94.4% liked)

Fediverse

28490 readers
641 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 2 years ago
MODERATORS
 

I just read this point in a comment and wanted to bring it to the spotlight.

Meta has practically unlimited resources. They will make access to the fediverse fast with their top tier servers.

As per my understanding this will make small instances less desirable to the common user. And the effects will be:

  1. Meta can and will unethically defedrate from instances which are a theat to them. Which the majority of the population won't care about, again making the small instances obsolete.
  2. When majority of the content is on the Meta servers they can and will provide fast access to it and unethically slow down access to the content from outside instances. This will be noticeable but cannot be proved, and in the end the common users just won't care. They will use Threads because its faster.

This is just what i could think of, there are many more ways to be evil. Meta has the best engineers in the world who will figure out more discrete and impactful ways to harm the small instances.

Privacy: I know they can scrape data from the fediverse right now. That's not a problem. The problem comes when they launch their own Android / iOS app and collect data about my search and what kind of Camel milk I like.

My thoughts: I think building our own userbase is better than federating with an evil corp. with unlimited resources and talent which they will use to destroy the federation just to get a few users.

I hope this post reaches the instance admins. The Cons outweigh the Pros in this case.

We couldn't get the people to use Signal. This is our chance to make a change.

you are viewing a single comment's thread
view the rest of the comments
[–] bighi@lemmy.world 1 points 1 year ago* (last edited 1 year ago) (1 children)

Not totally sure, but I don’t think that negotiating with Threads on anything at any point is a winning strategy. They’ll win every time. Kind of a ‘give them an inch they take a mile’ situation in my head.

Federating with them isn't "negotiating" in any way.

Any fear of Threads controlling the protocol is out of our hands, because the protocol isn't in the hands of the Mastodon devs, it's in the hands of W3C. So no matter what Mastodon instances do, it won't affect Threads and W3C.

At least by staying separate the user base will have to make a conscious decision about where they want to spend time instead of letting Meta dictate that for them in the future.

I think that by not federating with them, we're TAKING AWAY the option for people to make a decision, and forcing the worst possible choice on them. Imagine I want to follow a guy that is really popular on Threads. If Mastodon federates with them, I can decide to make an account on Mastodon and follow the guy from the safety of a network that it not governed by algorithms that promote hate, or I can decide to make a Threads account and follow them there. It's my choice.

But if Mastodon instances do NOT federate with Threads, the only way for me to follow that popular guy is by creating a Threads account and using the Threads app. By not federating, Mastodon removed my ability to choose and forced the worst possible option on me.

We should want MORE people using Mastodon, not fewer people. Let them follow Threads profiles from the safety of Mastodon.

[–] mayo@lemmy.world 1 points 1 year ago (1 children)

Allowing their platform access to the fediverse is giving them something they want in exchange for access to a larger user base for us. It's a form of trade or negotiation, however you want to look at it it's a choice to exchange something of value.

You're looking short term. The issue here is that Meta is going to be able to destroy the fediverse later, not right away.

[–] bighi@lemmy.world 1 points 1 year ago (1 children)

People have been repeating these fearmongering ideas, but with nothing concrete.

How is Threads going to destroy the fediverse if we make it easier for people to choose to come to Mastodon?

And how do you think that pushing people towards Threads is going to save the Fediverse?

And, like I said, if the entire protocol that the fediverse runs on is independent of Mastodon, how can Mastodon even stop it?

[–] mayo@lemmy.world 0 points 1 year ago (1 children)
[–] bighi@lemmy.world 1 points 1 year ago* (last edited 1 year ago) (1 children)

Yes. And it's also not clear how EEE is going to be applied here in this case.

EEE is easy to do when you're adopting something no one uses, like what happened with XMPP.

EEE is not easy to do with something that millions of people use. Look at emails, for example. Emails are still out there.

And let's stick to the example of emails. If every other email server decided to not work with GMail, then 99.99% of users would migrate to GMail and GMail would "win" so hard that emails would cease to exist outside of Google's control.

If you tell people that they can only interact with the hundreds of millions of people out there if they use the popular proprietary tool, they WILL choose the popular proprietary tool. Even if that proprietary tool push hate speech and bad news down their throats. And that's going to kill any chance Mastodon might have had.

[–] mayo@lemmy.world 1 points 1 year ago

That's true email is out there, but it's different because it's an protocol like TCP/UDP, HTTP. Federation is the same way, but the fediverse isn't and unlike SMTP the fediverse will be updated and changed frequently. I read another comment which made me think of this a little differently and now I'm maybe less against, more middle. Luckily we have a living experiment with Lemmy.ml and lemmy.world to see how this pans out.