Follow pods feature specification
===

We want to introduce a feature that enables pod admins and/or users to follow all accessible **content** and **activities** on a remote pod.

### The issue

When a pod admin sets up a new pod the interface appears blank. This can make the app feel empty and confusing.

### The solution

We provide a way for users to explore content from accessible remote pods.

## Feature behavior

This feature enables admins (not users) to enter a remote pod URL to display and interact with that pod's **public** and **pod-level** activities. This includes:

- **Channel metadata**
- **Public library metadata**
- **Public and pod-level user listenings**
- **Public and pod-level user favorites**

This content appears on the requesting user's pod for their users to interact with.

```flow
start=>start: Start
end=>end: End
enterURL=>operation: User enters a remote pod URL
reachable=>condition: Is the pod reachable?
handleError=>subroutine: Backend handles the error
showError=>subroutine: Frontend displays an error message
APfollowrequest=>operation: The pods are added to the DomainFollow table is the follow request succed
activities=>operation: The followed pod send activities to the followers pods

start->enterURL->reachable
reachable(yes)->APfollowrequest
reachable(no)->handleError(right)->showError(top)->enterURL
```

### Backend

FUNKWHALE_OBJECT_TYPES `Domain`
`DomainFollow` table :
- `target` : the remote pod service actor
- `actor` : the pod service actor (maybe its not needed since it will alway be the local service actor. maybe instead of using db entrie we could add this has a model property)

The follow request should respect AP protocol. 

### Frontend

> This is where we need to define the behavior of the feature from the **frontend** perspective [name=Sporiff]

## Availability

> Where is this going to be available to end users? [name=Sporiff]

- [ ] Admin panel
- [ ] App frontend
- [ ] CLI

## Responsible parties

- **Backend team** – needs to define and write the backend tasks and any new endpoints to enable the feature
- **Design team** – needs to create frontend designs that show how and where this feature will be presented to the end-user
- **Frontend team** – needs to implement the designs created by the **design team** using the APIs provided by the **backend team**
- **Documentation team** – needs to document both front- and backend behavior.

## Open questions

- Should this content appear in a **new** section on the homepage or in amongst the existing ones (new albums, new channels, listenings, favorites)?
- Do we need to give pod admins the ability to opt their servers out of being followed?

## Minimum viable product

The MVP for this feature is to implement the endpoint. We can ship this to users without breaking anything and test it with real data.

### Next steps

After the MVP we can build the **admin** access to the feature to assess how much strain the feature puts on a pod. If the feature works well enough we can give admins an option to give **all users** access to the feature.