Hacker News Reader

I think the federation model of Mastodon is nearly identical to SMTP + mailing lists. When you create your own mailserver, it's an island. You can join some mailing lists to meet new people, or you can contact them directly if you know their address. By design, you and I can both have "foo@<different_instances>".

You can have ten different email addresses or Mastodon accounts if you wish. By default, they are separate. If you want them to mirror each other's content, you have to do that manually. I'm OK with this.

The difference is that email don't have communal public feeds like the instance feed and the instance federated feed. More of my thoughts wound up here: https://news.ycombinator.com/item?id=14159523

That's why I added "...and mailing lists". If each email server had a default "local-msgs@example.com" list that everyone was subscribed to, it'd look a lot like Mastodon.

That would be the first thing most email servers would disable.

Email has never had such a thing and likely never will, now that we understand the deep perils of spam. Mastodon has a problem email doesn't have because email doesn't want it.

A better example might be to look to email's "sister" NNTP, which hardly anyone uses these days because no one could figure out the spam problem. People switched to privately maintained mailing lists and web forum software because it had fewer spaces for a tragedy of the commons.

One problem with this is that if an instance is a "mailing list", it's currently not possible to join multiple mailing lists with the same e-mail address. That said this would not be as big a problem with e-mail addresses as it is in Mastadon; as WorldMaker mentions, the analogy breaks down because of the public feed - if you want to create an alias, you need to duplicate your public feed, and if you have things like the federated feed and hashtag search, you're going to end up with a lot of duplicated content out there.

If you had a lot of people cross-posting to different mailing lists with similar subscriber lists, I imagine people would be really annoyed if they had no way of merging your duplicated content.

Portable identities as a feature is definitely being worked on, but IIRC it will only help in the "I need to move from one instance to another" case. I don't have a project issue number handy, but it's there.

Multiple identities seems like a problem best solved by client-side tools (e.g. tweetdeck handles this usage really well IME).

The easiest way to merge multiple toots originating from the same person (through multiple federated accounts) is not to need to merge them in the first place.

Admittedly, the current intent is that you (person) keep individual toots to specific instances and don't "cross-post", but there may be all sorts of reasons to need to cross-post across identities but try to avoid spamming federated friends.

Email doesn't need to solve the problem because there isn't a "public feed" to try to hit. The issue here is that the individual feeds in an instance are always going to be complicated game to play to get attention and the next steps are going to be instance-feed-optimization (IFO?) techniques including mass cross-posts, whether the Mastodon community wants to see that or not. (Just as advertisers still care to optimize how they show up on the Twitter public feed...)

Portable cross-instance identities are a possible way to mitigate some of the worst of that. My pessimism/cynicism thinks that maybe Mastodon instances shouldn't have instance and federated feeds publically visible. If I were to run my own instance, that would be the first things I'd disable.

> Multiple identities seems like a problem best solved by client-side tools (e.g. tweetdeck handles this usage really well IME).

I agree in the sense that I might want something like a role / brand identity and a personal identity, but I was considering something more like instance-specific aliases or identities. The first-pass solution at this would be one where you can specify that different accounts on different instances are all the same person so that posts duplicated on multiple instances (i.e. in the local feed of that instance) can be de-duplicated in a federated feed that includes more than one of the aliases.

External clients won't be able to stop people from following one of the alias instances and not the "canonical" instance, and they won't be able to make servers de-duplicate content that is cross-posted to multiple instances. If this isn't addressed in the protocol, you'll get people hacking together "boost bots" that duplicate your identity to multiple instances (with the issues that comes from hacking something like that into your client) in the same way that they are already using "follow bots" that just randomly follow tons of users on other instances to force more thorough federation between instances.

https://github.com/tootsuite/mastodon/issues/177

Although core devs don't seem to be interested in implementing this, as it's not supported in the Ostatus spec.

Portability was such a huge factor for me losing interest in diaspora, and I hope that can be addressed.

As for the multiple instances, can't you just pick one and follow things on the others? That was my understanding.

You can follow individual accounts on other instances and their posts will show up in your home and federated timeline, but there's no way to, say, "follow" the full local or federated timeline of other instances. I assume that's what OP was referring to.

Currently my process for discovering what to follow is to look at the federated feed, looking at the local feed, and looking at hashtags - the parts of other instances I see on these views is limited to the parts of those instances being followed by at least one person on my instance, so if I'm on a small instance it's very unlikely that between the few dozen people in my instance that all of another small instance is covered - I'd like to just say, "merge bookwitty.social and mastodon.technology in my feed" or "search for #scifi on bookwitty.social and mastodon.technology".

Ideally, I'd like a seamless experience that allows me to see a "virtual instance" that is the merger of two instances. Like I said - I think the part that I see can be handled client side. Getting other people to see me, and having a portable identity, is another question entirely.

I think the approach to that is create individual accounts across instances, but always use your "main" or "home" instance. Follow people you find in the other instances from "main" account and always reply/boost from the "main" account. Eventually other people might pick up to follow your "main" account?

It's a lot of social behavior that yes might be better if the technology did more of the grunt work for you.

> The main problem I have is the fact that you are pretty tied in with your instance.

That is in fact emerging as a feature of Mastodon. While messages can and do propagate quite effectively, it takes much longer than Twitter and does so less reliably. This means instance choice has a very profound effect on both who you talk with and who you will reach.

It's still entirely possible to follow people on other instances, and it works fine. But it discourages certain types of use:

    1. Advertisers: reach is much less predictable.
    2. Spammers & trolls: While troll instances exist, they get blocked. 
    3. Bots. See above, it's painful & captcha-gated to open accounts on many instances.

Search in the context of microblogging frameworks like this has always been of questionable value, as ranking on recall is almost terrifyingly time-gated. This further damages the reach of any ONE message but allows for conversations as a whole to be somewhat observable (e.g, gaming vs #gameing).

> If, client-side, I just create a bot that auto-posts on multiple instances, if my followers on a given instance are following different versions of my account, the federated feed on that instance will be spammed with multiple posts.

I would advise not doing this, as we will start to block all your accounts. Attempting to chorus-spam the federated timeline will show up very quickly.

In summary: The slightly slower and less reliable delivery is a feature for human discourse at the expense of automated discourse. That is good, not bad.

It can be frustrating when you as a human have to maintain outsized attention on two or more locales. We can fix this client side (maybe) or we can solve this structurally. In effect, the community is preferring the later. There are many very small instances (even witches.town is pretty small) all arrayed around a few very central "hub" instances where most of the traffic originates from due to population.

You may track your hub account frequently but need to do much less work for spoke accounts.

The experiment of: "Your choice of primary identity and its location having consequences on your experience of the network" is fascinating. I have instances I am on only for the local timeline. I would not want them to mix with my more public account.

Regarding this "feature", none of 1, 2 or 3 are solved at all by what I'm talking about. I'm saying that I would actively join another instance and my old identity is duplicated there, with duplicated posts being merged, not that my posts propagate automatically to every node in the federation. All the advantages of gating off your instance are preserved, plus you avoid duplicated post spam in the federated view.

> I would advise not doing this, as we will start to block all your accounts. Attempting to chorus-spam the federated timeline will show up very quickly.

This was entirely my point. If you want to maintain a presence on multiple instances, the only way to post content relevant to multiple instances is to duplicate it, and it is not your choice whether or not multiple accounts of yours show up in the federated view of other instances. Echoing your posts is the hack that I'm sure people will try, some instances will ban it, others will put up with it, I imagine enforcement will be imperfect.

> It can be frustrating when you as a human have to maintain outsized attention on two or more locales.

Yes, to the extent to which clients and other hack-y behaviors do not solve this problem, what it means is that all the "spoke" timelines will die out and you'll concentrate on a few huge mega-instances, and you might as well have not bothered to move off twitter in the first place. If it's very easy for someone to exist both in their "home" node and in another node, the major disadvantages that come with being on smaller instances will fall away.

> Yes, to the extent to which clients and other hack-y behaviors do not solve this problem, what it means is that all the "spoke" timelines will die out and you'll concentrate on a few huge mega-instances, and you might as well have not bothered to move off twitter in the first place.

That's not what evidence is suggesting so far.