Allow web users to view remote posts/follower/following lists inline in the web application, and at all in the mobile application

[SamStephens]

Pitch

Currently when you view a user profile from your local instance via the web application, you only see their follower/following that are visible to the local instance.

A link is provided, "Browse more on the original profile", that takes you to the users home server. However in doing so you leave the web application and are no longer interacting with that list using your logged in Mastodon identity.

Rather than this link, I suggest a link that will pull that list into the web application. This is a smoother experience for users, and allows them to interact with the list directly using their Mastodon identity.

The experience is even worse on the mobile applications. There you are simply told the person has a number of followers/followings, but when you click through, you only see the followers visible to your server, with no explanation of why the list you're seeing is so limited, and no way to see the full list of followers.

Motivation

The primary motiviation for this feature is that the existing behavior is a barrier to Mastodon usage for those who are not sufficiently technical to understand how identity does not carry across servers in Mastodon.

I witnessed this personally recently, when a family member started on Mastodon, found one of their friends, and then went to their following list to try and find other people they know. They were incredibly confused by the experience, and were ready to give up on Mastodon until I explained why they couldn't interact with the list using their identity, and how to easily copy and paste the link to each person into the search of their own instance.

If they had doing this on mobile on the other hand, I suspect they would have decided that Mastodon was buggy and given up on it entirely.

I believe the argument has been made that it's the responsibility of individuals to understand how federation works. My argument here is that it's very technical; not just involving the actual federated nature of Mastodon instances, but also technical details of how authentication cookies are scoped to a particular domain.

On this basis I argue there's an equity of access issue here. If we say that users have to understand Mastodon federation well enough to handle interactions that require them to navigate to remote servers, we are disenfranchising users that are not technical enough to work with the complexity of these interactions.

I believe this argument stands for all interactions that require you to navigate to remote instances - that they are a barrier to non-technical Mastodon users, that there's an equity of access issue.

There's also an equity of access issue in terms of the experience of mobile application vs. computers. By limiting the ability of mobile devices to interact with Mastodon, we're limiting the experience of those generally poorer people who only have access to the internet via mobile.

This feature has already been discussed and dismiss previously via https://github.com/mastodon/mastodon/issues/8301. However I think the arguments made against this feature deserve re-examining.

As discussed in that issue, there are two obvious approaches to solving this. One is via direct requests to remote instance. The other is proxying requests via the users local instance. My inclination is to go direct to remote instances, because it keeps Mastodon more scalable.

Querying the remote server directly from the user's browser is not safe in terms of exposing the user's IP address to a 3rd party.

But the alternative we're given is to follow a link to the users 3rd party instance, which also exposes our IP address to them. What difference is there in the security implications of a request from a web application, and a request made by direct navigation to the remote server?

Same goes for the trustworthiness of the content retrieved from a remote server. The current alternative is navigating your browser to the users remote server; where you are still having to trust that remote server to serve you trustworthy content.

Assuming a server does actually send back an untrustworthy response, you'll find out about that when you interact with the content, because interactions go via your local instance in a trusted fashion. If the remote server makes up a follower that doesn't exist, your follow request will fail. Etc.

Certainly I think that a note on the link to retrieve remote followers about trusting the remote server would be appropriate.

The REST API already has committments to certain response structures, like accounts having sanitized HTML fields, local IDs that can be used in other API methods, local avatar/header URLs, the loading of which would not expose the end-user's IP address to a 3rd party. If you were to skip processing and just repeat the JSON you got from the remote server, you couldn't have all that The remote server may not be Mastodon, so actually we can't even expect the Mastodon REST API format from it, we would be querying the ActivityPub JSON instead. Forwarding that to API clients would be completely unexpected

The other difficulties appear to be around having the applications deal with responses from remote servers and servers that may not be Mastodon. These are solvable problems, and I'm not convinced that they are a sufficient reason to block non-technical people from having an experience that they can easily understand and work with, and to block mobile users from the full Mastodon experience.

@nightpool has bought up the point that a better solution would be solving the difficulties of interacting with content on a remote server. That is fair, but it brings up complex issues of trust, and it would need to solve the issue for mobile, not just web.

Note that I previously lodged this as https://github.com/mastodon/mastodon/issues/20529, but my thorough misunderstanding of how the mobile applications behave made a mess of that issue, so I closed it and opened this one. Apologies.

[afontenot]

Several thoughts:

1. One thing that for me undermines the IP leaking argument a bit is that even as a technically proficient user, I have leaked my IP address to about a dozen different Mastodon servers in the last week alone. Usually because of this:

The two links shown here are the account name and the date (which functions as a permalink to the post). If you click on one of these, your click is intercepted by some JS and the post opens up in your local instance. But what if you want to open up multiple posts for later viewing? If you right click -> open in new tab, the "real" link takes over and bam you've just leaked your IP. Actually as far as I know there's no way in the current interface to easily get a link to the page that will view a remote post inside your instance. Interacting with posts is a major pain point, actually.

2. Gargron had something interesting to say in #8301:

Proxying the request to the remote server from within the request-response cycle puts a lot of strain on the server; if the remote server takes a long time to respond, it would DoS the server

This led me to wonder how it is that remote profiles get shown. Apparently they aren't proxied (else that would cause the DoS problem mentioned) and so presumably each instance is caching every remote profile it knows about and updating it when those profiles are edited / resaved.

So one potential solution to this problem that no one has mentioned is to cache follower information as well. If an instance is already sharing its social graphs publicly, then sending those graphs whenever they change is a pretty trivial operation. Even for users with enormous graphs (100k+), when compressed the data would probably be about the size of a single image, which instances share all the time. You could limit updates to once a day or so per profile.

Anyway, this would obviously solve the problem because if each instance knew the social graph, it wouldn't have to do a proxied lookup (or force the user to reveal their IP address) when showing a followers list.

3. I think the bigger unrecognized problem here is probably social. A lot of people really like the isolation and privacy that federation creates, even if it results in problems like this one for people who are expecting a more traditional social network. Plenty of instances don't share follower information, and in that case there's nothing Mastodon can do here - that information will always remain hidden. In fact, a move like that proposed here, where follower lists are much more visible, might cause a backlash where even more instances hide social graphs from public view. In other words, it might make the situation worse.

[SamStephens]

@afontenot said:

One thing that for me undermines the IP leaking argument a bit is that even as a technically proficient user, I have leaked my IP address to about a dozen different Mastodon servers in the last week alone.

It's a good point, but I think it's an even stronger argument that the link we are currently given to discover remote statuses/follower/following lists leaks information in exactly the same way.

Actually as far as I know there's no way in the current interface to easily get a link to the page that will view a remote post inside your instance.

This has been a major pain point for me, because my normal behavior on social media is to open tabs as I find interesting posts/people to look at. And I think it's just semantically wrong that these links present themselves as links to external servers when they're actually links to internal states within the web application (based on the behavior when you click them). Would you believe I've opened https://github.com/mastodon/mastodon/issues/19652 about this issue 😁

This led me to wonder how it is that remote profiles get shown. Apparently they aren't proxied (else that would cause the DoS problem mentioned) and so presumably each instance is caching every remote profile it knows about and updating it when those profiles are edited / resaved. [...] So one potential solution to this problem that no one has mentioned is to cache follower information as well.

So this is interesting. Because lets say we do cache follower information. What if I click on a user in that follower list?

Either instances cache every user in the Fediverse; or we accept that there is some limit where you cannot discover people who have not been cached on your instance; or there needs to be a mechanism for realtime look up of users your local instance does not currently have cached (and the same goes for statuses).

I don't think we can get away from solving the problem of a clean way of viewing the Fediverse outside of your instance's cache.

I think the bigger unrecognized problem here is probably social. A lot of people really like the isolation and privacy that federation creates, even if it results in problems like this one for people who are expecting a more traditional social network.

I think that's perfectly okay. The Mastodon client can just provide a message "This user's posts/followers/following are private/only visible to their followers". It's easy to understand, and people are used to this kind of privacy control from other social networks they've used. Better that than the experience users currently have where on mobile where they see a mostly incomplete list and no explanation of why it's incomplete.

[afontenot]

Either instances cache every user in the Fediverse; or we accept that there is some limit where you cannot discover people who have not been cached on your instance; or there needs to be a mechanism for realtime look up of users your local instance does not currently have cached (and the same goes for statuses).

What happens currently when I search for user@federatedinstance.something in the search box, and click to view the user's profile? Either (a) the profile data is already cached and displayed immediately by my instance, or (b) Mastodon has to dispatch a request on my behalf immediately to the user's server and request the profile data.

I haven't verified this but I believe the answer is probably "both". Mastodon caches a whole bunch of profiles locally (e.g. if any user on the local instance follows the user, it gets cached), but also if you search for a user the instance has never heard of, it tries to look it up immediately.

My suggestion is just that Mastodon should treat follower data the exact same way it treats any other kind of profile data. For the vast majority of users this data will be smaller than e.g. the header image displayed on their page. Caching it would probably not be an unacceptable amount of overhead.

[desperadosec]

I think the bigger unrecognized problem here is probably social. A lot of people really like the isolation and privacy that federation creates, even if it results in problems like this one for people who are expecting a more traditional social network.

While this is certainly true, I think someone who clicks on a profile and then followers/follows isn't looking for isolation, they're looking for discoverability. Along the same lines, someone with a public profile is probably looking for bigger reach, not privacy.

[afontenot]

I think the bigger unrecognized problem here is probably social. A lot of people really like the isolation and privacy that federation creates, even if it results in problems like this one for people who are expecting a more traditional social network.

someone with a public profile is probably looking for bigger reach, not privacy.

Not necessarily. There's not much flexibility at the moment to separate "public to my instance" (good for someone who wants to make friends) with "public to everyone", which is where you could start having a harassment problem. I do want to see a solution here though, even if it means that some instances hide their graphs from public view entirely.

[SamStephens]

Not necessarily. There's not much flexibility at the moment to separate "public to my instance" (good for someone who wants to make friends) with "public to everyone", which is where you could start having a harassment problem. I do want to see a solution here though, even if it means that some instances hide their graphs from public view entirely.

Any information that was exposed would already be visible by going to the users public profile on their own instance though right? If so, I don't see that making it less cumbersome for users on other instances to see the users already public information actually changes their privacy exposure, does it?

I'd argue that people who would hide their graphs from public view entirely once this feature was implemented should already have their graphs hidden; that what they have now is an illusion of privacy.

[afontenot]

Any information that was exposed would already be visible by going to the users public profile on their own instance though right?

No, quite a few instances don't allow you to see profiles unless you're logged in. I'm not sure if that's always up to the instance or if it's a user setting (some instances are running a fork of Mastodon with other features so it's hard to know).

I'd argue that people who would hide their graphs from public view entirely once this feature was implemented should already have their graphs hidden; that what they have now is an illusion of privacy.

That's true of a lot of things on Mastodon, including the apparent lack of searchability.

[SamStephens]

@afontenot :

Any information that was exposed would already be visible by going to the users public profile on their own instance though right?

No, quite a few instances don't allow you to see profiles unless you're logged in. I'm not sure if that's always up to the instance or if it's a user setting (some instances are running a fork of Mastodon with other features so it's hard to know).

If instances don't allow you to see profiles unless you're logged in, that's equivalent to only allowing users of that instance to see followers, following, and non-recent statuses? If so, this feature could reflect that.

I'd argue that people who would hide their graphs from public view entirely once this feature was implemented should already have their graphs hidden; that what they have now is an illusion of privacy.

That's true of a lot of things on Mastodon, including the apparent lack of searchability.

Good call.

[Trif4]

From a pure UX perspective, of course you should be able to view followers/followings without leaving your instance. I think that's a function that any user would expect, and when they discover that it's missing, many will get the feeling that Mastodon is still very incomplete.

Regarding isolation, ultimately it's up to the remote instance whether or not to offer the information. The burden of protecting access to the data doesn't lie on the client trying to access it.

As for leaking IPs, something like "Allow for federated.something/Allow for all instances/Deny" would give the user control.

[desperadosec]

I think that's a function that any user would expect

So from a philosophical perspective, I think it's okay to deliberately avoid giving the user what they expect, for example:

That's true of a lot of things on Mastodon, including the apparent lack of searchability.

It may be a valid intentional design choice. See for example, people who search all of Twitter for a topic just to yell at strangers about it in replies. I think one could make an argument that this prioritizes subjects over people, and has potential negative consequences. (There are certainly positive ones too, about finding people outside your friend/demographic bubble.)

The two things I don't agree with are the "engineer's interface" like the two-knob sink faucet: it's technically simpler to simply attach a valve to each pipe, but results in a far worse experience for the end user to have to do more work to get what they want. Following someone on another server should be easier, and if the notion of federation is about building webs of trust and social links the way humans naturally tend to, then it should be implemented despite the added technical complexity.

[afontenot]

That's true of a lot of things on Mastodon, including the apparent lack of searchability.

It may be a valid intentional design choice. See for example, people who search all of Twitter for a topic just to yell at strangers about it in replies.

That's true! I'm not advocating that a search feature be added to Mastodon and I think it might have the negative consequences you suggest. My point was only that many people on Mastodon treat the lack of search as a privacy feature when it absolutely is not one. Someone set up a working search engine just the other week but shut it down after receiving complaints. The next person to do so might not be so considerate.

[JustusW]

With so many people (including me) coming from a centralized system like Twitter this is highly frustrating. Decentralization is a nice thing, but it only works if there is User choice. I cannot join the server many of my friends are on. Mastodon.social has closed down registrations. So now I have no other option than to be separated in a significant way from a relevant group of my peers and vice versa. I have chosen a climatechange based community, but realizing that my direct social connections are irrelevant to how instances interact has basically made me stop using Mastodon again.

[SamStephens]

@JustusW please open a separate issue for this, rather than hijacking this issue. Your problems are not to do with follower list behaviors from what you have said.

[naught101]

@SamStephens they clearly are. @JustusW can sign up anywhere, but their friends are on another server, so if they visit their friend's accounts, they can't see the majority of their follower list. That is precisely what this issue is about. Since more and more of the initial servers are temporarily suspending sign-ups, this is going to be a problem for more and more new users, and is going to rapidly degrade the initial user experience for anyone not willing to dig deeply into how to bootstrap your following list.

[srkunze]

I am also in favor of this feature. As I try to recollect my friends and acquaintances across all servers, I do not want to switch to a complete different website (in terms of navigation).

IMO federation is a technical thing, thus it needs to be a visible/noticeable feature only when you want to make use of it.

[MrMAB]

I found myself frustrated by this - trying to rebuild my network (and in the light of today's policy shift from twitter....)

At the very least, the link to see followers should link to their profile in a browser, even if the list cannot be retrieved automatically.

[sitetherapy]

Count me as another vote for this. I can see the argument that a given server might want to be able to disallow this as I can imagine it being used for harassment by less savory people. But it makes finding others more difficult and I'm not convinced by any of the counter arguments which have a feel of 'well, that's what we've always done' to them.

Here's my example. I'm a web developer. Several of the more influential folks in the field setup an instance at https://front-end.social. A few people there are are people who I followed on Twitter and I can follow those people on Mastodon easily, but I'd like to build a list of others on that server and/or the people that some of them follow. So why not move my account there? Well, it's a small instance and they've understandably closed registrations so I can't do that.

[distantnative]

The argument of isolation presumes that our social identities mostly belong to just one group/federation. Which can be the case and such a group might decide not to allow easy discoverability. That's ok.

But for most of us, picking an instance is just one of the many groups our social identity belongs to. That's why we need to federate to be connected to all our friends and contacts. And that's why we need to find and discover them across instances.

I think it is very clear that this missing feature is a flaw right now for the whole system. And solutions how to handle those instances that want to be a bit more protective have been outlined above.

[jzandin]

If you really need to keep your IP address hidden from untrusted third parties, I assume you already use something like TOR or a commercial VPN service, which can then hide your request for followers too.

So I don't think that particular use case should stand in the way for making Mastodon useful for the remaining 99.9%+ of the users.

And you can always make it possible to disable requests to third parties and even make it opt-in instead of opt-out.

[noahdsmith]

Agree that this is a significant barrier to new and less savvy app users. At the very least (and in the short term) an explanation in the app is needed.

Beyond that, if the alternative is the user opening a profile in a browser, could following someone on another server while in the in-app browser be made simpler?

[andreynering]

As a user, I also miss the ability to see likes/favorites of posts from users in other instances.

[FediVideos]

Any progress on this? Just had feedback from new users confused about why they can't see people's followers on their own server, but can see it if they open the remote page. It's thoroughly confusing because the information seems to be out there in public, and they don't understand why it isn't being used by their own server.

[graham73may]

New-ish Mastodon user here, when I was using an account on a large instance I didn't even realise this was a limitation.

The main way I'm trying to get my feed up filled with content is by finding people I want to follow and then checking out who they follow (this is usually pretty successful). Looking back now at all those times where I see "Following 500" on a profile and I thought "well that didn't take very long to scroll through their followers" now make much more sense... I was probably only seeing 100 or so local accounts.

The whole "only view local followers" problem is amplified tenfold when you're self-hosting (you just see none at all) or on a smaller instance, you see a small portion.

• On a separate note, the web interface has a handy link to view the followers on the remote instance, the Mastodon iOS app does not have the helpful link, it just says no.

If I want to find a profile, I can search for their username and that is queried from the remote instance, perfect - that's exactly the behaviour I would expect.

Maybe it's the way I use the followers feature but when I'm viewing follower information I'm basically doing the same thing as when I'm searching for a username in the search box. I'm trying to discover new accounts to follow. (What other purpose does a public follow list even serve if not to connect with other users?).

I love the concept of federation, I love the idea of being able to self host and "own" my content... but the amount of features which are actually local-instance-only when you dive deeper feel like quite a big drawback (and I'm questioning whether to continue self hosting or not).

[o76923]

I'll add that the current system provides a strong incentive for a user to create accounts on large instances instead of smaller ones. When I click the profile of someone that I'm loosely connected to, I might only see 4/150 followers because that's all that's locally cached. But if I were on a bigger instance, the odds that at least someone on it would have interacted with instances those other 146 users are on.

I think it's bad practice to incentivize centralization that strongly especially for a feature so critical during onboarding.

[brendanjones]

Looks like this is duplicate of https://github.com/mastodon/mastodon/issues/19880, though that reports the issue as a bug, which it's not really, just a missing feature.

If the concern is too many requests or something like that, this issue could be partially solved by filling the follows/followers list when you follow the account, e.g. when https://github.com/mastodon/mastodon/issues/34 happens.