#movinginstances — Public Fediverse posts

@Ben Pate 🤘🏻

What if moving a server looked like this:

1. sign up for new account
2. authenticate old account (OAuth, whatever)
3. click "migrate"
4. click "yes really"
5. celebrate

If this were possible, then a whole lot of people could become "server admins" without being IT nerds.

Reality on Hubzilla for longer than Mastodon, as well as on (streams) and Forte:

1. Register a new account.
2. Optionally: Wait for it to be manually activated by the admin.
3. Be asked to create a channel (= the actual identity with posts and contacts and files and stuff; your account is not your identity).
4. Choose the option to move an existing channel.
5. Enter the URL of the existing channel.
6. Enter the password of the account on which the existing channel is located.
7. Confirm
8. A clone of the channel is created on the new server.
9. The data of the existing channel is mirrored to the clone.
10. The clone is promoted to main instance of the channel; the already existing instance of the channel is demoted to clone.
11. The ID of your channel is changed accordingly.
12. All nomadic contacts (= on Hubzilla, (streams) or Forte) are automatically changed to the new ID.
13. (streams) and Forte only: All non-nomadic contacts receive a new connection request.
14. The former-main-instance-and-now-clone is deleted because you chose to move rather than clone.
15. If there are no other channels on the account on the old server, the whole account is deleted because accounts cannot exist with no channels on them.

The only two differences between cloning and moving are that cloning leaves your main instance intact instead of deleting it, and it leaves it as your main instance by default rather than making the new clone your main instance.

It works for Discord, why not the Fediverse?

It's a common misconception, probably even by FLOSS devs, that "server" on Discord that a handful of clicks on the Web interface inserts a new 19" rack iron into a rack inside some data centre with a LAMP stack and an installation of the Discord server backend on it and makes you the tech admin. Or something like that.

This is far from the truth. Discord has integrated the word "server" into its newspeak. On Discord, "server" means "chat room". A chat room on the same centralised, corporate-owned, commercially-operated server farm as all the other "servers".

At the same time, Generation Z and newer think that this is what "server" always means because they've never come into contact with TeamSpeak and never experienced LAN parties.

Administrating a Fediverse server, on the other hand, does equal administrating a LAMP stack on the command line, full stop.

I sincerely hope that the day won't come when someone does with e.g. Mastodon what the Outworldz DreamGrid did with OpenSimulator: turn a full server stack into an "easy-peasy", fully-preconfigured, Windows-only point-and-click application that anyone can install on their Windows machines with absolutely zero prior knowledge about servers or networks, that even automatically connects to a dynamic DNS service that was created specifically for this application so you don't even need to know anything about domains, and that can only be handled through the built-in Windows GUI. (Mind you, there are people who are actually asking for exactly this, only not for Windows, but for their iPhones. Food for thought.)

CC: @silverpill  @Contraquestão

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Forte #MovingInstances #NomadicIdentity #Discord #OpenSim #OpenSimulator #DreamGrid

@Marcus Rohrmoser 🌻 Not to my knowledge.

First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.

See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.

As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.

Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.

Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.

Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.

There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.

In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.

So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until

• the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
• silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised

Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.

Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.

The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.

Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.

Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:

• Situation:
  
  • You have an account on digitalcourage.social with one channel, [email protected].
  • You want to move to troet.cafe.
• Step 1: You create an account on troet.cafe.
• Step 2: There can't be accounts with no channels. You have to add a channel.
  So you choose to move your channel [email protected] from digitalcourage.social to troet.cafe.
• Step 3: Your channel [email protected] is cloned over to troet.cafe.
• Situation now:
  
  • You have an account on digitalcourage.social with the main instance of your channel; its identity is [email protected].
  • You have an account on troet.cafe with a clone of your channel; its identity is still [email protected].
• Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
• Now the main instance and the clone are identical.
  Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving.
• Step 5:
  
  • The clone on troet.cafe is promoted to main instance.
  • As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
• Situation now:
  
  • You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is [email protected].
  • You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is [email protected].
• Step 6: All your connections on servers of nomadic software are changed from [email protected] to [email protected], both locally on the servers that you are on and locally on the servers that they are on.
• Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from [email protected] which, to them, is an all-new, independent identity.
• The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
• Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
• Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #ActivityPub #Zot #Zot6 #Nomad #FEP #MovingInstances #Clone #Clones