Federated Database Migrations

[zicklag]

It just realized that doing database migrations in a decentralized, federated context is a lot different than doing database migrations on a centralized PostgreSQL database.

When you're working with a centralized database, you can "freeze the whole world" while you migrate the database entries to the new schema.

In a decentralized context, you can't freeze the world. There could be many different Weird instances that are still running an older version and serving users. You could also have offline users that are changing their profile or writing posts, even though you've update the server to the new version already. All kinds of stuff could be happening at the same time, and there's no way to stop it.

There's still a way to do it, though!

The idea is:

• Everybody is free to update to newer versions of Weird at different times.
• When each server, or local app, updates, it will migrate it's own data, to the new format, and put it in a new namespace. ( A namespace is like a database, we can have multiple of them in Iroh. )
• This means that old servers / apps that haven't updated will continue to function, and be able to communicate with any other servers / apps that are running the same version.

If we release a new version of Weird, and we deploy it to Weird.one, it will migrate all of the accounts hosted on it, to the new format. Now we hypothetically have Weird.one at the latest version, and all other sites at the older version.

At that point there are some options:

• Weird.one can keep the old profiles around so that they are visible to other sites that have not updated yet, but that may allow stale profiles to be viewed on the old site which isn't good.
• Weird.one will delete the old profiles, so that they will not be visible anymore to the older versions.
• Weird.one will replace the old profiles with notes that the profile has moved to a later version of Weird.

The last option is most likely preferable.

So, while different versions of Weird won't necessarily be able to see profiles from the other versions, there is a sensible way to manage multiple running versions without things falling apart.

Also, this migration process only needs to happen for non-backward-compatible changes. Many updates could happen without migrations. For example, if we add a new field to profiles, old instances would simply not see it in standardized profile view, but they would actually still see it in the personal web page view, which is rendered by updated server.

It would eventually become an uncommon thing as Weird stabilized, but also gives us a transparent way to handle federating with a gamut of servers that may not all update at the same time.