because that is your identity, the full "user@domain" the domain you are on is an intrinsic part of addressing to get to your account. so the question then becomes why can't you change your name? and it has mainly to do with avoiding name conflicts in administratively isolated systems.

A major problem in distributed systems is names. one solution is to do what dns did, you can have nice names but you only get to pick them under the part of the hierarchy you control. another solution is to do what git or ipfs does. nobody gets useful names but at least you don't need any sort of central name database.

mastodon went the dns/email route, which makes sense people want nice names. but now your name is stuck on your domain. perhaps someone could have setup a central name server to avoid name collisions, but who would you trust to run it? what happens when it goes down? might as well just use dns.

Off tangent opinion on names in a federated system.

Unfortunately mastodon adopted the twitter style "@user" but because this only make sense in the context of a single domain mastodon mainly uses the awkward form "@user@domain" I think the email/xmpp form "user@domain" would have been better, but if they felt the @ prefix was critical to the experience of a twitter like micro blog than they probably should have adopted the form "@user.domain"

> because that is your identity

That seems like a very, very poor choice. I have the same concern with Matrix.

It is actually a better question than I initially thought.

the question actually challenges all sorts of assumptions we make about how the internet works. in this regards it reminds me of IPFS.

And while ipfs has some very cool tech the main thing it has problems with are names. ipfs has no names, which sucks. there is a name system ipns but it does not help much.

ipfs does a publish/subscribe subsystem which I find one of the most compelling parts. it is however considered experamental and inefficient.

this did not stop me from writing a distributed video streaming system using it. which turns out to suck, no names, and, even on my local network I was getting ~ 2 minutes of lag, no one would put up with that for streaming.

https://nl1.outband.net/fossil/ipfs_stream/doc/tip/readme.md

> That seems like a very, very poor choice.

By all means, enlighten us to the better one. It seems like they made a tradeoff here, and one that’s most in line with keeping everything distributed.

I don't know that I'd agree that it's a "very, very poor choice" but I can see how it would prevent Mastodon from seeing more widespread adoption. If widespread adoption isn't their goal, then it really doesn't matter though, and as you said, they made a tradeoff. I can definitely see the benefits of both ways of handling users.

>perhaps someone could have setup a central name server to avoid name collisions, but who would you trust to run it? what happens when it goes down? might as well just use dns.

ENS (https://ens.domains/) solves this problem rather elegantly. A single source of truth that is decentralized so any app can use it without trusting anyone. It wasn't around when Mastadon was being built unfortunately but is useful for developers of new apps and protocols.

no it doesn't. and you'd have to pay for names, which disqualifies it for mastodon like usage from the start.

Can you elaborate on how it doesn't? It ticks all of the boxes from your message.

Only the top level namespaces require a purchase. Names for services (e.g. james.mastadon.eth) are free. A live example of this is Coinbase which gives users (name).cb.id for free. Once your service claims a namespace you have full control over it.

> Can someone explain why a Mastodon account is so intrinsically tied to the instance it was registered on?

There's no central server, and not all of the instances talk to each other.

Where... where would you put the account data?

I imagine it working similarly to IPFS, where the data is distributed across the network.

Think of it as more like email. You have an account on a specific server, but can send or receive emails from anyone on any server.

There's not one network with mastodon. Depending on which node you start in, you can get different graphs (from what I remember, mostly due to differences in value between valuing free speech vs preventing hate speech).

Ya'll are describing SSB protocol and ManyVerse.

I just looked into SSB and I really like the concept. It seems much more elegant than Mastodon. Why is Mastodon/the Fediverse so much more popular (or is it?)? What are the advantages of federation over total decentralization? I suppose one disadvantage of total decentralization is the need for ‘fat clients’, as another commenter pointed out.

As you can see with Twitter, more popular doesn't mean better.

There's a way to do this, but it requires fat clients https://indieweb.org/POSSE

Mastodon confused me for the longest time as well. Which community do I join? If I create an account on "federatedplumbers.example" why would I interact with a community and follow people at "federatedshoelacecollectionists.example"? Shouldn't I create an account at both communities and interact with each separately? This is what we do now by having a twitter account and a facebook acount, and a etc... A twitter account doesn't ever talk to a facebook account.

Then I saw someone do something I hadn't seen before...

They made their own mastodon insance: toot.firstlastname.example and their identity was @[email protected]

Joey could make his own toot feed of social media posts that anyone at any community could subscribe to.

Joey could then subscribe to the entire community at federatedplumbers.example, or he could follow just one user: @[email protected]. Then @[email protected] could follow @[email protected] and so on.

It doesn't matter where you start an account. You can join a community that you really like or start from scratch with your own instance and go and make friends in other communities. The real advantage with starting your own is that you have control over your content and aren't in danger of having your account shut down if a community decides it can no longer maintain the server.

It's because of the sybil problem. If accounts are globally unique, then a bad actor can register as many accounts as they want, and can do things like e.g. reserve other people's usernames and charge real money to have them unreserved.

From a technical point of view because ActivityPub is based in HTTP and other instances need to know what endpoint to talk to.

There is already support for basic migration of followers but it would be nice to see fully instance-independant accounts. Probably something based on cryptography so your account is a key and you can publish from any server. However a protocol like this would be a lot more complicated than ActivityPub.