Skip to content
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

Closed
YukiSnowmew opened this issue Nov 25, 2022 · 6 comments
Closed

Unlisted posts with discovery enabled #21645

YukiSnowmew opened this issue Nov 25, 2022 · 6 comments
Labels
suggestion Feature suggestion

Comments

@YukiSnowmew
Copy link

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.

@YukiSnowmew YukiSnowmew added the suggestion Feature suggestion label Nov 25, 2022
@trwnh
Copy link
Member

trwnh commented Nov 26, 2022

"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)

@ddelabru
Copy link

ddelabru commented Nov 30, 2022

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.

@YukiSnowmew
Copy link
Author

"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)

@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 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.

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.

@mdingemanse
Copy link

mdingemanse commented Jan 8, 2024

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:

  • Live-posting e.g. in the form of live coverage of events, or of talks at academic conferences
  • Posting about objects (books, art, academic papers) that benefit from being discoverable but may be too niche to clutter timelines with
  • Hashtag games like #monsterdon #johnmastodon etc. (yes one can already mute tags, but a quiet+discoverable feature would turn the logic here from opt-in rather than opt-out, rather fitting the spirit of the fediverse).
  • Post threads where the current 'public first, unlisted next' convention makes hashtags and search currently useless for any posts but the first, which hurts discoverability
  • Topic-specific bots which most instances currently require to post as unlisted, which makes it nearly impossible to find out about them or about the content (including hashtags) they may post

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).

@trwnh
Copy link
Member

trwnh commented Jan 26, 2024

"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.

@trwnh trwnh closed this as not planned Won't fix, can't repro, duplicate, stale Jan 26, 2024
@mdingemanse
Copy link

"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:

Also, now it's dark in dark mode, and I've renamed the confusing "Unlisted" into a slightly less misleading "Quiet public".

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

4 participants