Anomaly in access to public messages between pods

[Alice-Po]

Description

Discovery of inconsistent behavior regarding access to public messages in a pod's inbox.

Observed behavior

Pod A receives in its inbox public messages (with as:Public in the recipients) sent by pod C, which it follows. Pod B, which has no special relationship with pod A, cannot read public messages from pod A's inbox when it is authenticated. On the other hand, these same public messages from pod A's inbox can be accessed from a browser without authentication, by going directly to the inbox URL.

Problem

The ActivbityPub specification is unclear about the right behaviour to get :

"The inbox stream contains all activities received by the actor. The server SHOULD filter content according to the requester's permission. In general, the owner of an inbox is likely to be able to access all of their inbox contents. Depending on access control, some other content may be public, whereas other content may require authentication for non-owner users, if they can access the inbox at all.""

But indeed the behavior is counter-intuitive and problematic, as authentication with a user seems to restrict access to otherwise publicly available content. Authentication should normally give more rights, not less.

Context of the discovery

This anomaly was discovered as part of an attempt to implement an onboarding mechanism for new users. The idea was to:

• Create a user/pod dedicated to the application who would follow major players publishing public content
• Use the inbox of this user/pod to display relevant content to newcomers in order to offer a more user-friendly experience for new users accustomed to centralized applications.

Steps to reproduce

Prerequisites

• Mastopod application in local

Replication

1. Create 3 pods (A, B and C)
2. From pod A, follow pod C
3. From pod C, post public messages (A will receive them because he's following C)
4. Check that as pod A, C's posts are visible in the inbox.
5. In the Inbox page, temporarily replace the following code:

const {
  items: activities,
  hasNextPage,
  fetchNextPage,
  isFetchingNextPage,
  isLoading
} = useCollection('inbox', { liveUpdates: true, dereferenceItems: true });
``
per :
```js
const {
  items: activities,
  hasNextPage,
  fetchNextPage,
  isFetchingNextPage,
  isLoading
} = useCollection('http://localhost:3000/<poda>/inbox', { liveUpdates: true, dereferenceItems: true });

Observed results

• Pod A can read public messages from its own inbox
• An offline user can read public messages from pod A's inbox via a browser with the direct URL
• Pod B, although authenticated, cannot read anything in pod A's inbox.

Expected behavior

An authenticated user (regardless of pod) should have at least the same access rights to public content as a non-authenticated user.