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 Request] Instance-level whitelist #3880

Closed
thedeadparrot opened this issue Jun 20, 2017 · 6 comments

Comments

@thedeadparrot
Copy link

commented Jun 20, 2017

It would be nice for the admins of instances that are more concerned about privacy/leaking information to be able to choose between using the instance blacklist and an instance whitelist. This is already implemented for awoo.space, the code of which is publicly available.

vahnj@2cf7a09
vahnj@2fca7e8

I am sure it needs to be cleaned up, have tests added, and so on, but I would love to see this feature more widely available for admins.


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

This comment has been minimized.

Copy link
Collaborator

commented Jun 22, 2017

Searched for a while but couldn't find an issue for this, which feels weird to me—this code has been around for a while.

@Gargron

This comment has been minimized.

Copy link
Member

commented Jul 2, 2017

Whitelists go against the spirit of decentralization. If you can't start your own server and join in, but have to go through some kinda review process with every single other node, then you can't really start your own server. So whitelists will never be in the upstream repository.

@TheDiscordian

This comment has been minimized.

Copy link

commented Sep 10, 2018

This seems like a really knee jerk decision to me. The main usage I can see for private instances would be organizations communicating for a specific goal, isolating themselves from the outside world. There would be other people using it too. But if your fear is most people just won't federate, they'll do that anyways if they want to via fork.

You can't force people to federate, but you can be annoying about it I guess ...

@Shadowghost

This comment has been minimized.

Copy link

commented Sep 10, 2018

I don't see why this can't be an optional setting.
I agree that it's against the idea of federation, but as long as it's not the standard setting, there's IMHO nothing speaking against it to be implemented upstream.

@emollusion

This comment has been minimized.

Copy link

commented Jan 15, 2019

+1 on this.
Opting out of federation or keeping federation within set domains would for some organisations be required. Doesn't matter if the organisation is a private company or a small chess club, or a union of board game clubs with no profit interest what so ever.
Since GDPR within the EU those organisations need to be able to delete user data when requested to do so by the user. With federation user data gets federated and after that there is nothing stopping it.
To not go against GDPR, some other features would be nice too but keeping federation within specific network(s) is a good start.

@odecif

This comment has been minimized.

Copy link

commented Jan 15, 2019

+1
This is a real issue for organizations since there is a use for Mastodon as a platform but not necessarily as a federation.

I think that opening up for the possibility of being compliant with GDPR would give significantly more interest to Mastodon than the cost it brings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.