Removal of global federated feed and/or local instance feed
walking mirage
Public
Seen by 43
I am seeing varying opinions on whether we should remove the federation feeds, or both the local and federation feeds. I will update this thread as we collect pros and cons; my own opinion is in a comment, and I am starting based off that and recent conversation in Discord.
Pros of allowing federation feeds:
Having a global view of the network would enhance discoverability and allow a larger audience for people with few followers; having a view of the network as a whole might make it feel more alive, especially for people new to the system.
People used to Mastodon may expect them.
Cons of allowing federation feeds:
Global feeds have presented a harassment vector in the past. For Cohost, the opt-in global feed tag was used to harass others by tagging them into it; staff had to place restrictions on the tag system as a whole to prevent this.
Global feeds create an artificially connected overlay in the social graph of the site's userbase. On Mastodon, if you post something, there is a 100% chance that people who don't know you and don't know anyone you know are going to see it; if any of them have a problem with you or your post, they are free to start conflict over it. Without the federated feed, they would never have seen the post and been bothered by it.
In the same fashion, any conflict that is caused by a post's visibility on the global feed by necessity becomes an inter-instance conflict; while intra-instance conflicts can be resolved by moderators, inter-instance conflict would necessitate the involvement of the Stewards, and presumably whatever conflict-resolution process we come up with, potentially increasing our workload significantly. (Side note: we will need to come up with a conflict-resolution process regardless.)
Cohost didn't have them (having identified them as a dark pattern), and we said we'd be avoiding dark patterns in the same ways that Cohost did.
Conflict spreads rapidly and uncontrollably when everyone can see everyone else's posts
Pros of allowing local (instance) feeds:
Could be a choice given to instance moderators; if a local feed causes problems, they can be disabled.
Might work well with the nature of an instance as a small community, promoting local social connections; the League is a collection of small communities, not one big community. Allows users to see what else is going in in their instance, and affords some degree of discoverability.
More likely to work well with the "reasonably small instance" norm we appear to have been trying to set.
Making an instance feed viewable to the public would allow users to get the vibe of an instance, or of the League in general, while deciding if they want to join and where they want to go.
Cons of allowing local (instance) feeds:
Could still increase instance moderator workload somewhat should they cause conflict or be used for harassment.
walking mirage Fri 11 Oct 2024 5:43AM
@nora i think we should (collectively) figure out how we can do that.
nora Wed 9 Oct 2024 2:38PM
@walking mirage I absolutely agree with both of your major points here. In GoToSocial, at least, "Unlisted" (not on feeds) is the default, so we've got that already.
If we want instances to be communities unto themselves, we need to do more to explicitly facilitate and promote that, imo.
walking mirage Wed 9 Oct 2024 4:54AM
@nora The "fewer posts on it" part is the crucial part, especially if it's opt-in. If we continue to push for small, manageable instances as we have been, it helps put a damper on conflicts that embroil the entire network. Context collapse isn't the only problem we're trying to fight by removing federated feeds; the fact that conflicts and discourse can spread like wildfire is another, and (imo) just as important.
that last option is what folks generally seem to be leaning toward (I have not done a poll on this). the primary point of a local feed isn't for discoverability, it's for allowing an instance to function as a community.
i really don't like the idea of a site dropping off the network, for whatever reason (dissatisfaction with how things are going, or the entire project coming to a close, etc), and suddenly all that's on there is a bunch of disconnected users who have never been in the same "space" before. that's not a community, it's a dead website.
they do have their disadvantages, including the lesser context collapse issues, but that's why they're optional. turning them on doesn't run as much of affecting the network as a whole; it increases small-scale connectivity between users without directly affecting large-scale.
we should consider having "not on the local feed" be either an obvious option or the default if we're going to have them, though.
nora Fri 4 Oct 2024 1:48AM
I have some concerns about our current policy based on user feedback I've seen and my personal experience. To ensure we're all working with the same framework, I'll start with some annoyingly exhaustive definitions of terms.
An instance A's Federated timeline shows posts which are:
- 🌐Public visibility, AND ANY OF
- Posted by user of instance A OR
- Posted by anyone followed by a user of instance A, OR
- Boosted by anyone followed by a user of instance A (including a boostbot
like FediBuzz), OR
- Manually federated by a user of instance A (e.g. by searching for the post's
URL in the search bar), OR
- Federated over via a relay.
An user of instance A searching for a tag T will see posts which are:
- 🌐Public visibility, AND
- Tagged with tag T, AND ANY OF
- Posted by user of instance A OR
- Posted by anyone followed by a user of instance A, OR
- Boosted by anyone followed by a user of instance A (including a boostbot
like FediBuzz), OR
- Manually federated by a user of instance A (e.g. by searching for the post's
URL in the search bar), OR
- Federated over via a relay.
An instance A's Local timeline shows posts which are:
- Public visibility, AND,
- Posted by user of instance A
The core of my concern is this: unless we do something explicit to make individual instances act as communities, for example by making them invite-only (which I think we have already identified as being problematic), the only difference between a local timeline and a federated timeline is that the local timeline will have fewer posts on it.
I don't think this meaningfully reduces the risk of context collapse except in that it prevents arguing over whether instance A's rules should be applied to posts from other instances. This is a big deal on The Fediverse, but in leaguespace we have the ability to actually make decisions that harmonize rules between instances, so I think that difference is comparatively irrelevant.
I do think that this makes the local timeline much worse for discovery, because the only posts users will see there are selected essentially randomly (again, unless instances are actually pushed as communities, which we are not currently doing) and will by definition be a small subset of posts on the network that were intended to be available to everyone (so marked by 🌐Public visibility.) I also think that having only local feeds makes the moderation burden seem lower at first glance, without actually reducing the overall moderation effort required, except insofar as poor discoverability leads to fewer interactions.
While Cohost showed that a global feed with one moderator for tens of thousands of users doesn't work, I don't think it proves that a global feed with one moderator per tens or hundreds would be similarly fated to fail.
In other words: I think the local timeline is just as bad for context collapse as the federated timeline, and worse for discovery. We should choose one of:
- allow both
- ban both
- allow both until we have tag visibility fixes at which point we ban both
- allow only local and make some kind of steps towards making instances feel more like communities unto themselves
My recommendation is to allow both for now and then ban both once we have universal adoption of relays and working tag aggregation so people can do discovery that way
Lobo Torres Thu 3 Oct 2024 3:31PM
Against federated feeds
Local feeds are good, but feel to me as more of a makeshift solution while we try to figure out the discoverability issue for tags. Once we have that problem solved we shouldn't need any sort of feeds IMHO
muffin j. lord Thu 3 Oct 2024 7:01PM
@ankiolyne i pretty much agree, but I think it will be even harder to turn it off if we use it as a temporary measure than if we just quash this now. I think local can really help if your server is you and friends or people with the same general interests, but part of that relies on the servers staying relatively small - if they become triple-digits massive, it'll be just as bad and no help to anyone.
ankiolyne Thu 3 Oct 2024 3:33PM
@muffin j. lord yeah-- honestly i am of the opinion the only compelling case for a global feed (maybe local to a lesser extent) to exist is as a stopgap for functional tags
muffin j. lord Thu 3 Oct 2024 2:40PM
Whatever we decide to do, we need to decide it and then stick to it. With patches already going live for Gotosocial, it's becoming imperative that we're all on the same page about this.
I'm still against the global feed, and I still think the local feed should be left up to node staff discretion. I'm not convinced that the federated global feed is all that good for discoverability, honestly, and if we can get a solution in place for a central tag repository then in my mind that should be sufficient.
CMO CYCLAR·2 Thu 3 Oct 2024 6:56PM
@sirocyl no, actually, it was the federated feed that they wanted
wenchcoat system · Tue 15 Oct 2024 7:29PM
@walking mirage missed this prior, agreed on all points re: local feeds good actually; to me they're how we create a community from a node.
I'm gonna argue that they should be on by default though: the main case for disabling is "node so big it's the firehose again" which, as you mention, we're trying to minimize anyway. (and as a short-term concern on the technical side, changing states is currently non-trivial on both GTS and Akkoma; no easy toggle, requires adding or removing a source patch.)