80 lines
3.0 KiB
Markdown
80 lines
3.0 KiB
Markdown
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.
|