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

Feature requests: Opting out of feeds and viewing which ones are showing my posts #28

Open
eepynet opened this issue Jun 26, 2023 · 4 comments

Comments

@eepynet
Copy link

eepynet commented Jun 26, 2023

I need to be able to opt out of feeds. Ideally, I'd be able to opt out of all of them and selectively opt back in to certain feeds. It's going to be an important safety feature for users to be able to opt out of specific feeds if it's enabling harassment against them or other bad behavior. I'd also love to know what feeds my posts go to and I think this would not only mitigate privacy surprises, I think it would be a great way for feeds to be discoverable.

Privacy Surprises

No other platform has anything like custom feeds so it's important to note that new users aren't going to have any experience with them. That can cause privacy surprises: where you didn't expect something you posted to be seen by a lot of people. This is usually harmless, but there are cases when it can be bad.

For example: people posting sensitive images like nudes. The suggestive feed has actually implemented opting out independently with the !no-promote tag. Unfortunately, new users won't find out about that unless someone tells them or if they post a nude and wonder why so many strangers saw it.

There are other (less bad) examples I can think of, like if you posted a picture as a reply not really meant to be seen or shared widely but the cat is in the background so it goes in the cat feed and gets seen by hundreds of people. There's also the Newskies feed which I think is great, but you do see people surprised that their first post is so visible.

One way to handle new users not knowing what feeds are out there is to have visibility of what feeds a given post is appearing in. Didn't know there was a nudes feed? Well, if you posted a nude and instantly got a notification that says "added to feed: sexy bluesky bitches", you would find out within minutes rather than hours. If you were getting a lot of rude comments on a specific post, you could check what feeds it ended up in and block the one that's sending all the hate your way.

It would also be a great way to discover new feeds and connect with others who share your interests!

I'm not sure if I would prefer something like the Twitter post analytics or if it would make sense to do it via notifications. On one hand, the notifications could get noisy, but on the other hand having a visual that tells you when a post was added to a feed and what notifications came after it could give good context for deciding which feed to block.

Bad Behavior

Opting out of feeds I think could mitigate a lot of the potential for harm in them.

I wouldn't be the first to point out that feeds will be used to make lists of users to turn hate mobs against. I'm aware that the nature of the internet makes completely preventing this behavior impossible, but I think there's a lot of power in what default tools are available. Maybe opting out of feeds won't stop kiwifarms, but I'd rather they had to make their own custom tools rather than use what's available by default.

Aside from simple harassment campaigns I think feeds have the potential to enable a lot of bad behavior. One example I can think of is a "Ratio" feed: posts that have significantly more comments than likes.

Opting Out of Virality

One thing that makes twitter unsafe is that the algorithm can look at a post that was popular with a user's audience and decide to share it widely outside of their circle. Custom feeds have already exhibited this exact behavior.
For example:

  • a group of experts discussing a nuanced topic (like race, gender, scientific topics relevant to political issues). Taking these discussions and putting them in the center of the public square invites non-experts to comment and take the discussion out of context. I can think of several examples of people who have endured years-long harassment campaigns because of this sort of app behavior.
  • harmless cringe that appeals to the user's social-circle but anyone else outside of that could see the user as a target for bullying. For example, kids drawings (usually fanart of popular video game or cartoon characters) going viral because of people making fun of them for being kids who don't know how to draw very well yet.
  • discussions of sensitive topics among users who are comfortable with it can end up in front of users who are not. An example is users on twitter/tumblr talking about themes of violence in media having their posts interpreted as promotion of violence and harassed accordingly.

The ability to opt out of virality is something that I think could prevent a lot of harm. Platforms normally expect that if users don't want to be fully private, then they must be trying to get as much attention as possible. In reality, neither one of these modes is what most people want. We have the opportunity to design for the in-between: giving people control over the discoverability of their content while still allowing them to make connections.

Concrete Proposals

Any of the following features would help:

  • opt out of all feeds
  • opt in to all feeds by default but opt out of specific ones
  • opt out of all feeds by default but opt in to specific ones
  • take a specific post out of feeds and show only to followers. Like a checkbox that says "allow in custom feeds"
  • view what feeds your posts are shown in.

My protocol knowledge is limited so I have no idea how feasible this all is! Hope you consider it. This is really long and I didn't get it proofread.

@sneakers-the-rat
Copy link

+1, this is a fundamental question of safety on the protocol that is linked to many other currently open issues here.

I would be really interested to hear the devs opinion here because from what I can tell this would be effectively impossible in the current federation draft - to block feeds, you would need to be able to block big graph servers. Otherwise, you might specify that you are blocking a particular feed, but someone running an adversarial big graph service could just ignore that and send it to the blocked feed generator anyway.

OP mentions being able to tell which feed displayed your post that allowed someone to see you, which is a good idea in some contexts but a privacy concern in others, and from what I can tell this would also be impossible by going out of protocol - my post is included in some relatively innocuous seeming list, someone I have blocked is following that list from a different DID, and rather than interacting with it via that list I do a direct search for the post and interact with it directly from my (burner) PDS.

This is especially a problem since most people are expected to get their posts from feed generators, right? So you might be able to opt out of the big indexing services, but if everyone else is looking at feeds generated by the indexing systems then I become effectively invisible. Only people specifically looking for posts directly from private PDSes would be able to see me, but for that would I need to be able to construct feeds locally (rather than downstream from a BGS)? how would that work?

@eepynet
Copy link
Author

eepynet commented Jun 26, 2023

Thanks for the response @sneakers-the-rat !

to block feeds, you would need to be able to block big graph servers

I just want there to be a good default that well-behaving services respect. Even just metadata at the post level that says "hey! This post shouldn't go in feeds!" would be enough for me. That signal could be used by any party in the chain from the feed generator to the PDS or even the client. I'm talking about building a social norm more so than an airtight security system.

OP mentions being able to tell which feed displayed your post that allowed someone to see you, which is a good idea in some contexts but a privacy concern in others

You mean revealing what feeds someone is browsing? I think as long as everyone knows that this information is accessible it's fine. Likes are public anyway. Was there another situation you had in mind?

@beholdnec
Copy link

@sneakers-the-rat You bring up a lot of points related to "What happens if a server misbehaves?" It's a good question to ask. I think the intention is the misbehaving servers will be caught and cut off from the network. It's a little unclear to me what this looks like in practice.

Will misbehaving servers still be able to view our posts? Suppose if there is an "evil" server that allows people to reply to posts when they shouldn't be able to, thus breaking Bluesky's "social contract". As long as the evil server is gated off, then I suppose it isn't much different than someone posting a screenshot of your skeet on a different website.

@sneakers-the-rat
Copy link

Yes. Part of what I'm suggesting here is that the design of atprotocol seems to make it very difficult to protect oneself from bad actors, and the lack of clarity re: what that looks like is a big problem. Who gates off evil server? How? From who?

I'm talking about building a social norm more so than an airtight security system.

Totally, the network doesn't have to be totally airtight from abuse, which is arguably impossible given the conflicting constraints of public communication and safety, but its design seems mostly designed with a centralized context in mind, and if the current draft of the federation component of the protocol is implemented relatively unchanged then it seems much worse than airtight.

I think as long as everyone knows that this information is accessible it's fine. Likes are public anyway. Was there another situation you had in mind?

this is basically the question - is everything necessarily completely public, with no practical means of privacy on the network? agreed clear ux signaling would be necessary in any case. If someone expects a block to actually function as a block, and the ux encourages them to believe that, big problem.

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

No branches or pull requests

3 participants