Blog Thread

Thread of discussion about a topic that runs across multiple postings on multiple WebLog sites.

A subset of the general Threaded Discussion problem.

A nightmare for an outsider to follow...

Unfortunately this doesn't seem to be the target for ThreadsML.

Technorati was supposed to provide this, but has never been fast/stable enough. And there's a huge Comment Spam issue.

• likewise Track Back/etc.

=== Sept'2014: Pondering interface challenge ===

Triggered by IndieWeb discussions...

Looking at suggested example: (1) Kyle Mahan makes a post, (2) Kartik Prabhu responds, (3) Kyle responds to that.

• Kyle's stream doesn't show (3), it shows only (1)
• the stream view of (1) ends with "2 replies"

Which raises questions....

• if (3) had come 3 days after (2), wouldn't it make sense to show (3) in Kyle's stream?
• only the other hand, if Kyle and Kartik went back-and-forth 10 times in a single day on that thread, would you want all of Kyle's responses to appear in his stream?
• and what if there are other people involved? If Alice responds to Kartik, will Kyle ever see it? And what if Bob responds to Alice?
  • Kartis suggests I could send a webmention to Kyle every time my post gets a reply from a third person and he could choose to update his thread with the same. Note that trickles up hard (Candy replies to Bob on his site, then Dan replies on Candy on hers...)

I kinda assemble these bits by hand myself right now...

• I read a post, I might tweet it
• If I really like it, and it relates to my areas of interest, I'll LinkBlog it on my WikiLog, probably with excerpts modified to add WikiWord-s.
• If I'm doing that, plus I made a relevant comment on your blog (which I care about not losing), I'll copy that in my WikiLog entry with an I Commented prefix.

Don't forget there will always be some people who don't have a blog, so unless you're going to leave all of them out of the conversation, you still need a Blog Comment system!

So I'm not convinced there's a huge amount of value here that makes it worth building this stuff while still building/running a Blog Comment piece.

• strongest argument I think is "my comment is so good, but if I put it on your blog's comment system and then your blog shuts down, my comment will be lost forever". In which case the manual copy-to-your-own-blog seems probably good enough....

Feb'2002: Semi-related (to Referer Watching service) idea considered: tracking a Blog Thread. My thoughts: Well, I thought that blogdex could be a place to start, since at least it lets you search on a URL (sample ), but unfortunately, since it focuses on scraping homepages of blogs, the URLs it returns are typically just the blog homepages, rather than the permalinks associated with the appropriate little chunk of blog... And this is a difficult problem to solve, since the pointing-permalink href is associated generally with some little symbol or label located "near" the text itself (rather than being attached to a blogBit title, say). So, you'd have to design system for defining where to find a permalink for each site (e.g. on peterme, it's the href surrounding "Link!" following the paragraph, on JOHO it's the href surrounding "PermaLink" following the paragraph). Oops, and on most Manila sites, there's no permalink at all for a single note, the link is associated only with an entire day of notes (Radio seems to fix that). So I don't think we'll see a solution anytime soon...

• Feb24'02 - was thinking about this again, and realized that RSS probably provides at least part of the answer, since at least the permalink is "attached" to the entry and its target HREF. The issues are:

  • not everyone's blog supports RSS

  • not everyone links accurately to the narrowest permalink they're referring to: sometimes they just link to the home page of the blog since that matches "today".

  • some blogs have a single permalink for the entire day, so if that person participates in 2 blogthreads on the same day, there could be a mess.

  • most current RSS-based services dump their data every day or two. So if existing services were going to start supporting blogthreads, they'd have to change the lifecycle of that data, etc.

    • any client-based RSS aggregator like Radio Userland should be able to do this. It would also have to change its retention model, so you could save and connect entries, without leaving them in your main to-read listing.

    • an alternative to this could be to have blog serving tools support an RSS (really XML - maybe we're going to have to stop trying to have RSS meet every possible structural-content need) view of any item (right now I believe that RSS is consistently a "one file per channel, containing most recent stuff" model). This way once a reader discovers an in-progress thread, his tool can trace backwards through the entire history of blogbits, regardless of age. Thus syndication servers wouldn't have to store a huge history of RSS.

Apr'02: see BackLinks for a new approach.

Mar'03: across Wiki sites, various WikiWeb approaches like RemoteWiki[[URL]] and Sister Sites might be helpful - if each person has a certain Wiki Name that they use in each of their own postings about a given topic, and then people link across those Wiki Names, it might become a bit easier to browse across them.

John Abbe says: This is one direction that i think automated exchange of notes among weblogs (or wikis) would be of value.

We each create a page with a table -- the weblog of our own input in one column and the RSS feed of the other in the other column. You create the inverse (using e.g. Tobi Schaefer's Java Script Rss Viewer).

If others join in, we add columns for them (getting the feed of their appropriate category if there system supports that sort of thing).