@feditips sorry for a really dumb question on Kban…how do I sign up with my mastodon user name? What’s the proper format? I keep getting a “match format” message. I’m not sure why I’m struggling with. Mastodon was a breeze compared to this. 😔

@feditips ok, I think I understand that, but when I look at users on kban it displays their other instance info as well (eg: FEDITIPS @[email protected]). I’ve just created a kban account displaying USERNAME @[email protected] which isn’t what I want. Does that make sense or am I totally missing something. Thanks for your patience, I don’t know why I don’t get this.

@feditips @SocialSpirit the bit that's always stumped me is why I've got to have one profile per fedi app rather than a single unified profile. That's the part that isn't seamless.

@Fedi.Tips @SocialSpirit :mastodon: I guess what @Coo-Ops wants is not simply to be able to interact with users on other projects (or "apps" because they sound like someone for whom the Fediverse is an obscure black box with a bunch of mobile apps on the Apple App Store or the Google Play Store sticking out) from Mastodon.

It sounded more like they want full user access rights on all #Fediverse projects with one account on one instance. Upload videos to any #PeerTube instance, upload songs to any #Funkwhale pod, upload podcasts to any #Castopod instance, create and moderate communities/magazines on any #Lemmy or #kbin instance, create and moderate public and private forums on any instance of #Friendica, #Hubzilla or #Streams, create and edit articles and wikis on any Hubzilla hub and so forth. All only with one login on one instance of one project, preferably #Mastodon.

This simply is technologically impossible. It's like having a user account on one phpBB forum and still being able to post on every forum in existence, regardless of whether it runs phpBB or vBulletin or Discourse or Flarum or whatever.

In order to have full user rights on any one Fediverse instance, you will need an account there. Even if there was a unified login system so that you actually log into 20,000+++++ Fediverse instances when you log into one, you'll still need an account.

This would mean two things.

For one, whenever a newbie comes over from Twitter to Mastodon, and they create an account on mastodon.social, accounts on all other instances of all other Fediverse projects must be created automatically with the same credentials.

Now you might say, "I don't need an account on EVERY instance!" No, but you MAY need an account on this instance or that instance because you've just stumbled upon it, and you want to use it as if you have an account there. And ANY instance out there could be "this instance or that instance".

Besides, whenever an aspiring admin starts up a new instance of any Fediverse project for the first time, and be it something fairly obscure like (streams) which only supports #ActivityPub as an optional plug-in, it would immediately have to create 12,000,000++ user accounts automatically so that every Fediverse user has full user rights on this one particular instance as well. I mean, someone on #Akkoma could find your one-minute-old (streams) instance and decide it's a nice place for a public forum.

I think it's clear that this is unrealistic.

@Coo-Ops That's because neither your WordPress blog nor your Pixelfed account even know that your Mastodon account exists. They have never in their lives heard of one another. They have never come into touch with each other. So they can't magically know who and where you are on other projects.

The practical solution for this would be for your Mastodon account to follow both your Pixelfed account and your WordPress blog.

The "one login for everything" approach would require total centralisation of the whole #Fediverse. Not only would separate projects have to be merged into one gigantic, omnipotent monster of a project, but the concept of separate distributed instances would have to disappear, too. One central all-knowing login for everything would require one central database for everything.

And whoever owns this database would have full control over the entire Fediverse.

@Coo-Ops That'd require all instances of all projects to be aware of all user accounts/channels on all instances of all projects and stay up-to-date in real time. This could only be established in two ways.

Either there would have to be one central server which all instances of all projects communicate with, where they can look up user identities. It's a very bad idea already to make any one Fediverse project, e.g. Mastodon, depend on central infrastructure. It'd be even worse if the whole Fediverse with dozens upon dozens of independent projects and tens of thousands of independent instances depended on central infrastructure and essentially ceased to work properly without it.

Or all instances of all projects would have to communicate with each other directly. In order to be able to do that, they would have to know all other instances, regardless of project. All of them. No exception.

So let's suppose I return to self-hosting my own Hubzilla hub like I've done in the past. I set up a virtual machine. I install a LAMP stack. I install Hubzilla on it. I configure it. I start the Web server up for the first time. And my Hubzilla hub would have to know all instances of all Fediverse projects out there immediately. Yes, including the brand-spanking-new MissKey instance someone just spun up for the first time in Nagoya 30 seconds earlier. And that new MissKey instance would have to know my own new Hubzilla hub as soon as I start it up.

For one, this is another thing that's technologically impossible unless each Fediverse project comes with a full list of all instances right away upon install. A list that's provided separately but still pulled in automatically during installation. A list that would have to be automatically updated by each instance of each project every few seconds in order to really always cover the entire Fediverse. With tens of thousands of instances pulling this list in every few seconds, the list would require its own data centre in order not to be DDoS'd to kingdom come.

By the way, even that wouldn't make sure that all Fediverse instances know all other Fediverse instances. Some instances would never have this list because their admins don't update them anymore, mostly small private instances. There are even active instances of entire projects that are dead, that aren't maintained anymore. There's at least one operational Osada instance, there are at least two operational Zap instances, and both projects had their end-of-life on New Year's Eve 2022. They might make it onto the list, but they won't have the list implemented themselves.

Oh, and you can't do that through the apps as in what's installed on people's mobile phones either. This would require every installation of every mobile app on every smartphone and every tablet to know all instances of all projects in the Fediverse, regardless of whether they can practically be used with these projects or not (good luck using Mobilizon through Mona). Instances pushing their data to mobile apps would be even worse: Each instance of each project would have to know every installation of every mobile app on every mobile device out there. Right away after starting up for the first time. Like, I spin up my brand-new Hubzilla hub, and it knows right away what you've got on your phone so that it can advertise its presence and all channels on it to all the apps on your phone. And to millions of other phones out there.

See, I'm a tech guy myself. But my view of the Fediverse is not that of a bunch of iPhone apps with some murky magic happening in the background. I used to self-host Friendica and Hubzilla on a Linux machine which I've built from parts myself; most of the time, they actually ran on Debian virtual machines on a Manjaro host system. I started using Friendica early on when it was still named Friendika, and that was 2011. And I access all Fediverse projects I use through Web browsers on Linux desktop computers and laptops. So I guess I know the technological background pretty well.