Here’s where the Slack team suggest feat- as a prefix convention for temporary feature channels.

🤡

According to the commit that made this change, one of the benefits of moving nipsa to the user model was that the flag would survive users changing their names. Is that still a concern, or has something changed that makes this no longer a problem?

The use of the word “awkwardly” makes me wonder whether you meant to put this in the “Cons” list. I’m also not certain I understand what you mean here.

Is this because we’ve now made the h storage layer aware of NIPSA, so we might as well put it all together? Or is there something I don’t understand here?

Also based on whether the user themselves has a nipsa flag set?

I wonder: does this need to be returned under its own key? It looks to me as though it’s returning a fuller representation of the same resources as the flagged key, so would it make sense to return the more fleshed-out version in place? For example:

{
  "flagged": [
    {
      "id": "{first annotation id}",
      "flag_count": 42,
      "actions": { … }
    }
  ]
}

Is it? This request feels like it only makes sense for an authenticated user.

I’m struck by the asymmetry between the API for flagging an annotation and for showing the flags, in that the POST includes the annotation ID in the URL, while the GET returns it in the response body. If we were to POST to the /api/flags/annotations endpoint, with {"id": "123456"} as the request body, that feels like it would be more symmetrical, and means that the client is then POSTing a representation of the new “flaggening” resource.

What do you think?

If the response won’t have any content, could we return a 204 No Content instead? Or is there a reason we shouldn’t use that status code?

Is the idea behind including /annotations in the path that we could have flags for other things (say, users) in future?

Seems to indicate that birthdate is optional if you don’t have a US account.