Dear @Gargron,

Please reevaluate your decision to incentivise centralisation on mastodon.social in the official app.

This is the sort of design a VC-funded startup would implement, not a non-profit acting in the interests of a healthy commons.

I’m sure you don’t want mastodon.social to become mini-Twitter and you don’t want to become mini-Musk.

That’s not how we win this.

More instances, not larger instances is the key.

https://mastodon.ar.al/@feditips@mstdn.social/110233282943673558

#decentralisation #fediverse #staySmall

Fedi.Tips (@[email protected])

Attached: 1 image The official Mastodon app is doing something new which is potentially very dangerous to the existence of Mastodon and the Fediverse. The official Mastodon app now prompts users to join mastodon.social by default, when previously it prompted them to pick a server. If you're new this may sound harmless, but let me explain. The entire point of this place is to be a social network spread out on as many servers as possible (the reasons are here: https://fedi.tips/why-is-the-fediverse-on-so-many-separate-servers/). (1/6)

Mastodon 🐘

@aral @Gargron Actually, when combining this decision with the recent trademark one of not allowing other instances to be named *.mastodon.* there might be a case for questioning Gargron's motives here.

... but I think this is the right move to enable frictionless signups. However, it's now critically important to implement the one-click _complete_ account migration between servers as well.

Basically mastodon.social needs to encourage users to move on from spawn.

#Mastodon

@troed
@aral @Gargron
Mastodon is also missing the ability to migrate the post, reply, boost history. Also it cannot migrate accounts from instances that are dead or disabled migration.
This creates user lock-in and therefore centralization.
@federico3 @troed @aral @Gargron Though to be fair here, there are technical limitations. From what I understand, migrating posts/boosts would put a lot of demand on servers especially if you have few folks migrating at once - as those messages end up being rebroadcast again all at once, notifications come through etc - not to mention trying to replace the replies in threads of past conversations. (1/2)

@federico3 @troed @[email protected] @Gargron Dead instances are always going to be a risk, without some kind of duplication and a way of proving you owned the account on the dead instance (possibly a good ol' key pair but would add complexity for new users).

The code is open source - anyone that wants to disable migration will be able to do that, not much we can really do on that front. (2/2)

But I'm not disagreeing with you, migrating post history would be ideal.*

*Possible? https://social.luca.run/@luca/109559157272902502

Luca 🔨 (@[email protected])

I'm playing with the idea of importing my Tweets archive to my #Mastodon instance (not here, on my personal server) but don't want to spam other instances. I found https://github.com/wb14123/twitter2mastodon from two years ago. It uses the API to create the post and then edits creation and update timestamps in the database. I wonder if it would be enough to cut the connection to the internet during import. Is that correct or would backdated posts get federated?

social.luca.run
@BenjaminNelan @troed @aral @Gargron If "live mirroring" was part of the protocol it would be reasonable to require it be enabled on an instance in order to join the federation.

@federico3 @troed @aral @Gargron Though a change like that to the protocol could be seen as a forceful takeover by other fediverse platforms.

So it probably can't be a requirement of federation, maybe of the server covenant and optional for others. Basically an opt in to cache more content than is typically covered and in some cases involves backfill of earlier posts, which is currently still an open issue on the github page.