undo

 undo  is a common action you can take (often a button or menu item) to reverse the effects of the previous action, as if the action had never occurred; on the indieweb, you may want to undo a post, a deletion, or an update.

No side-effects
A key aspect of "undo" from a user perspective is that there are no side-effects of what they did and undid, it is literally as if the thing they had "done" had never been done in the first place.

The indieweb implication of this is that anything that your posts (or other actions) cause on other sites must not have occurred if you want to actually undo what you did (posted or other actions).

Examples (of side-effects that cannot be undone)
 * Your feed file (RSS/Atom) being polled and cached by a feed reader (which won't update)
 * POSSE, e.g. to Twitter, because it has been pushed to your followers clients, and they may have responded to it, copy/pasted it, etc.

What is not undo

 * Delete is not undo

Gmail
Gmail has an option to turn on "Undo", which enables the very useful "Undo Send" action.

After you send / file / move / label etc. an email, Gmail shows an "Undo" link/button/notification (depends on UI version you're using / app / platform), which disappears for some time later (typically 30s, configurable).

Gmail implements undo send by introducing a delay (that same configurable 30s) before actually sending the email to the destination server.

Micropub
Micropub has an "undelete" verb, so clients that support it can attempt to undelete a post that was (recently?) deleted.

posting UI
In an indieweb posting UI, you can implement undo using the same technique as Gmail, e.g. a 30s delay, before executing any non-undoable actions (e.g. POSSE, etc.)

This requires rethinking the indieweb posting UI to consider when/where to put an "Undo" link/button, and having it disappear when the delay time has passed.

side-effects to delay
Side-effects from publishing that you need to delay in order to actually implement Undo:
 * sending Webmentions (you don't control what the receiver will do with the Webmention both immediately, and upon any follow-up updates or delete Webmentions)
 * POSSE to Twitter
 * POSSE to GitHub - when you create a GitHub issue, or comment on one, it may be configured to automatically send an email, and that cannot be undone

Feed readers
If you publish a feed file, at any time (likely within minutes if not seconds), it may be retrieved by a feed reader, which, commonly will cache that version, and may not actually update it.

Thus if you publish a feed file with a new post, perhaps as soon as you update it on your server, it is not possible to undo that action, because that new post may have been retrieved and cached by feed readers.

Work-around:
 * Only publish items which are 30 minutes or more older in your feed files (RSS/Atom). This way any edits / or undo publishing that you do within 30 minutes of publishing a post will not be seen by feed readers, and thus give you plenty of time to "Undo" such actions without any side-effects in feed readers.

UX flow
(stub)

A good place to start with implementing a UX flow from post to undo to delete with explicit states, UI mockups and the transitions (both explicit by user, and implicit by passage of time).

Timeline of actions
 * Post
 * Undo post (within 30s)
 * Can't undo post (after 30s), perhaps offer option to Delete


 * Delete
 * Undo delete
 * Recover


 * Edit
 * Undo update

Micropub Undo
It may be worth exploring if it is possible to extend Micropub to support full undo on existing verbs. E.g.


 * Undo post
 * Undo update

This would require explicit support on clients and servers, as well as some way for a client to detect if the server supported these undo extensions.

Undeletable ambiguity
The word "undeletable" is ambiguous and could mean two very different nearly opposite things. See also: https://en.wiktionary.org/wiki/undeletable
 * "un-deletable" - not deletable
 * "undelet-able" - can undo a delete (the meaning we would like to use on this page)

Sessions

 * 2018/NYC/undo