Re: How would "algorithmic choice" laws/regulations impact ActivityPub?

Bob pointed out that I trailed off mid-sentence.

That's because the sentence was going to be, "I think we have an issue 
open for this very topic", but when I switched over to my browser to 
find the issue, I couldn't find it.

Then, when I got back to email, I hit "send" without checking the last 
paragraph!

Anyway, I opened a new issue for this topic here:

https://github.com/w3c/activitypub/issues/490

Evan

On 2025-01-19 9:53 p.m., Evan Prodromou wrote:
>
> Hey, Bob. This seems to me to be primarily an ActivityPub API issue, 
> so I'll address that directly.
>
> With the ActivityPub API, we have essentially one inbox feed (but see 
> cardinality of properties 
> <https://www.w3.org/wiki/ActivityPub/Primer/Cardinality_of_properties>). 
> It's required to be in reverse chronological order by the AP spec.
>
> I /think/ it's reasonable for ActivityPub API /clients/ to do sorting 
> and filtering of that inbox feed. (Some siloed social networking 
> platforms explicitly disallow this in their developer terms of use, 
> for various reasons, but I don't know of one of those platforms that 
> implements the ActivityPub API.) So, the client fetches the activities 
> in reverse chronological order from the server, and then re-orders or 
> filters them according to the user-defined algorithm.
>
> Performance-wise, this is not a great solution. It would probably 
> require a lot of pre-fetching happening in the background.
>
> I think it would be out of scope to define how those clients would 
> present the different sorting/filtering options to a user.
>
> We don't have an easy way for an ActivityPub API /server/ to provide 
> multiple inbox-like feeds with different algorithms. We have the 
> /streams/ property, but it's really loosely defined, and it's not just 
> restricted to Collection objects that represent something like an 
> inbox or home timeline.
>
> I see a few ways to implement multiple server-side "home feed" 
> collections:
>
>   * Use the `inbox` property with multiple values. This would probably
>     break a lot of Fediverse software, which expects this property to
>     be a single value, and usually a single URL.
>   * Define a way to add multiple inboxes to the `streams` property,
>     and maybe have a way to signify that they are essentially the
>     inbox sorted or filtered in some way.
>   * Define a new ActivityPub extension property to provide a list of
>     available inboxes, like, I dunno, `availableInboxes`.
>
> I think we have
>
> On 2025-01-17 10:52 p.m., Bob Wyman wrote:
>> Yesterday, Missouri's Attorney General announced plans to issue 
>> regulations 
>> <https://ago.mo.gov/attorney-general-bailey-promulgates-regulation-securing-algorithmic-freedom-for-social-media-users/> 
>> that would require social media platforms to “offer algorithmic 
>> choice” to users. Clearly, it will take some time for this plan to be 
>> published, studied, challenged in court, etc. It is also quite 
>> possible that the regulations will be targeted to only the largest 
>> services (i.e. Twitter, Facebook, etc.). Nonetheless, I think we 
>> should anticipate that the coming to power of Trump and MAGA 
>> Republicans is likely to spawn many such proposals in the coming 
>> years. Given this, I think it would be useful to at least consider 
>> what impact such regulations would have on Social Media systems that 
>> rely on ActivityPub and ActivityStreams.
>>
>> My guess is that the position of the "ActivityPub" community would be 
>> that, in a federated system composed of a multiplicity of independent 
>> interoperating servers -- each having a potentially different 
>> moderation approach, it is not necessary for each individual server 
>> to offer algorithmic choice. Users are free to seek out and use a 
>> server whose default "algorithm" addresses their needs. However, this 
>> position might not be accepted as sufficient if the opinion is that 
>> the individual server, not the federated system as a whole, is 
>> considered to be the regulated "platform." The obvious question then 
>> becomes, what would need to be done to  enable a federated service, 
>> even if very small on its own, to provide compliant algorithmic choice?
>>
>> Some will undoubtedly argue that the BlueSky support for a variety of 
>> "labeling" services, when combined with user-selected client 
>> algorithms capable of filtering, etc. based on labels, might be 
>> sufficient to provide the necessary algorithmic choice. If such an 
>> approach is sufficient, then one must ask if supporting it would 
>> require modification to the ActivityPub protocols and schemas? (i.e. 
>> Would we need to add a "content label" item that allows 
>> the annotation or labeling of posts, replies, collections, etc.?)  
>> Would a labeling service be able to rely on the existing 
>> server-to-server protocol? Or, would something tailored more to the 
>> specific requirements of labeling be necessary? Of course, it would 
>> be useful to ask if there is a less cumbersome or otherwise superior 
>> method for providing algorithmic choice. What do you think?
>>
>> While the text of the plan isn't yet available, the AG's press 
>> release does provide a sketch of what will eventually be published. 
>> See the list below or read the full release 
>> <https://ago.mo.gov/attorney-general-bailey-promulgates-regulation-securing-algorithmic-freedom-for-social-media-users/>:
>>
>>  1. "Users are provided with a choice screen upon account activation
>>     and at least every 6 months thereafter that gives them the
>>     opportunity to choose among competing content moderators;
>>  2. No algorithm selection is chosen by default;
>>  3. The choice screen does not favor the social media platform’s
>>     content moderator over those of third parties;
>>  4. When a user chooses a content moderator other than that provided
>>     by the social media platform, the social media platform permits
>>     that content moderator interoperable access to data on the
>>     platform in order to moderate what content is viewed by the user; and
>>  5. Except as expressly authorized below, the social media company
>>     does not moderate, censor, or suppress content on the social
>>     media platform such that a user is unable to view that content if
>>     their chosen content moderator would otherwise permit viewing
>>     that content."
>>
>> bob wyman
>>