FEP-4ccd: Pending Followers Collection and Pending Following Collection

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-4ccd: Pending Followers Collection and Pending Following Collection.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

This specification defines two collections, pendingFollowers and pendingFollowing, with which users can review and manage their pending follow requests.

cc @eprodrom

1 Like
2

This FEP is more than 6 months old. I’ve implemented it in both onepage.pub and ap on the client side. I’d like to collect any final feedback, and then submit it for final status.

1 Like
3

You can mention them in “Implementations” section. This information could be useful to other implementers.

4

Thanks, good idea! I’ve added an issue for it.

1 Like
5

Sorry if this is a naive question. I’m fairly new to ActivityPub, and entirely new to the world of web standards. I’m currently reading Evan’s book and found my way here through curiosity.

The document states:

Each actor of a Follow activity in the pendingFollowers collection MUST be unique by id .

I read that to mean that each actor who has requested to follow the owner of this collection, can only be present once in the collection. But can’t there be multiple pending Follow activities, each activity having a distinct ID?

I didn’t see anything in the AP spec that suggests once a Follow activity has been generated for a particular pair of source+destination actors, that no such subsequent activity can be created.

If my understanding is correct, what is the expectation? That this collection be deduplicated and only the latest follow activity from a particular actor be present? If so, I think it would be valuable to spell that out.

6

Yes, the actor doing the following can publish multiple Follow activities for the same object with different activity ids. I agree that Evan’s requirements imply some form of deduplication of pendingFollowers. It doesn’t specify (from what I’ve seen) which (semantically) duplicated Follow activity to include in the collection.

Note that this doesn’t require that the “duplicated” Follow activities are not stored somewhere in the server so they can be used for processing requests like Undo/Follow. It only requires that they aren’t presented in the pendingFollowers collection.