untag

 untag  is sending an edit request to delete one or more tags (often person-tags) on someones post, where those (person-)tags possibly originated from someone else's tag-of reply post.

plain text untag
A GitHub issue has several labels (tags) on it.

Someone (with authority to alter labels on issues) chooses the label gear widget, and clicks the close box next to a label/tag, removing it.

untag persontag
Aaron posts a photo of Sebastiaan and Tantek sees that.
 * Tantek sends a tag-of reply to Aaron, notifying that it's Sebastiaan in the photo.
 * Aaron has Tantek whitelisted for tagging, and tags Sebastiaan on the photo.
 * Tantek and Aaron both send notifications to Sebastiaan, to notify him about the tag request and the update.

Sebastiaan then sees the photo, but doesn't want to be tagged.
 * He creates an untag post, in reply to both the photo post and the tag-of post, and notifies both Aaron and Tantek.
 * Aaron sees Sebastiaan wants to be untagged, and prioritizes that wish above the tag-of from Tantek, thus deletes the tag.
 * Similarly, as a result of receiving the untag post, Tantek deletes the tag-of post.

GitHub
GitHub supports removing labels from issues which is a form of plain text untagging.

Just like their support for tag replies, removing labels also shows up explicitly among the comments on an issue and has its own fragment permalink.

E.g. https://github.com/w3c/css-houdini-drafts/issues/763#event-1710566168 "🏷 undefined removed the css-paint-api-1 label 5 hours ago"

Github POSSE
Ideally you would post an untag response to a GitHub issue on your own site, and then automatically POSSE that untagging to GitHub.

Bridgy Publish feature request:
 * There is also the counterpart: 'untag-of' posts…

How to mark up?
Possible tags:
 * - only delete the tag(s) in the post
 * issue: too specific to just tags (does that mean  is also too specific?)
 * counterpoint: we already have  implementation (publishing/consuming) experience, thus it’s worth considering   as part of completing those implementations and use-cases.
 * issue: the name is not necessarily correct, and you may be removing the tag someone else added, thus it's not really an "un-*" action, it's a remove or delete
 * counterpoint: it's still an "un-*" action, even if someone else did the original action. remove or delete are also acceptable though.
 * +1 undefined leaning towards this choice in the short term as well, as part of completing existing tag-of implementations and use-cases, and to help enable UI/ecosystem experimentation with the whole flow of tagging and untagging things, to better understand adding/deleting properties in general. Such reversible tagging/untagging reflects the GitHub label model and that’s a good relatively simple place to start. There may be a need to expand this model to add a distinct "remove tag" feature as a more permanent action that blocks that tag from being re-added in the future, e.g. "Remove Tag" in Facebook blocks that person-tag from being re-added.
 * - can be used for any number of tags/, and also for requesting removal of other properties such as one  of a multiphoto
 * which other properties would indicate things to remove? vs about the h-entry delete-of post itself
 * remove: category, photo, ??? others (perhaps make this an explicit list that delete-of applies to?)
 * about the h-entry itself: dt-published, dt-updated, ??? should this be the default for any new properties e.g. dt-created?
 * +1 undefined leaning towards this choice, feels like it strikes a good balance between simplicity and ability to extend to additional properties. 'delete' in the name directly corresponds to Micropub "delete".
 * Does this mean we should consider "add-of" similarly more general than "tag-of"? Maybe worth discussing in the context of edit posts in general.
 * and then p-update/p-add/p-delete with an entire embedded object to represent the full set of properties and values to be updated/added/removed, close parallel of the Micropub‘s JSON.
 * issue: nested object more cumbersome (for publishing and consuming), especially for common case of one property with one value
 * issue: nested object more cumbersome (for publishing and consuming), especially for common case of one property with one value

See also:
 * https://micropub.net/draft/#remove

See the broader discussion for deleting (and adding) specific property values as variants of an edit post:
 * Edit brainstorm: add remove properties on other posts

hide the untag request
Since the untag request also links the identity and the photo, it should not be easily discovered and thus be a private post of some kind, e.g. not listed in feeds and at a non-guessable URL. If the other parties abide the request, it can be deleted - once the original tag-post is gone, the tag won't be accidentally recreated.