Okay, so my feedback:
In the Terminology section is the same hint I had in the account deletion spec: An Actor does not have to represent a user.
Then there is a not fully clear thing in the Proposed Solution Section, Web app behavior: The way I understand this is that the Frontend/User Interface is responsible for the web finger de-referencing. I am not sure if this is what we want. On the one hand the interface is likely connected to the internet (if not, following doesn't work anyways) and has the capabilities. On the other hand, I think we shouldn't split the AP implementation too much between frontend and backend and therefore do the de-referencing in the backend.
In the following users section is a list of currently supported Content Types that are shared with the audience, however this is outside of the scope of this spec and likely to change.
In the API behavior section are no responses defined, I think we should do this.
In the unfollowing users ActivityPub behavior the spec states it is allowed to unfollow unilaterally, and this is probably AP spec compliant. However, we should do it right and inform the target of the Unfollow-Event.
I am not sure about the relation to public activity and the ability to follow. We probably should have a specific setting for the ability of arbitrary users to follow me, and not couple two things that are really unrelated.
Example: I might want to share my listens publicly, but post audio snippets for my followers only. In this case my activity is public, but I still want to control who gains access to my followers list.
In the UI I wouldn't automatically set the button to "Unfollow" in the case of the Follow activity. In the best case this goes pretty quick, however we probably don't know yet if the Accept bit comes. I would therefore make sure the Button reflects the state correctly by always going from Follow -- Click --> Pending -- Accept --> Unfollow instead of switching to Unfollow directly in some cases.
In the blocking section, its probably just wording, but multilateral seems to be the wrong term here. I can always block anyone without any involvement of other parties. Its my decision, my power. AP even forbids us to inform the blocked actor of the block, so its likely unilateral?
I think in the API behavior section for the blocking we should change the vocabulary from requesting and target user to blocking and blocked user. This is way more clearer and less confusing, especially since its a unilateral transaction and we do not need to make clear that both involved parties have the ability to block.
In the AP section for the blocking feature step 2 is wrong. Since we cannot inform the blocked user of the block, we don't know if we are blocked or not. And since we don't know and the blocking target probably even avoids letting us know, we can not not send the follow request. We need to send it and it just doesn't get accepted.
Furthermore I can't see why we should send an Undo Activity on the Block Object to the target. They don't know they were blocked, nothing changes.
I think the confusion here comes from the fact that the AP spec has a Client-to-Server and a Server-to-Server spec, while we are only interested in the later and the undo-on-block thing comes from the former.