Hacker News Reader

Comment by HankB99 | Hacker News Reader

Ash: I'm sorry to hear about the health issue that precipitated this. I wish you the best outcome but realize that that does not always happen.

Rest: As someone who does not (yet) use Mastodon, I'm curious about the impact of a single node shutting down. At least in this case this is happening in an orderly manner and with warning.

I'm also curious if this is a problem with Mastodon in general or did this particular node just become too popular for its own good. I seem to recall that some instances (Adam Curry's No Agenda related instance) limiting membership. Or perhaps I'm thinking of something else. But that may not help if the problem is traffic generated by the entire network as seems to be hinted at in the post.

Please excuse my ignorance of how Mastodon operates that may be implicit in my questions.

View on HN

Mastodon has a migration path for users to move to other instances. So when the server admins allow it (i.e. don't just shutdown, or kick someone off) moving is rather easy.

Today, several in my mastodon timeline mentioned they finished the move. But without them mentioning, I, an outstander (i'm on another instance) wouldn't notice it.

What will happen, though, is that a portion of the users won't migrate. Either because they forget, or they can't be bothered, are "zombie accounts", or because its too challenging: it does involve down- and uploading and/or copypasting zips/datafiles. This means a bit of pruning or culling, and that could be considered good, IDK.

What will also happen, on a more technical level, is that other instances and maybe bots and automation will hit timeouts and connection errors when it really shuts down. Most instances and fediverse software can handle this just fine, it's built with this mind; it might at most cause some overhead and load. Some flakey or poorly developed software might crash or break (for a moment).

> Today, several in my mastodon timeline mentioned they finished the move. But without them mentioning, I, an outstander (i'm on another instance) wouldn't notice it.

Do you mean that part of the protocol allows for a migration process that includes changing who your follows are pointing at? (assuming all servers involved are up to date and have this feature) I.e. did your account automatically start following your friends' new accounts?

Yes. The process has three steps: First, you update the receiving profile to "allow" the move by pointing at each other using the as:alsoKnownAs relationship. This allows everybody to confirm that the receiving account is participating in the move, and authorizes it. Then, you update your old account with the "movedTo" property, so that any new users who look up your account will see a notification that you've moved. Finally, you send out a Move activity to all of your followers, pointing at the new account. Automatically, all of your old followers who receive the Move activity will send Follow activities to the new "receiving" profile.

This process doesn't update any of the old content from your account, which was regarded at the time as a necessary simplification because of the issues of updating canonical URIs for accounts on one system to accounts on another system (different software might have different expected routes, you might need to store lookup tables, etc etc. It just opens up a huge can of worms). In practice this doesn't really matter that much since Mastodon is used primarily for microblogging and less for, well, actual blogging. If you were designing a more fully-featured social blogging platform like a Medium or Tumblr equivalent you'd probably want to put some more thought into that side of things.

If it doesn't update the old content on your old account, then is there a way to copy the old content to your new account?

I imagine that is what ggg-parent meant by: "it does involve down- and uploading and/or copypasting zips/datafiles."

Indeed.

Though it also involves migrating blocklist, followers, some settings, and such.

Yeah, this is how it works. I don't know the technical details/internal terminology, but I've definitely had a few accounts I follow switch servers for various reasons. It was basically just "oh hey so-and-so's handle changed" from my perspective, which is kinda neat.

> a migration path for users to move to other instances

Thanks for clarifying - without that bit of background, this post reads like, "if I can't have it, no one can". But I guess the post is directed at people who do understand the background behind mastodon in general (which I and OP didn't).

Wouldn't it make sense for there to be a cryptographic verification based on a private key held by the user, so that they can prove to other servers/users that they are the same account as one that existed on a server that has shut down already? Is there something like that in Mastodon?

It doesn't involve cryptography, but mastodon has for at least a couple of years supported link-verification in profiles (it basically checks if a link back to your mastodon profile exists on a page linked on your profile), so a linking to a page that only you credibly control (say, a personal website) is the de-facto system of decentralized user-verification on mastodon.

Edit: supported since 2018 https://github.com/mastodon/mastodon/pull/8703

It does sort of involve crypto: if the page you control weren't served over HTTPS it wouldn't be too hard (DNS poisoning) for someone else to trick a server into verifying the wrong user.

If DNS poisoning is so easy why don't you perform the same attach on Let's Encrypt since that also uses plain HTTP.

Certificate Authorities are extremely careful about DNS (and BGP hijacking), more so than basically everyone else.

I think most people in this situation do the same thing people do on Twitter when it suspends an account for nonsense reasons like telling a Nazi to eat paste: make another, make a post, share it with a few friends off Twitter/Mastodon, have them RT/boost to circulate it within their circles. This seems to work pretty well.

Cryptographic certainty is fun to think about, but sometimes you just need people.

Well, seems like this is a clear path for improvement: a decent UI tool for migration between instances

Such mechanism already exists. Look for the comment by @nightpool

It works best between Mastodon instances, but between different apps the migrations are often also supported. New apps like GoToSocial have the migration still as open issue sitting in their tracker, but will support as well.

Very little actually. Depending on how the shutdown works in practice, the impact is basically nothing. Other instances just stop receiving updates from the instance, which just results in the users in the closed instance being cached artifacts (zombie accounts) that need to be cleaned out manually.

There's also a "self destruct" feature in Mastodon which is the nice way to shut down an instance; it issues account deletion messages for every account to every instance it federates with. The idea being that this results in the federating instances processing the account deletions accurately.

As for requests to the original server; basically all instance software (Mastodon included) implement a backoff mechanism, meaning that if after 3 months your server is still returning 404s when requesting new information, the software will quietly stop requesting new info unless explicitly asked to do so by a user.

A know a fair amount of Fedi folk who have moved instances. The move feature means we haven't lost touch, that they haven't lost their network. Some have even moved to start their own instance, or chose to move elsewhere. Whilst I am sure many lament not being able to bring posts to a new account, they can be exported and it's one's network which is most important.

I myself moved off mastodon.technology when I didn't agree with a change to the ToS, and was banned from mastodon.social without reason or redress, and neither event meant I had to start from scratch.

We're already seeing hundreds of people migrating to other nodes.

Reply on news.ycombinator.com