Eureka Wiki (易易维基)





reply-context [2018/05/24 14:55] (当前版本)
eureka 创建
行 1: 行 1:
 +A **''​reply context''>​** 是显示[[reply]]贴子回复的内容,包括链接到原始贴子并带有[[in-reply-to]] 标记,显示作者姓名,图标,摘要/​省略内容和日期时间等原始帖子的一些发布内容。
 +当回复开始拥有自己的顶级永久链接时,回复上下文变得更加重要,这个已经在 [[Twitter]] 中被广泛使用,将 @-replies 当作其它的推文。 Twitter通过显示 @-reply 的直接reply-context回复的内容,但最后开始在线程中递归显示reply-contexts。.
 +=====  为什么 ====
 +====  为什么显示 ====
 +象吃货jeremycherfas [[https://​​2018/​you-can-get-good-help|说的]],​ "​一个回复没有上下文就象蛋汤没放盐。"​ 回复下下文提供:
 +  *  **读者认识** ​ 它们为读者提供了正在回答的内容。 通过提供更好的理解来提供更好的用户体验。
 +  *  **回复的完整性** ​ 存储回复上下文可确保您的内容副本始终是最完整的。 答复的本质是,在上下文之外没什么意义,如果你没有存储和显示该上下文,那么规范化副本的价值就比文章中出现和显示的任何副本都要低。
 +  *  **时间环境** ​ 存储回复上下文可以及时冻结您正在回复的内容,也就是说,如果回复或更改,您仍然拥有您回复的原始内容的副本。
 +    *  以一个 (不自然)的例子,回复同意一篇反战文章。一个月后,回复的域名被亲战组织购买,网站上的所有内容都会发生变化以反映这一点。 通过存储回复上下文,您可以保护您的意图免受误解。
 +====  为什么 in-stream ====
 +如果你在你的 [[homepage|主页]]流上显示回复 (e.g. 例如在 [[composite_stream]]中),​ ,或者甚至在他们自己的页面或[[archive|存档]]页面上显示一个列表,你应该在回复中至少显示一个最小的回复上下文,​ 基于以下原因(例如,至少用''​u-in-reply-to''​ 内嵌链接到 [[in-reply-to]] URL) :
 +  *  IndieWeb [[reader]]s that consume only the [[h-feed]] of your homepage will be able to detect and optionally retrieve/​show/​disclose [[reply-context]]s for your [[reply]] posts
 +  *  A small visual cue helps more clearly indicate replies (independent of starting with @-name), in a [[composite|stream]],​ as distinct from [[note]]s and other types of [[posts]]
 +Why not more reply-context?​
 +  *  Bigger / more extensive reply-contexts inline in a stream (especially composite stream) would add too much clutter/​noise vs. value.
 +=====  操作方式 =====
 +====  显示 ====
 +**How should reply contexts be displayed?​**
 +For general guidance on primarily textual reply-context presentation best practices, see
 +  *  [[reply-context-examples#​Indieweb_Examples]]
 +===  reply to a photo ===
 +How to reply to a photo, see this real world photo reply-context example:
 +  *  https://​​2014/​05/​i-used-to-live-in-bernal-heights-when-i-lived-in-the-city-looks-like
 +And brainstorming:​
 +  *  [[reply-context-examples#​reply_to_a_photo]]
 +====  标记 ===
 +For consistency with [[comment-presentation#​How_to_markup|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 ([[http://​​notes/​4QfGbM/​|example]]). Like this:
 +<code html>
 +<div class="​h-entry">​
 + <​div class="​u-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>​
 + </​div>​
 + <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.
 +=====  Levels ==
 +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.
 +====  URL ===
 +Since a reply has to be [[in-reply-to]] to <​em>​something</​em>​ (a URL), the simplest reply context is to simply show the URL (hyperlinked of course) of the original with perhaps a text label like:
 +<​blockquote>​In reply to: hyperlinked-URL-of-original</​blockquote>​
 +IndieWeb Examples of URL-only :
 +  *  ... {{t}} does this ... example on [[reply-context-examples]]
 +  *  ...
 +====  icon ===
 +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://​​benwerd/​profile_image:​ https://​​benwerd/​profile_image?​x=.jpg See [[Twitter#​Profile_Image_URLs|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
 +====  published ===
 +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 <​em>​content</​em>​ of an original post is the hardest thing to display <​em>​well</​em>​ in a <​em>​singular</​em>​ 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:
 +  *  ... a lot of folks - see [[reply-context-examples]] and copy a short list here inline
 +  *  ...
 +====  recursive reply-contexts ===
 +{{main|recursive reply-contexts}}
 +(previously called: <span id="​reply_thread">​reply thread</​span>​ and <span id="​history_thread">​history thread</​span>​)
 +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:
 +  *  [[User:​|Ben Roberts]] e.g. [[http://​​note/​2014/​9/​12/​1/​_|on 2014-09-12]]
 +  *  ...
 +=====  Notifications ==
 +Sites should send notifications using [[webmention]] for every [[h-cite]] / URL (u-url) in reply-contexts of posts.
 +=====  IndieWeb Examples ==
 +In order of deployment:
 +  *  **[[User:​|Aaron Parecki]]** displaying full h-cite reply-contexts on since at least 2013-04-19 using [[p3k]]
 +    *  [[http://​​replies/​2013/​04/​19/​2/​indieweb|example]],​ [[http://​​replies/​2013/​04/​21/​1/​|multiple reply example]]
 +  *  **[[User:​|Barnaby Walters]]** displaying full h-cite reply-contexts on since at least 2013-05-16 using [[Taproot]]
 +    *  [[http://​​notes/​1424/​|example]]
 +  *  **[[User:​|Sandeep Shetty]]** displaying full reply-contexts on since ??? using [[Converspace]]
 +    *  [[http://​​32|example]]
 +  *  **[[User:​|Tantek Çelik]]** displaying minimal reply-contexts on since at least 2013-07-09 using [[Falcon]], and in-stream reply-contexts since 2018-05-02 on his homepage
 +    *  [[http://​​2013/​190/​t6/​oauth-traded-evil-user-pass-dev-complexity-app-keys-tos|example]],​ [[http://​​2013/​132/​t2/​been-t-since-day-joined-2006|multiple reply example]]
 +  *  **[[User:​|Ben Werdmuller]]** displaying minimal reply-contexts on since 2013-06-24 using [[idno]]
 +    *  [[http://​​view/​51c921fcbed7de745b274ae6|example]],​ [[http://​​view/​51f01e17bed7de2b1d060400|multiple reply example]]
 +  *  **[[User:​|Bret Comnes]]** displaying minimal reply-contexts on since at least 2013-06-24
 +    *  [[http://​​2013/​06/​24/​t4/​|example]]
 +  *  **Julian Schweinsberg** displaying full reply-contexts on since 2013-08-21
 +    *  [[http://​​2013/​08/​21/​1377101842/​|example]]
 +  *  **Barry Frost** displaying reply-contexts on since 2013-09-15
 +    *  [[http://​​posts/​4|example]]
 +  *  **[[User:​|Brennan Novak]]** displaying h-cite reply-contexts on since 2013-10-11
 +    *  [[https://​​notes/​334|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!
 +  *  **[[User:​|Kartik Prabhu]]** displaying minimal reply-contexts on since at least 2014-03-17
 +    *  [[http://​​notes/​disappearing-ny-book|example]]
 +  *  **[[User:​]]** displaying reply-contexts as embeds on [[https://​​|]] (and like-contexts,​ repost-contexts,​ etc). [[https://​​responses|See all replies.]]
 +    *  [[https://​​2014-06-05_twitter-therealfitz-this-analysis-of-restaurants|Twitter example]]
 +    *  [[https://​​2014-05-28_alexis-shoemate-for-you-and-gina|Facebook example]]
 +  *  **[[User:​|Ben Roberts]]** displaying recursive reply-contexts in [[Postly]] since 2014-09-12
 +    *  [[http://​​note/​2014/​9/​12/​1/​_|example]]
 +  *  **[[User:​|David Shanske]]** displaying limited reply-contexts since 2014
 +    *  Example Pending
 +  *  **{{}}** has been displaying limited reply-contexts on [[http://​|]] since 2017-03-18
 +    *  [[http://​​social/​2017/​03/​updating-indieauth/​|example]]
 +=====  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:
 +  *  [[https://​​aaronpk/​php-mf2-instagram-shim|php-mf2-instagram-shim]] - converts Instagram posts to h-entry
 +  *  [[https://​​aaronpk/​php-mf2-twitter-shim|php-mf2-twitter-shim]] - converts Tweets to h-entry
 +  *  [[https://​​indieweb/​php-mf2-shim|php-mf2-shim]] - converts Tweets and Facebook posts to h-entry
 +=====  Brainstorming ==
 +====  Minimal text reply contexts ===
 +{{t}}: Some ideas for improvements over: "in reply to: (URL)"​.
 +(some from [[Falcon#​improve_reply-context_support]])
 +  *  if URL is a tweet permalink of user aaronpk, <​blockquote style="​color:​gray">​In reply to @aaronpk’s tweet</​blockquote>​ and hyperlink it to the in-reply-to URL
 +  *  else if URL is a Github issue comment permalink (​owner/​xyz/​issues/​n#​issuecomment-m),​ <​blockquote style="​color:​gray">​In reply to a comment on issue #n of GitHub project xyz</​blockquote>​
 +  *  else if URL is a Github issue (​owner/​xyz/​issues/​n),​ <​blockquote style="​color:​gray">​In reply to issue n of GitHub project xyz</​blockquote>​
 +  *  else if URL is a Github repo or issues list (​owner/​xyz or​owner/​xyz/​issues optional trailing /), <​blockquote style="​color:​gray">​New issue on GitHub project xyz</​blockquote>​
 +  *  else if URL has some other silo domain ( others?), <​blockquote style="​color:​gray">​In reply to silo-domain/​path-segment</​blockquote>​ (where path-segment is the username)
 +  *  else <​blockquote style="​color:​gray">​In reply to URL</​blockquote>​
 +For [[multi-reply]] context, space separate the generated @/​domain/​URL and link 2nd and later to respective in-reply-to URLs.
 +Possibly worth a small CASSIS function, takes in-reply-to array, returns display HTML.
 +Note that the above brainstormed reply contexts are actually two separate things - the "In reply to" pre-text which is specific to a reply-context (e.g. RSVPs would be different), and the synthesized summary of the url e.g. "a comment ..." or "issue n of Github project xyz".
 +The latter can be used in a number of different contexts for providing a more human text-friendly synthetic summary of a URL if you have no other information (i.e. a URL-only [[h-cite]], and no retrieval of the URL itself for [[link-preview]] properties).
 +Thus it’s probably better to make two CASSIS functions, one for the reply_to_text and one for an auto_url_summary.
 +====  CRUD ===
 +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]].
 +===  Update ====
 +  *  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
 +===  Delete ====
 +  *  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.
 +  *  http://​​replies/​2014/​05/​17/​1/​ - replied to a tweet which was deleted
 +===  CRUD Issues ====
 +==  Downstream vs Upstream =====
 +  *  I think it's bad to send webmentions downstream and that it should be avoided. One should rather look into alternative mechanisms to ensure reply-contexts stay up to date and maybe look at how eg. silos like Facebook solves that. I see some reasons why it's bad to send webmentions downstream as suggested here: <span class="​h-card"​ style="​white-space:​nowrap">​{{sparkline|http://​​avatar.jpg}} [[User:​|Pelle Wessman]]</​span>​ 05:21, 8 May 2016 (PDT)
 +    *  It will make a webmention endpoint that doesn'​t expect such downstream mentions to show the upstream post as a comment due to the upstream post likely including a link to the downstream post from the original upstream mention.
 +      *  That's a bug in the endpoint. It has no choice but to handle this since a third party C can send a webmention for any post link in A that links to B, regardless of whether that link is in a reply-context,​ a like-of, or a comment. [[User:​|Tantek]]
 +    *  It adds lots of complexity for standalone webmention endpoints, like [[]],​ which don't really have the data of an original post readily at hand and detecting downstream webmentions,​ unlike Salmentions which also adds a lots of complexity, will have side-effects if ignored.
 +      *  Complex or not an endpoint must handle any webmention for any link. It doesn'​t have a choice about this since anyone can send a web mention on behalf, and it is likely validation tools like will start doing this automatically. [[User:​|Tantek]] 05:46, 8 May 2016 (PDT)
 +    *  I'm also missing documentation of existing practices of for keeping reply-contexts up to date – eg. both Facebook and Twitter shows a preview of mentioned URL:s – how do they keep them up to date? Can the same practices be applied here? Downstream webmentions is no small addition and looking into alternatives would therefore be a good thing so we don't add complexity where we don't need to.
 +      *  There is no additional complexity beyond the defensive handling. This just an optional enhancement. [[User:​|Tantek]] 05:46, 8 May 2016 (PDT)
 +==  Webmentions to responses inefficiency =====
 +Even though possible, it may be inefficient to send individual webmentsions from an original post to all the responses of that post.
 +With each nth response (reply, like, etc.), the source then has to send n-1 webmentions to all the previous responses.
 +It results in a geometrically growing responsibility of sending webmentions.
 +There may be other notification mechanisms that should be explored such as [[PuSH]], e.g. if a response wants updates on that post in particular, perhaps it could do PuSH discover on the post, and then explicitly subscribe to receive PuSH updates on that post. (suggestion from {{aaronpk}})
 +===  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
 +  *  [[RSVP]]s in reply to the event
 +  *  [[invitation]]s 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|event:​ Response context CRUD]] for more details on how event posts should send webmentions to enable RSVP/​reply-context CRUD.
 +====  Fork On Text ===
 +[[https://​​kylewm/​forkontext|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."​
 +  *  https://​​kylewm/​forkontext
 +====  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: [[https://​​client-side-reply-contexts-with-javascript|Client side reply contexts with JavaScript]].
 +=====  Silo Examples ==
 +Some silos display reply-contexts.
 +=====  See Also ==
 +  *  [[in-reply-to]]
 +  *  [[rel-in-reply-to]]
 +  *  [[reply]]
 +  *  [[comment]]
 +  *  [[multiple-reply]]
 +  *  [[webmention]]