We need a server that can tell us, given one URL, what the threads are it belongs to. Every thread has a name, and a tree of nodes. Every node has an URL and another name. Since URLs are unique, we don't need yet another identifier.
This we call querying the server -- the response will be a little structured document (maybe XML, maybe even XHTML) describing the thread.
The API will allow us to add new nodes, delete nodes, rename nodes, add threads, delete threads, etc. This we call updating the server.
Deleting and renaming is optional for the beginning. Public thread servers will have to solve the same kinds of problems USENET has.
With that, we can add threading to one wiki, but we can also add threads to our blog articles. And to other people's blogs.
We can produce a new RSS feed that links selected articles from all over the blogosphere.
Later we can add functionality to other tools that will post new items in a thread to a thread server automatically.
Note that the content (the actual text) is not stored on the thread server. If we want to store the content on the thread server, we might as well use something like usenet, mailing-lists, blogs, or throw-away message boards on the web.
When you have a group of people interested in a topic, you can start a wiki. The problem is finding these people. 
When you don't have a group of people interested in the topics you are interested in, you can start a blog. Where to people engage in a conversation, however? Comments don't scale. You don't get email notifications if somebody replies to your comment. Only the owner gets notified when somebody adds a comment. RSS feeds are an all-or-nothing solution. When you see lots of blogs when surfing, and want to leave a comment, you don't want to add the blog to your blogroll just for that. Ordinary RSS feeds are much to coarse. [FineGrainedRss?]
What we would like to do is have a little bookmarklet that allows you to add the current page to a thread somewhere. If you do that for all the articles that you posted a comment on, then you'll at least see what you talked about. 
When you don't leave a comment but decide to write your own blog entry in reply to something you saw, you can currently use TrackBack and similar tools. But these also suck, because there's no inherent threading in the link mess. Allowing these people to add their blog entry to a thread on a thread server would solve the problem.
Blog authors interested in showing where their blog entry is in the thread can fetch the thread document from the thread server, inline it directly (if it is XHTML), style it using CSS, and they're instantly connected.
The simplest thing will be a wiki page per thread. The pagename is the threadname. The read is a nested unnumbered list. Every list item is a node: A name linking somehere.
This is the output of a little thread with two messages. It is valid HTML. Querying the server is easy, just fetch the wiki page. The extra level of brackets which are part of the name might be a problem. Updating the server is also easy, just edit the wiki page. In the future, there will be a more elaborate interface.
A real thread on the thread server can have comments before and after the thread, and for each item. This should be easy: Just pick the first ul item on the page. Nested ul are for nesting, li is a node, the a has the name and the URL of the node, the rest of the list item is a commentary for the node.
Here's a user story:
Today I saw an interesting post on JoiIto's blog: Similarity between Finnish and Japanese. I want to write a reply to that post, but I don't want to leave a comment on Joi Ito's site, because I want to make it longer.
So here's what I do:
Now, if Joi's blog also allows this "special link from his entry to the thread on the threaded server", then me and Joi could agree on a common default thread server and use it automatically. If not, I can always maintain the thread manually. This allows us to collect a number of wiki pages and blog entries and put them in a thread.
These are the basics: We only need four pieces of information.
There's a thread server implementation for Oddmuse, Oddmuse:Thread_Server_Extension.