Mastodon: user blocking/whitelisting of entire domains

Created on 7 Jan 2017 · 19Comments · Source: tootsuite/mastodon

i have a proposal for an interface that would allow individual users to control which GNU social / mastodon instances they would see posts from on the public timeline.

the interface would be a checklist, on the user settings page, of all GNU social instances that the current instance knows about. instances that are checked are whitelisted; everything else is blocked. there could be buttons for things like sorting the list and checking/unchecking all entries at once. there should also be a toggle for whether or not to automatically whitelist new instances.

it seems there's currently no way to find a list of all existing instances of GNU social or even just mastodon. however, as soon as you view an account that belongs to another instance, a reference to that account (and thus the instance it's on) is added to the current instance's database. so, populating the checklist shouldn't be hard.

if people like the sound of this then i would be willing to do the work on it. i finally have my own dev instance working outside of docker and while i'm new to rails, i feel capable of adding this feature.

see issues #231 and #344 for previous discussion on similar topics.

Source

daliacoss

👍8

All 19 comments

I like the sound of this.

There's a varying complexity in implementing the actual blocking i.e. not as a one-time action, I mean as a modification of all queries.

There's the fan-out-on-write process which uses a bunch of filters defined in lib/feed_manager before putting stuff into users' personal feeds. That stuff can actually be as complicated as you want it to be, since it writes one time in a background process and the reads are cheap and fast.

Then there's the notifications, which use some of the filters defined in lib/feed_manager as well, but can have extra filters (services/notify_service). It's a one-time write as well so no big deal.

Then there's the public and hashtag timelines, which are live SQL queries (defined as static methods in models/status). You're gonna want to be careful not to kill the performance there.

Gargron on 7 Jan 2017

Would a "host file" like entry be a good first step?

krainboltgreene on 7 Jan 2017

What do you mean by host file-like entry?

Gargron on 7 Jan 2017

@Gargron:

<textarea />

krainboltgreene on 7 Jan 2017

Oh! Hm. No I actually really like the idea of listing all known domains next to toggles. Beyond moderation it's also a pretty good tool for people to learn more about the fediverse. For reference you'd get the domains with a Account.remote.select('distinct domain'). I don't think the overhead of querying that and displaying a table with check boxes is that much worse than a textarea entry!

Gargron on 7 Jan 2017

Got it! I'll work on this tonight if I get the ✅ from you.

krainboltgreene on 7 Jan 2017

😄1

Alright, @deckycoss expressed interest in doing it though so just make sure you don't do the same thing twice. Also, it'll be easier to make a static version in the settings area first rather than implementing it as REST API + React.js stuff, that can be refactored into later.

Gargron on 7 Jan 2017

actually, as i said in the first post, i want to work on this. but if i need help from people more experienced with front-end then i'll say so

daliacoss on 7 Jan 2017

Sweet! Let me know.

krainboltgreene on 7 Jan 2017

ineffyble on 7 Jan 2017

@ineffyble oh! i didn't know anyone had already started work on this. do you plan to resume the patch? if not, maybe i could continue where you left off?

daliacoss on 7 Jan 2017

@deckycoss It's not mine, I just noticed it earlier. @hach-que - where's this at?

ineffyble on 7 Jan 2017

I don't have any intention on finishing that contribution.