Broadcast and display listenings and favorites

petitminion

liked collection endpoint : /federation/actors/<preferred_username>/liked
listens collection endpoint : /federation/actors/<preferred_username>/listens or listened ?

Sporiff

petitminion Since we're going with liked to align with AP, I'd suggest listened.

Sporiff

Sporiff Actually, strike that. A liked collection is relatively static (something either is or is not liked) whereas you can listen multiple times. listened would therefore preclude duplicates, so /federation/actors/<preferred_username/listens makes more sense.

petitminion

indeed, let's go with listens then 🙂

also I started to build the privacy setting with theses options since they were the defaults on in our code : "everyone", "instance", "me", "followers".
But "followers" is too complicated to implement right now because "everyone", "instance", "me" are linked together and not mutually exclusive (everyone include instance and me) but followers is something apart that would need a proper design. So I will only allow the three privacy settings

Sporiff

petitminion

But “followers” is too complicated to implement right now because “everyone”, “instance”, “me” are linked together and not mutually exclusive (everyone include instance and me) but followers is something apart that would need a proper design. So I will only allow the three privacy settings

Agreed. Also, I would suggest that we refer to these using more clear terms:

"everyone" = "public"
"instance" = "local"
"me" = "private"

If it's not possible to change this on the backend, I would still suggest we use these terms in the docs and the frontend.

petitminion

Sporiff the is a lot of reference to this on the backend code so I would keeo this for later this is not needed. But we totally use another wording in the ui, doc 🙂 I think "instance" is clearer than "local' tho

petitminion

gcrk @sporiff reads good! I am only wondering if we also need to send a delete message to everyone in case content is set to be non public after it was public to ask remote servers to delete the data.

Working on this. If a user change the privacy setting and has 20k listenings and we send send in individual delete activities we will get kick-out by the remote server.

solution 1 :
considering my proposition to implemente privacy_setting for favorite and listening later on (https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/2075#note_63447) we could in the meantime send a delete activity with the user has object if we use the user privacy settings for listening and favorite.

solution 2 :
If we want to allow privacy_level for favorite and listening we could to create an Activity pub object :

{
    "type": "Delete",
    "actor": "user.actor",
    "object": {"type": "UserListening"},
}

when received in the service actor inbox, it will trigger all listening deletion for the activity actor.

Sporiff

petitminion in the spec you write about as😛ublic but I can’t find it on the activitystream context. It’s on our backend code tho’, maybe it has been deleted ? In any case I don’t really see the interest of it, we don’t use it afaik

It's something that's mentioned in AP's public addressing section, but the actual documentation on it seems a bit hard to track down. We can make the wording in the spec simpler, but the idea is simply that the action needs to be denoted as public.

petitminion If we want to allow privacy_level for favorite and listening we could to create an Activity pub object :
{
"type": "Delete",
"actor": "user.actor",
"object": {"type": "UserListening"},
}

when received in the service actor inbox, it will trigger all listening deletion for the activity actor.

This looks pretty elegant to me 👍️ @gcrk how does this look?

petitminion

also @Sporiff in the spec you write about as:Public but I can't find it on the activitystream context. It's on our backend code tho', maybe it has been deleted ? In any case I don't really see the interest of it, we don't use it afaik

petitminion

Sporiff oh thank you I didn't see this. Interesting but we don't have the public collection yet. And this might take some time to implement (we would need to add this feature to all the other activities, if not I would be confusing). Also if we implement this public collection we might want to use it to optimize actor discovery in the network (load actor activities when the actor is discovered). But if we don't use why build it ? Since this needs some more design maybe we can keep it for later ?

gcrk

Sporiff There is no reason why this shouldn't be possible, we just need to make sure the source of the activity is actually allowed to delete those listenings.

petitminion

gcrk we just need to make sure the source of the activity is actually allowed to delete those listenings.

this is already implemented so I will build this last feature (bulk delete listening and favorites) and will consider that user follow and listening and track favorite activities are ready to be reviewied o/

petitminion

I looked again into this : afaik we don't support user privacy-level downgrade in funkwhale : if a user set it's profile to "me" or "instance" the update is not dispatched through federation
Also we don't support "followers" privacy setting for user.

this will allow to do the same has my previous proposition but in a much easier way.

def dispatch_privacy_downgrade(privacy_level, user):
    if privacy_level == "me" or privacy_level == "instance":
        # this will automatically delete all related actor aciivities
        routes.outbox.dispatch(
            {"type": "Delete", "object": {"type": user.actor.type}},
            context={"actor": user.actor},
        )
    if privacy_level == "followers":
        routes.outbox.dispatch(
            {"type": "Update", "object": {"type": user.actor.type}},
            context={"actor": user.actor},
        )

the only thing lacking in the actual code is "followers" privacy setting support

petitminion

To add followers privacy_level support for federation we need to migrate the privacy_level attribute from the user to the actor (if privacy_level is set-up for user's we can't federate the privacy level setting)

this would be the center part of the feature, instead of looking into user.privacy_level we would look into actor.pricacy_level

def privacy_level_query(user, lookup_field="privacy_level", user_field="user"):
    if user.is_anonymous:
        return models.Q(**{lookup_field: "everyone"})

    actors_follows = user.actor.user_follows.filter(approved=True).values_list(
        "target", flat=True
    )

    followers_query = models.Q(
        **{
            f"{lookup_field}": "followers",
            f"{user_field}__actor__pk__in": actors_follows,
        }
    )
    return (
        models.Q(**{f"{lookup_field}__in": ["instance", "everyone"]})
        | models.Q(**{lookup_field: "me", user_field: user})
        | followers_query
    )

petitminion

so I've added the privacy_level migration to the draft mr. Maybe a pre-review could be great on the mr, I could split it but if I do so I cannot end the development so I will split it after i finished listening broadcast