Follower/Following lists

heartles commented

2022-09-15 23:56:33 +00:00

Owner

Users can create and cancel follow requests on other users' profiles
Users can unfollow followed users
Users can force followers to unfollow themselves
Users can approve and deny follow requests

- Users can create and cancel follow requests on other users' profiles - Users can unfollow followed users - Users can force followers to unfollow themselves - Users can approve and deny follow requests

heartles commented

2022-09-16 00:14:27 +00:00

Author

Owner

I've got 2 different ideas for an api here:

In either case, follow relations will have a status enum attached to them that can be in either active or pending states (where pending represents a follow request that has not been accepted/denied yet)

Option 1: user based

GET /users/:id/following
GET /users/:id/followers
POST /users/:my_id/following - create follow request
DELETE /users/:my_id/following/:followee_id - cancel follow request or unfollow
GET /users/:my_id/following?status=pending - list outgoing follow requests
`PUT /users/:my_id/followers/:follower_id' - approve follow request
DELETE /users/:my_id/followers/:follower_id - deny follower request or force unfollow
GET /users/:my_id/followers?status=pending - list incoming follow requests

Pros:

Mirrors activitypub api
Reinforces that users are performing activities on their own account

Cons:

larger api (6 calls)
a single conceptual object (a follow relation) has two locations

Option 2: resource based

GET /follows?actor=:id - list users that actor follows
GET /follows?target=:id - list followers of target
GET /follows?actor=:my_id&status=pending - list outgoing follow requests
GET /follows?target=:my_id&status=pending - list incoming follow requests
POST /follows - create follow request
PUT /follows/:id - Approve follow request
DELETE /follows/:id - Deny follow request, force unfollow, cancel follow request, or unfollow depending on id state

Pros:

Smaller api (4 calls)
single conceptual object has one location

Cons:

Relation between follow relation and user is no longer obvious from url (this could possibly be improved if we could find better terms for actor and target above)
more complex request validation

I've got 2 different ideas for an api here: In either case, follow relations will have a `status` enum attached to them that can be in either `active` or `pending` states (where `pending` represents a follow request that has not been accepted/denied yet) ### Option 1: user based - `GET /users/:id/following` - `GET /users/:id/followers` - `POST /users/:my_id/following` - create follow request - `DELETE /users/:my_id/following/:followee_id` - cancel follow request or unfollow - `GET /users/:my_id/following?status=pending` - list outgoing follow requests - `PUT /users/:my_id/followers/:follower_id' - approve follow request - `DELETE /users/:my_id/followers/:follower_id` - deny follower request or force unfollow - `GET /users/:my_id/followers?status=pending` - list incoming follow requests #### Pros: - Mirrors activitypub api - Reinforces that users are performing activities on their own account #### Cons: - larger api (6 calls) - a single conceptual object (a follow relation) has two locations ### Option 2: resource based - `GET /follows?actor=:id` - list users that actor follows - `GET /follows?target=:id` - list followers of target - `GET /follows?actor=:my_id&status=pending` - list outgoing follow requests - `GET /follows?target=:my_id&status=pending` - list incoming follow requests - `POST /follows` - create follow request - `PUT /follows/:id` - Approve follow request - `DELETE /follows/:id` - Deny follow request, force unfollow, cancel follow request, or unfollow depending on id state #### Pros: - Smaller api (4 calls) - single conceptual object has one location #### Cons: - Relation between follow relation and user is no longer obvious from url (this could possibly be improved if we could find better terms for `actor` and `target` above) - more complex request validation

heartles added a new dependency 2022-09-16 00:23:44 +00:00

#4 Home Timeline

heartles added this to the v0.0.3 milestone 2022-10-13 09:43:55 +00:00

heartles added the

endpoint

db

labels 2022-10-13 10:34:27 +00:00

heartles commented

2022-11-15 09:05:02 +00:00

Author

Owner

This is partly implemented right now but it's missing a mechanism for follow requests, and I don't like the API. Leaving this issue open until its resolved.

heartles commented

2022-11-15 09:06:29 +00:00

Author

Owner

Generally my thought re: api stuff is that I think the way other servers did it has it right, with just treating follow requests as their own resource in themselves and scrapping REST for a more RPC style api

heartles commented

2022-11-19 11:34:00 +00:00

Author

Owner

In hindsight, follow requests should go in a different issue, after profile updates.

heartles commented

2022-11-19 11:34:34 +00:00

Author

Owner

Closing with 252c124

Closing with 252c124

heartles closed this issue

2022-11-19 11:34:37 +00:00

Rows
Columns

Follower/Following lists #2

Option 1: user based

Pros:

Cons:

Option 2: resource based

Pros:

Cons: