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

custom federation levels (at the very least, for private posts) #712

Closed
hoodieak opened this Issue Apr 1, 2017 · 12 comments

Comments

Projects
None yet
9 participants
@hoodieak

hoodieak commented Apr 1, 2017

pretty much every user i've seen around who makes use of private posts wants the option for them to federate

i understand that there was backlash over this when it was implemented, but i think having it be opt in is the best option

i would suggest either making this only a decision you get to make RE private posts, or a seperate choice for private posts and other posts.

example: many people would not mind sending their unlisted posts anywhere, but, the same person might not trust a non-mastodon instance in the federation to handle their private posts.

regardless, the option should have three choices

  • do not federate
  • federate to mastodon instances
  • federate to all instances

  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
@rogerbraun

This comment has been minimized.

rogerbraun commented Apr 4, 2017

What's the reasoning behind "federate to mastodon instances"? Seems like a weird distinction.

@Fidgetcetera

This comment has been minimized.

Fidgetcetera commented Apr 4, 2017

Non-mastodon ostatus implentations may not implement certain features the same way, such as private posts not being able to be boosted. It's inevitable that if someone from a non-mastodon ostatus instance saw a post not distinguished as private, because their own instance doesn't have the feature set, they'd boost/reblog it. Federating only to mastodon instances is a bit of a safety bubble against those kinds of unwanted circumstances.

@rogerbraun

This comment has been minimized.

rogerbraun commented Apr 4, 2017

So this is to avoid accidents? Because nothing would stop an instance to just ignore those rules.

@Fidgetcetera

This comment has been minimized.

Fidgetcetera commented Apr 4, 2017

Being able to choose not to federate to instances which don't use mastodon specifically would certainly help prevent it.

@rogerbraun

This comment has been minimized.

rogerbraun commented Apr 4, 2017

What I mean is, any instance could just pretend to be mastodon, or could run a modified version of mastodon that ignored the restrictions. So having a setting like this could prevent accidental reposting, but not a true bad actor.

@Fidgetcetera

This comment has been minimized.

Fidgetcetera commented Apr 4, 2017

That's absolutely true, but it's easier to spot and block a bad actor instance than an innocent well-meaning but completely different instance that doesn't implement features correctly.

@hoodieak

This comment has been minimized.

hoodieak commented Apr 5, 2017

can't this be mitigated with a list of trusted truly-mastodon instances, implemented using public keys? they all have them already because of HTTPS

@yiskah

This comment has been minimized.

Collaborator

yiskah commented Apr 10, 2017

On the topic of private post federation, one solution would be to implement on the instance-level a list of "trusted" domains which that instance knows it's safe to federate to. This could get around some of the technical limitations while not making the posting UX too technical.

@hoodieak

This comment has been minimized.

hoodieak commented Apr 14, 2017

note mostly just for myself / anyone curious, this, as i understand it, relies on #1557

@evanminto

This comment has been minimized.

Collaborator

evanminto commented Apr 16, 2017

I agree that it's a little weird (and possibly against the spirit of federated networks) to give preference to instances of the same application, but to my knowledge no protocol (almost certainly not ActivityPub) has a protection against bad actor services that are willing to break privacy rules and repost private posts.

@yiskah's solution seems the most solid to me. Rather than have Mastodon as a whole prefer its own instances, each instance can maintain its own list of trusted domains. This is a pattern that could potentially be replicated by other platforms as well. My only worry would be if every platform has thousands of instances, no one will be able to manually maintain a list of trusted domains, but there are ways to solve that too (a centralized registry of trusted domains, for example).

@LogicalDash

This comment has been minimized.

Contributor

LogicalDash commented Apr 16, 2017

If we get an interface for unprivileged users to add and block instances from their home timeline, as in #423, it would make sense for that same interface to handle federation levels, so that the user can decide which instances they personally trust to keep toots private. I think this should be a strictly opt-in feature per-user.

abcang added a commit to pixiv/mastodon that referenced this issue Dec 18, 2017

Merge pull request tootsuite#712 from pixiv/hashtag
Remove redundant redux store reference in hashtag_timeline
@Cassolotl

This comment has been minimized.

Cassolotl commented Feb 26, 2018

Private posts no longer federate to instances that don't keep private posts private, so this can be closed, I think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment