2016/Düsseldorf: May 7, 2016!


A reply context is the display of what a reply post is in reply to, including linking to that original post with in-reply-to markup, showing some amount of that original post like author name, icon, summary / ellipsed content, and datetime published.

Reply contexts became more important when replies started to have their own top level permalinks, which appears to have been popularized by Twitter treating @-replies like any other tweet. Twitter started by displaying the immediate reply-context of what an @-reply was in reply to, but eventually started recursively displaying reply-contexts on up to the tweet at the start of a thread.



Why show reply contexts?

  • reader understanding. They provide readers the context of what's being replied. Better user experience through increased comprehension from the provided context.
  • completeness of your reply. Storing a reply context ensures that your copy of your content is always the most complete. The very nature of a reply is that it makes little sense out of context, and if you don’t store and show that context then the canonical copy is less valuable than any copies syndicated out and shown by the replied-to article.
  • temporal context. Storing a reply context freezes the content you’re replying to in time, meaning that if it goes away or changes, you still have a copy of the original content you replied to.
    • Take, for (contrived) example, a reply agreeing with an anti-war article. A month later the replied-to domain gets bought by a pro-war organisation and all the content on the site is changed to reflect that. By storing a reply context you protect your intent from misunderstandings.

How to


How should reply contexts be displayed?

For general guidance on primarily textual reply-context presentation best practices, see

reply to a photo

How to reply to a photo, see this real world photo reply-context example:

And brainstorming:


How should reply contexts be marked up?

For consistency with comment markup, reply contexts should be marked up as an embedded h-cite in a .u-in-reply-to so that it’s a nested microformat property of the parent (example). Like this:

<div class="h-entry">
 <div class="p-in-reply-to h-cite">
  <p class="p-author h-card">Emily Smith</p>
  <p class="p-content">Blah blah blah blah</p>
  <a class="u-url" href="permalink"><time class="dt-published">YYYY-MM-DD</time></a>
  <p>Accessed on: <time class="dt-accessed">YYYY-MM-DD</time></p>
 <p class="p-author h-card">James Bloggs</p>
 <p class="e-content">Ha ha ha too right emily</p>

Why mark up reply contexts?

  • Allows feed readers/conversation viewers/other microformats consumers to provide a better UX. E.G. a feed reader can parse a reply with a marked-up reply-context and use that data to show what the reply is commenting on without having to make another request, or as a temporary preview whilst it’s loading the original content.

Why use h-cite instead of h-entry for reply contexts?

  • Because it's more precise. Your reply-contexts are citations of someone else's work, not an attempt to propagate (syndicate) their work.

Why not use h-entry in addition?

  • Because h-entry implies syndication semantics, which are not what a reply-context is showing/conveying.


There is a broad spectrum of reply-context presentation that can be roughly ordered in terms of fidelity and difficulty, from simplest/easiest to richest (silo-parity) and most challenging.


Since a reply has to be in-reply-to to something (a URL), the simplest reply context is to simply show the URL (hyperlinked of course) of the original with perhaps a text label like:

In reply to: hyperlinked-URL-of-original

IndieWeb Examples of URL-only :


The next easiest thing to add is the icon (or avatar) of the author of the original post.

For example, replies to tweets can retrieve the icon purely by inspecting the URL for the first path segment for the Twitter username, and then embedding a dynamic image redirect URL, e.g. https://twitter.com/benwerd/profile_image: profile_image?x=.jpg See Twitter: Profile Image URLs for details.

Replies to indieweb posts can retrieve the icon from a nicknames-cache.

IndieWeb Examples of icon plus URL:

  • none so far

author name

Next, you can sometimes determine the author's name from a nicknames-cache.

Determining the author's name and their icon (more broadly/reliably than above), requires implementing the authorship algorithm on the original post, which requires more work than just parsing it for its h-entry as above.

IndieWeb Examples of icon URL dt-published and author name:

  • none so far


The original's published date is the next interesting (and slightly harder) thing to retrieve and display in a reply-context. With this step, an implementation must retrieve the original post and determine its "dt-published" (e.g. from parsing its h-entry).

The date and time of the original should be displayed and hyperlinked to the original's URL.

IndieWeb Examples of icon URL and dt-published:

  • none so far

original content

Lastly, the content of an original post is the hardest thing to display well in a singular reply-context, due to numerous additional variables. Some challenges:

  • length of original content - how do you truncate/abbreviate (if at all) original content to "fit" into a reasonably sized reply-context?
  • markup in original
    • do you allow any markup from the original content (e.g. links, images)?
    • or do do you always display only plain text from originals?
    • or use your own auto-linking on the plain text from originals?

IndieWeb Examples of icon URL dt-published author name and original content:

recursive reply-contexts

(previously called: reply thread and history thread)

Popular silos (e.g. Twitter) recursively display reply-contexts of originals/replies from the tweet that you're replying to, and if it was a reply itself, what it replies to etc. on up through the original tweet at the start of the thread.

IndieWeb Examples of icon URL dt-published author name original content for reply-contexts up through the original post that started the thread:


Sites should send notifications using webmention for every h-cite / URL (u-url) in reply-contexts of posts.

IndieWeb Examples

In order of deployment:

  • Bret Comnes displaying minimal reply-contexts on bret.io since at least 2013-06-24
  • Julian Schweinsberg displaying full reply-contexts on jschweinsberg.de since 2013-08-21
  • Barry Frost displaying reply-contexts on barryfrost.com since 2013-09-15
  • Brennan Novak displaying h-cite reply-contexts on brennannovak.com since 2013-10-11
    • first reply-context example
    • markup issue as of 2013-10-28: reply-context marked up as h-entry instead of h-cite, parent note not actually marked up with h-entry so no way of knowing it’s a reply!
  • Kartik Prabhu displaying minimal reply-contexts on kartikprabhu.com since at least 2014-03-17
  • David Shanske displaying limited reply-contexts since 2014
    • Example Pending

of silo posts

Reply contexts where the original is on a silo may sometimes need or deserve special treatment.

If you reply to a silo post where the silo does not mark up their HTML pages with h-entry, (e.g. post a comment on your own site, and the POSSE it to an Instagram post), you will need to do further processing in order to display the reply context as high fidelity as other indieweb posts.

You may find the following tools useful:



Though one advantage of storing and showing a reply-context is freezing the original context of what you're replying to, it may make sense to accept some updates.

For this to work, an original post that accepts and displays comments should send webmentions to all the comments permalinks when the original post is updated or deleted.


  • If your reply post receives a webmention from the original post, re-read the reply-context from the original, and consider updating the reply-context on your reply accordingly. Possibilities to consider:
    • automatically accept minor changes to the original that may just be typos
    • store the latest reply-context update separately and optionally present a UI to accept it (and perhaps update your reply accordingly as well).
    • maybe note dt-updated as edited/updated
    • check reply-context author name/avatar for updates


  • If your reply post receives a webmention of the original post, and when attempting to re-read the reply-context your server receives a 410 from the original post, then the original post has been deleted. What should you do with your reply and reply-context?
    • Leave it alone? (Do nothing)
    • Unlink the original?
    • Note in the reply-context that the original appears to have been deleted, but keep the reply-context from before.
    • This may be something we need to do individual UI experimentation on to get a feel for what are good options to consider.


Events RSVPs Invitations

This applies to event posts as well, and any responses to them, e.g. any changes to the event (name, , location, times, description etc.) should make the event send a webmention to any

  • RSVPs in reply to the event
  • invitations to the event
  • and comments, likes, reposts etc. as in response to other posts in general

So that they can update their respective reply-contexts accordingly.

See event: Response context CRUD for more details on how event posts should send webmentions to enable RSVP/reply-context CRUD.

Fork On Text

Fork On Text is an open source project in development to provide reply-contexts as a service, self-described as "Service to upgrade simple reply contexts with full reply contexts by fetching and storing remote content."

Client side with JavaScript

We could write a single reusable JS library that fetches, renders, and injects reply context(s) into the current page. Details: Client side reply contexts with JavaScript.

Silo Examples

Some silos display reply-contexts, including App.net (who mark them up with h-cite) and Twitter.

See Also