untag

From IndieWeb
(Redirected from untag-of)


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.

Use-cases

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.

Silo Examples

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

🏷 Tantek Çelik 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:

Brainstorming

How to mark up?

Possible tags:

  • u-untag-of - only delete the tag(s) in the post
    • issue: too specific to just tags (does that mean u-tag-of is also too specific?)
      • counterpoint: we already have u-tag-of implementation (publishing/consuming) experience, thus it’s worth considering u-untag-of 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 Tantek Çelik 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.
  • u-delete-of - can be used for any number of tags/u-category, and also for requesting removal of other properties such as one u-photo 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 Tantek Çelik 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.
    • ...
  • u-edit-of 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

See also:

See the broader discussion for deleting (and adding) specific property values as variants of an edit post:

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.

See Also