Merge branch 'spec-domain-follow' into 'develop'

add domain follow spec

See merge request funkwhale/funkwhale!2798

changes/changelog.d/762.doc

@@ -0,0 +1 @@
+Add Domain follow specification

docs/specs/domain-follow/index.md

@@ -0,0 +1,79 @@
+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.