User-level blocking and muting

petitminion

Give users control over the content they see and broadcast within the app by allowing them to block or mute other users, artists or channels.

Channels and artist
Actually an user can block artists. I propose to follow the same mechanism for channels.
User
User blocking is describe in the User following spec. and will apply for users listening and favorites activities since only this two activities will be implemented for now. Futures activities (upload activity for example) should be added to the filter when implemented.
Has requested in the forum https://forum.funkwhale.audio/d/559-how-to-block-individual-users we could also block user uploads. I think this should be implemented

Does everyone agrees ?

Sporiff

@petitminion This sounds good to me! If a user is blocked, their content should also be blocked. Makes a lot of sense. Blocking channels also makes sense, since they're just another actor 💪

petitminion

I'm writing the spec here : https://pad.funkwhale.audio/UZ7YFKn1SUCOxSwGpuMasA

And I'm wondering how is it useful to block user uploads ? I suppose blocking user upload activity, favorites and listenings is enough since this are the only spaces were user interacts with each other.

We could also hide the blocked User collections but allow the blocking user to access the upload if he need to ?
And on the other side we could make all upload of the blocking user unplayable for the blocked user. If so we need to add this to the collection spec and add another field on top of shared_recipients, blocked_recipients

Sporiff

petitminion

And I'm wondering how is it useful to block user uploads ? I suppose blocking user upload activity, favorites and listenings is enough since this are the only spaces were user interacts with each other.

I think the main use-case here is if the user keeps uploading abusive material and you don't want to see it anywhere, even if another user follows them. Blocking a user should block everything about that user.

For example:

User A follows User B
User B starts following User C and follows some of their collections
User A doesn't like User C's content and blocks the user
Funkwhale hides any and all content belonging to User C for User A

We could also hide the blocked User collections but allow the blocking user to access the upload if he need to ?

As I say, I think if User A decides to block User C that is a pretty definite rebuke of all of User C's content and activity. If the user just wanted to block a specific collection, that should be a different action. Having access to the upload doesn't really make sense, I don't think. Blocking is basically saying "I want nothing to do with this person".

And on the other side we could make all upload of the blocking user unplayable for the blocked user. If so we need to add this to the collection spec and add another field on top of shared_recipients, blocked_recipients

Yes, if User A blocks User C, User C should not be able to access any activity or content posted by User A. The block must be unilateral and prevent any interaction or visibility between the two parties to prevent abuse.

petitminion

Sporiff Funkwhale hides any and all content belonging to User C for User A

the only thing that "belong" to user C is the Upload file, the metadata is public. If user C also upload very mainstream material, it would also be blocked, this is probably not what is expected. I think we should focus on User activities because User upload can be merged with very mainstream content.
Afaik the only space where User C upload activity could appears is in the "Recently added" section. Actually this section use the albums endpoints, we could change this behavior and implement and UploadActivity endpoint. Then filter this endpoint with the user blocking list. This also has a side effect that seem cool : albums that are re-uploaded by a different user will appears since we look for upload activities and not albums creation date o/

Example :

User A block User B
User B is the first to upload Linkin park tracks
User A will not find Linkin park tracks on the network

Sporiff

petitminion

petitminion the only thing that “belong” to user C is the Upload file, the metadata is public. If user C also upload very mainstream material, it would also be blocked, this is probably not what is expected. I think we should focus on User activities because User upload can be merged with very mainstream content.

Yes, good point. The uploaded file should be blocked, but the metadata should be handled separately (e.g. if user A doesn't like a specific album/artist they can use the existing filters to remove these).

petitminion Afaik the only space where User C upload activity could appears is in the “Recently added” section. Actually this section use the albums endpoints, we could change this behavior and implement and UploadActivity endpoint. Then filter this endpoint with the user blocking list. This also has a side effect that seem cool : albums that are re-uploaded by a different user will appears since we look for upload activities and not albums creation date o/

This is an interesting idea. So in this case:

User A blocks User B
User B uploads Linkin Park albums
User A doesn't see Linkin Park albums at the top of the "Recently added" stream because they've blocked User B
Later, User C uploads Linkin Park albums
Because User A follows User C and has not blocked them, the Linkin Park albums appear at the top of the "Recently added" stream for User A

Is that right? What would this look like on API side? Does this have an ActivityPub representation?

petitminion

Sporiff The uploaded file should be blocked, but the metadata should be handled separately

But blocking User B uploaded file is useless doesn't it ? Blocking User A upload file to user B is needed tho'.

Sporiff Because User A follows User C and has not blocked them, the Linkin Park albums appear at the top of the “Recently added” stream for User A

This is not exactly true since we don't have a dedicated "My follows activities" feed has discussed here : https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/1810#note_61296. I think we should so but this should probably be discussed in the related thread. Actually User C albums will appears in the thread nevertheless it's followed or not.

Sporiff What would this look like on API side? Does this have an ActivityPub representation?

There is a partial answer in the spec. We should implement the blocking mechanism for both the funkwhale api and activitypub. As far has I understant ActivityPub blocking mostly consist to say to remote actor to not send activities, since we send a lot of activities to the services actor this has a limited effect, so the funkwhale api should take the relay. This is due to the fact that we mix activitypub and fw api. Maybe we could refactor this but I would rather to work with what we have since we already have a lot of work ^^

Sporiff

petitminion But blocking User B uploaded file is useless doesn’t it ? Blocking User A upload file to user B is needed tho’.

If I'm user A and I block User B, I want everything from them to be blocked. This includes their uploads. And yes, I expect User B not to be able to access my uploads, too.

petitminion Actually User C albums will appears in the thread nevertheless it’s followed or not.

Okay, I see. In the current implementation all that would happen is the blocked user's activities would not appear in the recent stream, but all other activity would appear normally. Makes sense 👍️

petitminion As far has I understant ActivityPub blocking mostly consist to say to remote actor to not send activities, since we send a lot of activities to the services actor this has a limited effect, so the funkwhale api should take the relay. This is due to the fact that we mix activitypub and fw api. Maybe we could refactor this but I would rather to work with what we have since we already have a lot of work ^

The ActivityPub spec basically says that the server SHOULD prevent a blocked user interacting with any object posted by the blocking user. It doesn't really account for the idea of hiding a blocked user's content/activity/profile from the blocking user.

Maybe we could mimic what Mastodon does here with their remote blocking feature. While the AP spec says you SHOULD NOT send a BLOCK activity to the recipient of the block, Mastodon does send this activity to the recipient's server. The server then uses this information to ensure that the blocking user doesn't see the profile of the blocked user.

petitminion

Sporiff If I’m user A and I block User B, I want everything from them to be blocked. This includes their uploads. And yes, I expect User B not to be able to access my uploads, too.

okey let's do it this way.

Sporiff Maybe we could mimic what Mastodon does here with their remote blocking feature. While the AP spec says you SHOULD NOT send a BLOCK activity to the recipient of the block, Mastodon does send this activity to the recipient’s server. The server then uses this information to ensure that the blocking user doesn’t see the profile of the blocked user.

there is something I don't understand.

actor A from serve A, block actor B from server B.
remote server B that receive the block activity from actor A : how server B is suppose to hide user B content from user A since user A interact with user B through server A ? Server B should only avoid to send user B activities to server A user A inbox since server A will reject them.

Sporiff

petitminion there is something I don’t understand.
actor A from serve A, block actor B from server B.
remote server B that receive the block activity from actor A : how server B is suppose to hide user B content from user A since user A interact with user B through server A ? Server B should only avoid to send user B activities to server A user A inbox since server A will reject them.

The local server side of things is pretty simple. Since User A has User B in their blocklist, filtering User B's content and activities is trivial

User A blocks User B
User B's content is public and is sent from Server B to Server A
Since User A has User B in their blocklist, they SHOULD NOT see any activity from User B. It should be filtered at the API level

What is harder is ensuring that User B CANNOT interact with User A's content on Server B.

User A blocks User B
User A's content is public and is sent from Server A to Server B
Server B SHOULD prevent User B from seeing or interacting with any of User A's content since the user is blocked

Reading more into it, I think remote blocking feature is for making sure that User B COULD NOT mention User A or load their profile. Either way, it requires some awareness of the block happening on the server side of things.

petitminion

Sporiff Okey got it. Thx a for the explaination o/ I think we have enough thing to build a proper spec 🙂

petitminion

@Sporiff I updated the spec with what we said.

petitminion

@Sporiff does your thumb-up means you've read it and that it's good or not ? ^^

Sporiff

petitminion I've not had a chance to look at it yet, I was just acknowledging it. I'll look today if I get a chance and give you any feedback I've got.

petitminion

Sporiff yeay no presion, it was just to know the status of this 🙂