-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unlisted posts with discovery enabled #21645
Comments
"Discoverable" == "Public". I'm not sure it makes sense to opt into public timelines and hashtag timelines separately... at the very least, you'd need two discoverable flags. Or to somehow split it so that "discoverable" is a flag that can be applied on top of either Public or Unlisted (which would need to be renamed) |
I made a similar suggestion for a new visibility setting here: #5463 (comment) However, the name I proposed for this visibility option was "Quiet" or "Taggable". I imagine it being another option at the same level as "Public" or "Unlisted", not an additional control that would layer over existing visibility options. That's also how I interpreted @YukiSnowmew's proposal, for what it's worth. What @trwnh suggests sounds like it would involve more of a multi-select interface for visibility settings. I don't really know what other "discoverability" features are applied to Public that aren't applied to Unlisted, aside from local and federated timelines and hashtag searches. But I do see strong use cases for opting out of local/federated timelines while separately opting into hashtag searches. For example, if I were liveblogging an event or promoting my niche artistic work to people interested in the genre and didn't want to spam uninterested people with posts about it, I might want to opt out of local/federated timelines. But I absolutely would want to opt into hashtag searches for such liveblogging or tactful self-promotion, so I can specifically reach the people who are interested in that topic. With the recent Mastodon+fediverse influx from changes at Twitter, I've noticed a lot of new users learning the visibility options. And I've seen some of those users suggest to each other, erroneously, that they can use Unlisted to avoid spamming people about self-promotion or niche topics while still appearing in hashtag searches. I think it's too late to make Unlisted posts work that way because it would mess with the privacy of users who are used to intentionally hiding their posts from hashtag searches with Unlisted. An added option in the post visibility categories seems like a more considerate way to implement this functionally that users think is already available. |
@trwnh, "Discoverable" =/= "Public". Discoverable opts out of the public (and perhaps federated) timelines while allowing posts to be searchable via the search bar or discoverable via hashtag. Public does not work this way. Public posts appear on the local timeline. Currently, it is impossible to keep relevant posts off the local timeline while retaining discoverability. @ddelabru's proposal seems pretty much identical to what I've proposed. A new visibility setting for posts to opt into discoverability features, but out of the local timeline. I also agree with the use-case they mentioned. Spamming the local timeline with livestream notifications, for example, may get annoying or simply be against the rules. But discoverability is still important for a livestream! If we can't post publicly due to instance rules or fear of annoying people, we're stuck with unlisted posts. But unlisted posts opt us out of discoverability via hashtag and search, which makes an unlisted livestream notification post nearly pointless. This also has the potential to hurt artists who rely on discoverability, but don't produce art that their instance is necessarily interested in. Or perhaps, they need to upload many pieces at once and simply don't want to spam the local timeline. Again, the only option is unlisted, but unlisted makes those pieces undiscoverable.
I believe you can perform full text searches on public posts on your instance, but unlisted posts are opted out of that, too. I could be wrong here. |
Strongly support this proposal. @YukiSnowmew's "Discoverable" or @ddelabru's "Quiet" would both be good names, and infinitely better than the current "unlisted" which is clearly confusing the hell out of people and which is not fit for this particular purpose. A setting for quiet discoverability is extremely useful to avoid cluttering main / home feeds while still posting stuff that others (not just followers or those who happen upon your profile) might have a specific interest in. The compelling use cases I've seen (that don't work right now) include at least the following:
Because unlisted is used by at least a subset of users as a kind of stealth mode, and has a very confusing name anyway, I think the most graceful and useful option would be to add this as a new post visibility mode just as OP suggests (though the current title is confusing). This would also make it independent from debates about whether unlisted is going to continue to exist (as some note, its removal from the 'official' mastodon apps definitely suppresses its use and people understanding of it so that may be a prelude to deprecating it). |
"Unlisted" has been renamed to "Quiet public" in the latest commits. There is also a tooltip that explains exactly where it will not show up. |
Oof. For the curious, here's the commit with @Gargron's words:
Worth noting that Gargron's post is edited from Low-key public to Quiet public in response to comments on that PR two days ago. Have to say I'm not impressed by the low-key public / quiet / unlisted nature in which these changes are wrapped into an unrelated pull request without any reference to prior thoughtful contributions. In this respect I agree with @tsmethurst here that it is "procedurally very odd". A reason for me to stop engaging. |
Pitch
We currently have multiple options for post visibility, including unlisted. This stops your post from showing up in the local and federated timelines, but also opts the post out of discovery features, if I understand correctly.
So, I propose a new post visibility option: discoverable.
A discoverable post is one that does not show up in the local feed, but can be discovered via hashtag, search, or whatever else.
Motivation
This feature would provide more nuanced control over post visibility, which benefits all. In particular, instances may not allow certain types of post on their local timeline, but do allow them elsewhere.
For example, an instance may ban political posts from their local timeline. The user's only remaining options are unlisted, followers only, and direct. All of these options opt the post out of discovery via search and hashtags.
For this reason, I believe the proposed discoverable visibility option is necessary. It would allow discoverability while adhering to the instance's content rules.
The text was updated successfully, but these errors were encountered: