search

glitch-soc / mastodon

A glitchy but lovable microblogging server
https://glitch-soc.github.io/docs/
GNU Affero General Public License v3.0
709 stars 182 forks source link

Federation-specific visibility setting #1422

Open ClearlyClaire opened 4 years ago

ClearlyClaire commented 4 years ago

glitch-soc has local-only toots, which never leave the instance, but sometimes, one may want to have different visibility settings for a same content depending on whether it's for their core community (local instance) or for the wider fediverse.

For instance, people might want to post publicly for their own community (and appear in the local/federated timelines), but not attract reply guys looking at other instance's public TL : public on local instance, unlisted on remote ones.

Similarly, one may trust their local instance's users with private information, but only their followers from outside: public/unlisted in on local instance, followers-only on remote ones.

So, being able to set two different privacy settings could be useful, although it kind of conflicts with the local-only setting.

Database considerations

This should just be a new remote_visibility nullable column to the statuses.

We may or may not need a new index. Not sure about that.

REST API considerations

Viewing remote visibility

When serializing toots, this could be a new attribute, remote_visibility.

Posting with a remote visibility

When posting toots, this could be a new attribute, remote_visibility.

The backend could return an error if the status is local-only (ends with the magic emoji) and have a remote_visibility set.

The backend could also return an error if the remote visibility is higher than the local visibility.

When posting, without setting remote_visibility, a reply to a toot with a remote visibility set should have the remote visibility copied (if it isn't higher than the new local visibility) as to avoid accidental leaking from clients not supporting this extension.

UI considerations

I have no idea how selecting the federated visibility should work, nor how the federated visibility of toots should be displayed.

shaun-floss commented 2 years ago

I stumbled upon this issue because I am looking for this functionality:

public on local instance, unlisted on remote ones

Related to this comment:

So, being able to set two different privacy settings could be useful, although it kind of conflicts with the local-only setting.

I wonder if local_only could be kept in place, and a new field local_only_public could be added, which would mean:

local_only true and local_only_public false --> local, private, not remote (like it is now) local_only true and local_only_public true --> local, public, not remote (which would provide the new functionality referenced above)

if remote_visibility were to be added, I think there would still need to be a way to distinguish between local-only private and local-only public? :thinking:

Also, regarding this scenario:

public/unlisted in on local instance, followers-only on remote ones

This might not work, but just an idea - I wonder if that can be handled with a combination of a "Followers only" toot, local_only, and local_only_public?

Maybe I'm just complicating things, but just thought I would suggest some ideas, hoping this issue can get some traction! :crossed_fingers: :smiley: