Ben Pate 🤘🏻So, I realize that I’m probably an edge case, and the rest of the Fediverse may not neeed true account portability right away, but I’m putting my foot in the gas because I reeeally neeeeed this to work
Jupiter Rowland@Ben Pate 🤘🏻 Let's just say the only devs who need full identity portability are silverpill and you, and silverpill is actively working on it.
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity
Tim Chambers (@[email protected])
69.8K Posts, 5.48K Following, 18.1K Followers · Technologist, writer, who is fascinated by how new politics impacts technology and vice versa. #fedi22 #indieweb #fediverse
Forgive me for being slow to get back to your #Long post.
I’ve skimmed the FEP (with more studies to come) and I doubt Mastodon et al will implement this. It seems like a breaking change that a big project just couldn’t undertake.
Also: I see the mechanism for splitting an identity and recovering if a server goes down, but how is profile data supposed to be synchronized between servers in the first place? How does it get distributed?
@Ben Pate 🤘🏻 I’ve skimmed the FEP (with more studies to come) and I doubt Mastodon et al will implement this. It seems like a breaking change that a big project just couldn’t undertake.
Well, I think that chances are nil that Mastodon will even consider this. I mean, when was the last time that they've implemented something developed by another Fediverse project, especially a non-commercial one? And in this case, on top of it all, it'd mean that Eugen Rochko would have to admit that Mike Macgirvin was right about something. He'd rather go on headbutting, hoping he'll win just by having the project with more users.
Otherwise, yes, it'll come with big changes. I remember last summer. The streams repository used to have its own "nomadic" branch; while (streams) has always been nomadic, this branch was for the development of support for nomadic identity via ActivityPub (while, of course, (streams) itself would continue to use Nomad for nomadic identity).
In June, Mike was confident enough about the nomadic branch to merge it into the dev branch. In July, he merged the dev branch with the release branch for a new release, thereby introducing decentralised identities as per FEP-ef61 to all (streams) servers that'd upgrade from then on. Again, (streams) was already nomadic at this point with identities separate from logins and accounts.
Still, (streams) blew up. What had worked under lab conditions failed out in the open. (streams) was unable to federate or connect with anything. With DIDs new in the game, it had to juggle so many identifiers that it got them mixed up. After all, it also had to handle various already existing ActivityPub IDs plus the Nomad IDs plus the Zot6 IDs to stay compatible with Hubzilla.
And (streams) was being daily-driven by a few dozen people back then with no way to move anywhere. It has never been possible to clone from (streams) to Hubzilla after all.
Mike had to spend hours upon hours trying to find the fault in the first place and then fix it. This may have been the reason why he officially launched Forte in mid-August: He probably took (streams) and ripped out everything that isn't ActivityPub to get rid of the Nomad and Zot6 IDs. And it must have been easier to actually make Forte clone via ActivityPub than to get (streams) going again. He largely achieved the latter until the end of August when he officially quit developing Fediverse software and declared both repositories up for grabs.
So the whole new DID system is likely to cause trouble.
In addition, non-nomadic projects based on ActivityPub (i.e. literally everything that isn't Hubzilla, (streams) and Forte) will have to switch from the usually model of the account and login being the identity to Hubzilla's, (streams)' and Forte's channel model. This is a big change, it will make onboarding more difficult, and it will be hard to sell to the existing users how it's supposed to be better than how things were before.
Also, it will break compatibility, so it will have to be rolled out in slices, by and by. For example, Mastodon would first have to roll out a new version that understands identities that are separate from logins and ideally bundle it with must-have security fixes and bugfixes to ensure that as many servers as possible will upgrade. In fact, they may actually have to backport that feature to Mastodon 4.3, 4.2, 4.1, 4.0, maybe even to 3.x because some admins refuse to upgrade to 4.0.
Only when most Mastodon servers understand identities separate from logins, Mastodon can introduce these separate identities to mastodon.social and mastodon.online. Otherwise they'd end up in a situation in which mastodon.social, the flagship instance of the whole freaking Fediverse, interacts with (streams) and Forte better than with the rest of Mastodon.
And then we can talk about cloning and syncing. By the way: "Let's first implement better moving before we tackle cloning" would be non-sense. Moving with nomadic identity requires cloning. It literally involves cloning. If you can't clone yet, you can't move.
Again, look at Mitra. silverpill decided to go nomadic in 2023. It's still in early development now.
Also: I see the mechanism for splitting an identity and recovering if a server goes down, but how is profile data supposed to be synchronized between servers in the first place? How does it get distributed?
I'm not a Fediverse developer, but AFAIK, FEP-ef61 doesn't cover everything that makes up nomadic identity.
Three things I know. One is when syncs happen.
Zot has the ability to trigger syncs built in. This means that if something changes in one instance of your channel, this triggers an immediate syncing process to all other instances. Nomadic syncing happens in near-real-time. ActivityPub doesn't have this feature, and it can't be implemented by FEP either. So nomadic identity via ActivityPub will probably have to rely on cronjobs to trigger syncs.
Basically, on Hubzilla (Zot6) and (streams) (Nomad), it works like this: You use one instance of your channel. You change something. The server notices these changes and nearly immediately pushes them to the other servers with instances of your channel in much the same fashion as an incremental backup.
On Forte (ActivityPub), there must be something that collects and lists changes. If changes are listed on an instance of your channel, when the cronjob kicks in, these changes are sent to the servers with the other instances.
Conflicts that arise if you use two instances of your channel at the same time are probably solved by always overwriting older data with newer data.
The second one is that initial syncing can be selective. When you create a new clone, you can choose to not sync everything over yet. The actual profile with (almost) all settings, the posts/comments/DMs and the files in the cloud storage can be sync'd separately from one another, and they can also be sync'd after the fact if you don't immediately need all your files on your clone yet.
Later syncing always involves everything that has been sync'd at least once.
The third one is that nomadic identity with more than two instances doesn't work in a hub-and-spoke way. If you log into one of your clones and you use it, the changes are not sync'd from that clone to the main instance and from there to the other instance. If the main instance was offline, nothing would be sync'd at all. Rather, everything is sync'd from that clone to the main instance and directly to the other clones. Each instance of your channel is aware of all other instances.
In short, nomadic identity can be described as "OwnCloud/Nextcloud/OpenCloud, but it's peer-to-peer, and it's between servers rather than between workstations".
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Zot #Zot6 #Nomad #Mastodon #Hubzilla #Streams #(streams) #NomadicIdentity
Well, I think that chances are nil that Mastodon will even consider this. I mean, when was the last time that they've implemented something developed by another Fediverse project, especially a non-commercial one? And in this case, on top of it all, it'd mean that Eugen Rochko would have to admit that Mike Macgirvin was right about something. He'd rather go on headbutting, hoping he'll win just by having the project with more users.
Otherwise, yes, it'll come with big changes. I remember last summer. The streams repository used to have its own "nomadic" branch; while (streams) has always been nomadic, this branch was for the development of support for nomadic identity via ActivityPub (while, of course, (streams) itself would continue to use Nomad for nomadic identity).
In June, Mike was confident enough about the nomadic branch to merge it into the dev branch. In July, he merged the dev branch with the release branch for a new release, thereby introducing decentralised identities as per FEP-ef61 to all (streams) servers that'd upgrade from then on. Again, (streams) was already nomadic at this point with identities separate from logins and accounts.
Still, (streams) blew up. What had worked under lab conditions failed out in the open. (streams) was unable to federate or connect with anything. With DIDs new in the game, it had to juggle so many identifiers that it got them mixed up. After all, it also had to handle various already existing ActivityPub IDs plus the Nomad IDs plus the Zot6 IDs to stay compatible with Hubzilla.
And (streams) was being daily-driven by a few dozen people back then with no way to move anywhere. It has never been possible to clone from (streams) to Hubzilla after all.
Mike had to spend hours upon hours trying to find the fault in the first place and then fix it. This may have been the reason why he officially launched Forte in mid-August: He probably took (streams) and ripped out everything that isn't ActivityPub to get rid of the Nomad and Zot6 IDs. And it must have been easier to actually make Forte clone via ActivityPub than to get (streams) going again. He largely achieved the latter until the end of August when he officially quit developing Fediverse software and declared both repositories up for grabs.
So the whole new DID system is likely to cause trouble.
In addition, non-nomadic projects based on ActivityPub (i.e. literally everything that isn't Hubzilla, (streams) and Forte) will have to switch from the usually model of the account and login being the identity to Hubzilla's, (streams)' and Forte's channel model. This is a big change, it will make onboarding more difficult, and it will be hard to sell to the existing users how it's supposed to be better than how things were before.
Also, it will break compatibility, so it will have to be rolled out in slices, by and by. For example, Mastodon would first have to roll out a new version that understands identities that are separate from logins and ideally bundle it with must-have security fixes and bugfixes to ensure that as many servers as possible will upgrade. In fact, they may actually have to backport that feature to Mastodon 4.3, 4.2, 4.1, 4.0, maybe even to 3.x because some admins refuse to upgrade to 4.0.
Only when most Mastodon servers understand identities separate from logins, Mastodon can introduce these separate identities to mastodon.social and mastodon.online. Otherwise they'd end up in a situation in which mastodon.social, the flagship instance of the whole freaking Fediverse, interacts with (streams) and Forte better than with the rest of Mastodon.
And then we can talk about cloning and syncing. By the way: "Let's first implement better moving before we tackle cloning" would be non-sense. Moving with nomadic identity requires cloning. It literally involves cloning. If you can't clone yet, you can't move.
Again, look at Mitra. silverpill decided to go nomadic in 2023. It's still in early development now.
Also: I see the mechanism for splitting an identity and recovering if a server goes down, but how is profile data supposed to be synchronized between servers in the first place? How does it get distributed?
I'm not a Fediverse developer, but AFAIK, FEP-ef61 doesn't cover everything that makes up nomadic identity.
Three things I know. One is when syncs happen.
Zot has the ability to trigger syncs built in. This means that if something changes in one instance of your channel, this triggers an immediate syncing process to all other instances. Nomadic syncing happens in near-real-time. ActivityPub doesn't have this feature, and it can't be implemented by FEP either. So nomadic identity via ActivityPub will probably have to rely on cronjobs to trigger syncs.
Basically, on Hubzilla (Zot6) and (streams) (Nomad), it works like this: You use one instance of your channel. You change something. The server notices these changes and nearly immediately pushes them to the other servers with instances of your channel in much the same fashion as an incremental backup.
On Forte (ActivityPub), there must be something that collects and lists changes. If changes are listed on an instance of your channel, when the cronjob kicks in, these changes are sent to the servers with the other instances.
Conflicts that arise if you use two instances of your channel at the same time are probably solved by always overwriting older data with newer data.
The second one is that initial syncing can be selective. When you create a new clone, you can choose to not sync everything over yet. The actual profile with (almost) all settings, the posts/comments/DMs and the files in the cloud storage can be sync'd separately from one another, and they can also be sync'd after the fact if you don't immediately need all your files on your clone yet.
Later syncing always involves everything that has been sync'd at least once.
The third one is that nomadic identity with more than two instances doesn't work in a hub-and-spoke way. If you log into one of your clones and you use it, the changes are not sync'd from that clone to the main instance and from there to the other instance. If the main instance was offline, nothing would be sync'd at all. Rather, everything is sync'd from that clone to the main instance and directly to the other clones. Each instance of your channel is aware of all other instances.
In short, nomadic identity can be described as "OwnCloud/Nextcloud/OpenCloud, but it's peer-to-peer, and it's between servers rather than between workstations".
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Zot #Zot6 #Nomad #Mastodon #Hubzilla #Streams #(streams) #NomadicIdentity