Follow
@J12t@social.coop Well there are two different use cases here.
People wanting to have different hats is one thing. It absolutely makes sense to have a professional versus a fun persona. Obviously that person doesn't want to link the two.
But the issue of having different accounts on different platforms because they do different things, that is a huge drawback to the #Fediverse system as it is now. That's the case of the same hat, the same persona, on different platforms simply because different platforms can't do the same work.
I really hope the system that some point figures out how to have the same account/persona on different interfaces. I think I remember that Bluesky might support that out of the box.
@volkris @Johannes Ernst First of all, I'm not a tech-illiterate dreamer. I've even hosted personal #Friendica and #Hubzilla instances myself on Linux machines at home, and I've been on even more public instances of several projects, long before there was #Mastodon even. So I'm not a dreamer for whom the Fediverse is an obscure black box observed through a mobile app.
And I have to say that an easy-peasy solution where you register one account on one instance of one project and automatically get accounts on all projects won't happen. It's technologically impossible or just not feasible. You will never be able to just simply register one Mastodon account, go to any one #PeerTube instance, upload videos on your personal channel which you suddenly have, go to any one #FunkWhale instance and upload audio files.
Automatic recognition of login credentials is one thing. This is possible already now, and Hubzilla and #Streams have this implemented and in use, even including which of your channels you have active right now (both allow you to have multiple channels, i.e. multiple separate IDs like multiple separate Mastodon accounts, but with only one actual account per instance).
But full participation requires accounts. And automatic account creation is non-sense. Dangerous non-sense.
Imagine you register a Mastodon account. Now you expect to also have a PeerTube account, a #Pixelfed account, a FunkWhale account, a #Lemmy account, a #BookWyrm account, even a Hubzilla account with one channel while we're at it and so forth. One account for each Fediverse project.
Well, how is that automatic account creator supposed to know on which instances these accounts shall be created?
This can only be carried out in two ways.
One, immediate account creation on ALL instances. You create one account on Mastodon, you automatically get one account on each public instance of every one of the other projects. You will have a login with the same e-mail address and the same password everywhere.
In the cases of Hubzilla and (streams), both of which are nomadic, this still only gives you one channel which is immediately mirrored by its #NomadicIdentity across all public instances. This is what many Fediverse users dream of.
But the rest of the Fediverse doesn't have nomadic identity. You can't have one Pixelfed account automatically mirrored across all public Pixelfed instances. This is not possible with ActivityPub, and it most likely never will. You'd have lots of separate accounts, one per instance.
Also, this means that whenever someone is being lured over from Twitter to mastodon.social, and they create an account, at least everything that isn't Mastodon will automatically be cluttered with new accounts, most of which will never be used.
A more lightweight alternative would be drive-by account creation. So you're logged into Mastodon. You go to any one Pixelfed instance, no matter which. And a new account is being created there for you immediately with the same e-mail address and the same password. Regardless of whether you want to have an account on this particular instance or not.
This also means that whenever you visit any instance of any Fediverse project where you don't have an account, and you're logged into any one other Fediverse instance, a new account is being created for you.
Again, this would mean account clutter. Not as badly as in the previous example, but still. And it would mean lots of separate accounts on the same projects which are not in-sync because Mastodon and Pleroma and Pixelfed and PeerTube and the other #ActivityPub projects don't have nomadic identity.
It's also a common misconception that the various Fediverse clients are just different access clients/user interfaces for the very same thing. That the difference between Mastodon, #Akkoma and Hubzilla is like the difference between Google Chrome, Opera and Firefox. But that the data structure is always exactly the same.
This is wrong. This is dangerously wrong.
Akkoma and Hubzilla don't just make stuff look different from Mastodon and vice versa. They have different internal workings. Vastly different in the case of Mastodon and Hubzilla. They don't just display the same stuff differently. They make it so that it isn't even the same stuff anymore.
For example, Hubzilla can do a whole lot of text formatting, and you can embed as many pictures as you want wherever you want in posts. Mastodon can't do text formatting at all. You can only attach a maximum of four pictures and only to the end of your toot. And Mastodon doesn't understand how other projects handle pictures, so it converts them into file attachments and hangs them below the post. Go through this thread to see what I mean.
This isn't a case of Mastodon displaying the same content differently. This is a case of Mastodon changing the content. Destroying content even. It doesn't just look different. It is different. If someone managed to send one of my Hubzilla posts from Mastodon back to Hubzilla, it would not look like it did when I sent it.
And this is also why going fully nomadic across the whole Fediverse, regardless of project, will never be possible. Mastodon won't be able to handle the data that is being mirrored over from a Hubzilla hub because it doesn't even know what half of it is.
Not to mention that there is literally nobody working on ActivityPub who could advance the protocol to even include basic nomadic functionality. The ActivityPub committee has disbanded.
And I have to say that an easy-peasy solution where you register one account on one instance of one project and automatically get accounts on all projects won't happen. It's technologically impossible or just not feasible. You will never be able to just simply register one Mastodon account, go to any one #PeerTube instance, upload videos on your personal channel which you suddenly have, go to any one #FunkWhale instance and upload audio files.
Automatic recognition of login credentials is one thing. This is possible already now, and Hubzilla and #Streams have this implemented and in use, even including which of your channels you have active right now (both allow you to have multiple channels, i.e. multiple separate IDs like multiple separate Mastodon accounts, but with only one actual account per instance).
But full participation requires accounts. And automatic account creation is non-sense. Dangerous non-sense.
Imagine you register a Mastodon account. Now you expect to also have a PeerTube account, a #Pixelfed account, a FunkWhale account, a #Lemmy account, a #BookWyrm account, even a Hubzilla account with one channel while we're at it and so forth. One account for each Fediverse project.
Well, how is that automatic account creator supposed to know on which instances these accounts shall be created?
This can only be carried out in two ways.
One, immediate account creation on ALL instances. You create one account on Mastodon, you automatically get one account on each public instance of every one of the other projects. You will have a login with the same e-mail address and the same password everywhere.
In the cases of Hubzilla and (streams), both of which are nomadic, this still only gives you one channel which is immediately mirrored by its #NomadicIdentity across all public instances. This is what many Fediverse users dream of.
But the rest of the Fediverse doesn't have nomadic identity. You can't have one Pixelfed account automatically mirrored across all public Pixelfed instances. This is not possible with ActivityPub, and it most likely never will. You'd have lots of separate accounts, one per instance.
Also, this means that whenever someone is being lured over from Twitter to mastodon.social, and they create an account, at least everything that isn't Mastodon will automatically be cluttered with new accounts, most of which will never be used.
A more lightweight alternative would be drive-by account creation. So you're logged into Mastodon. You go to any one Pixelfed instance, no matter which. And a new account is being created there for you immediately with the same e-mail address and the same password. Regardless of whether you want to have an account on this particular instance or not.
This also means that whenever you visit any instance of any Fediverse project where you don't have an account, and you're logged into any one other Fediverse instance, a new account is being created for you.
Again, this would mean account clutter. Not as badly as in the previous example, but still. And it would mean lots of separate accounts on the same projects which are not in-sync because Mastodon and Pleroma and Pixelfed and PeerTube and the other #ActivityPub projects don't have nomadic identity.
It's also a common misconception that the various Fediverse clients are just different access clients/user interfaces for the very same thing. That the difference between Mastodon, #Akkoma and Hubzilla is like the difference between Google Chrome, Opera and Firefox. But that the data structure is always exactly the same.
This is wrong. This is dangerously wrong.
Akkoma and Hubzilla don't just make stuff look different from Mastodon and vice versa. They have different internal workings. Vastly different in the case of Mastodon and Hubzilla. They don't just display the same stuff differently. They make it so that it isn't even the same stuff anymore.
For example, Hubzilla can do a whole lot of text formatting, and you can embed as many pictures as you want wherever you want in posts. Mastodon can't do text formatting at all. You can only attach a maximum of four pictures and only to the end of your toot. And Mastodon doesn't understand how other projects handle pictures, so it converts them into file attachments and hangs them below the post. Go through this thread to see what I mean.
This isn't a case of Mastodon displaying the same content differently. This is a case of Mastodon changing the content. Destroying content even. It doesn't just look different. It is different. If someone managed to send one of my Hubzilla posts from Mastodon back to Hubzilla, it would not look like it did when I sent it.
And this is also why going fully nomadic across the whole Fediverse, regardless of project, will never be possible. Mastodon won't be able to handle the data that is being mirrored over from a Hubzilla hub because it doesn't even know what half of it is.
Not to mention that there is literally nobody working on ActivityPub who could advance the protocol to even include basic nomadic functionality. The ActivityPub committee has disbanded.
I never questioned your cred.
But I do remember once being told that the #ActivityPub protocol might be open to cross-service identity just because of how it handles account addressing and certificates.
With id, WebFinger, and other things already baked into ActivityPub and/or implementations, ids can be separated from instances.
So supposedly support for the functionality is already in there, whether intentionally or not. It just takes implementers figuring out the best way to make it work.
@J12t@social.coop
@volkris @J12t I absolutely agree. I officially have *two* Fediverse hats (I link both of them in both profiles and use the same avatar) that I want to keep separate, but I can use only *one* platform (instance software), because I can't connect multiple accounts into one hat. So the #Fediverse is all #Mastodon for me, and I can't use anything else, because I don't want more hats.