A conversation field is a space for conversation.
Here are the basic ideas:
In the OverHear system, everybody has a conversation field around them.

See? There everybody is, with their conversation field around them.
(The terms "field" and "space" are used here interchangably. They mean the same thing.)
People can talk into their own conversational field. Because others can subscribe to their field, the net result is that it's something like blogging. You say something, and your subscribers hear it. But with an instant messaging "push" twist.

You'd likely subscribe to your friends' fields. If they had something to say but to nobody in particular, they'd just speak it into their field, and you'd hear it.
One thing that is kind of interesting, is that people cannot enter each other's conversational field. For example, if Alex Schroeder has a conversation field around him, you can't walk into it.
What happens instead, is that, if you want to talk with Alex, you merge your fields. At least temporarily.

In reality, the "merged field" is it's own field, and we've just pointed the two of you's fields to point to a new field.

But we call it "merged," because we want to describe the situation for subscribers.
The people who subscribed to Alex's field- they now hear everything that is happening in your conversation. The people who subscribed to your field- they now hear everything that is happening in your conversation.
That's part of why the system is called "overhear."

This way, you can hear all the conversations that your friend is partaking in!
Let's take an inventory of what we have so far:
About that last point- jumping in. When people are engaged in a merged conversation, you can send a note to the shared space. (I'm not worried here about the particulars of how joining the conversation works.) Your conversational field then merges with the spared space. You are now a part of the conversation.

It's my belief that a lot of larger conversations will actually come about this way- a friend of yours has a conversation with someone, and you overhear it. It sounds interesting, and you find you have something to contribute. You send a message, and suddenly you are three.
There's a network effect here: Suddenly all of your friends are overhearing the larger conversation (via their subscription to you,) and now they are interested, and want to say something. The party grows larger.

At some point, the group gets large enough that they want to split into individual conversations. The conversation splits into fragments (by some mechanism,) and now there are lots of little conversations.
Perhaps the mechanics of OverHear allow for some networking between conversations. History tracking, something like that - so that you can see how conversations came about, and find the earlier or later conversations.
Perhaps you could have some sort of cool conversation visualizer, for hopping around.

Maybe superfluous, but this diagram helps us understand how conversations develop and fragment.
So, we have:
There's only one major thing really missing: topic based arrangements.
Right? For example, in IRC, we can group ourselves by topic. We can say, "I am interested in wiki," and join "#wiki." #wiki is a chat room dedicated to wiki. It is expected that when people talk in #wiki, that the primary conversation be of general interest to the wiki community.
The system we've described, of conversational fields, so far has nothing to account for that kind of interaction.
So, we add a new concept: "Pegs."
A "peg" is something that has a conversational field of it's own, but it's not a human.
(diagram of people and pegs with their conversational fields- all alone, all cut off)
The people in the drawing above are not pegs. But, the squares in the drawing above are pegs.
"Peg" is an English word that means something like a "pin for fastening" or a "hook for hanging" something.
We're going to use the word "peg" to describe a thing that we "hang" our conversations on. When we are talking about a particular sort of ideas, we'll be able to hang our conversation on a relevant "peg."
Let's see it work.
Let's say that there's a peg called "#wiki."
(drawing of a bunch of people, and a peg called #wiki)
If you want to hear about wiki stuff, you subscribe to the "#wiki" peg.
(drawing of a bunch of people subscribed to #wiki)
Now, let's say a bunch of people are talking about wiki. When they realize, "Oh, we're talking about wiki," they pull in the wiki peg.
(drawing of #wiki pulled into the conversation field of people talking about wiki)
Now, we see, all the people who are generally interested in wiki- they see the conversation about wiki.
In this way, we have the same effect of "chat rooms" in IRC.
We use "peg" in English to mark borders, and we use "peg" in English to talk about "hooking" things together.
But, we also use it to talk about "solid pieces." Like, if you're playing a board game, the pieces on the game board can be called "pegs." If you're playing Monopoly, we might call the boot or the battleship a player's "peg." That would not be too strange.
So, the word "peg" will also suggest "bots." A "peg" in the OverHear system is likely a bot.
Someone would have administrative control over the #wiki bot. That way, if some spammers share space with the #wiki field, the administrator of the bot would lock out the spammer.
Likely, the bot would have an internalized sense of delegating power. Sort of like the "op" system in IRC. The bot owner could say, "MattisManzel has the same powers to control the bot that I do."
Bots would also take care of any logging, could provide general services, etc., etc.,. (See also: TheBot, CommBot.)
Peg's could be "incarnate URLs," or something like that.
So, if y'all are looking at a page on a [SharedWebBrowser? shared web browser,] hopefully more sophisticated than our venerable low-tech shared web browser, then the shared web browser could invoke pegs for the URLs that are being visited, and bring them into the converesational space.
So groups that are talking around a web page could see each other.
If you just pulled a web browser into your own field (merging fields), then you could be "publishing" your location, and see other people looking at the same "location."
There's no reason bots can't communicate with each other via the conversational fields. And there's no reason bots couldn't listen in on each other's communications. You could build [IntComm:ActivityAwareness? activity awareness] using the underlying technology for "Conversation Fields."
This is basically all I have to say now, to explain the basic ideas of "Conversation Fields."
This will be a VisualLanguage explanation of a concept originally described in OverHear. The OverHear page is sloppy and hard to follow, I think this wil be a lot nicer.
I'm very busy with work right now, so I don't have time to fill in the pictures for this. I'll be at work for the rest of the day. I intend to fill the pictures in, a bit at a time, over the coming week. Please don't erase the markers for images.
I originally wrote a page while creating the images. Half-way through, I realized a mistake, and had to replace a bunch of stuff. I'm now thinking it's best to make the text first, with place-holders for images, and then make the images afterwards. It takes a long time to make images. (See also: "LongImageIncorporationProcess," on the Visual wiki. When we all have tablets in 5 years, this should be easier on us.)
Sprouts of the technology to implement OverHear are popping up all over the place; The technology is a seperate discussion altogether, after the basic ideas.
I'm still working on LocalNames, but I wanted to take time to write out the ConversationFields? idea.
update: I've added diagrams for all but the peg discussion, which I want to finish soon.
Also, it feels weird to me to say, "I'm subscribing to a label for a conversation." It feels easy to say, "I'm subscribing to a peg for a conversation," though.
Then again, I'm biased. I've been using the phrase "Memory Peg" for a long time now.
merging fields
When two people start talking with one another, their fields merge. Well, it feels like they merge. People who were subscribed to one field now hear everything in the other field. So, it feels like they merged.
It feels like this:

In reality, technically, the situation is probably going to be modeled something like this:

That is, the individuals' fields point to a new shared field. The shared field poinst back to information about the individual participants.
two conversations at once
If someone participates in two seperate conversations at the same time, then the system should handle that.
The word "merge" is not adequate here.
The person is actually engaged in two distinct conversations. People who subscribe to the person's field, though- they suddenly get two conversations on their radar. That is, they overhear two seperate conversations. Perhaps in the user interface, they see two seperate texts flowing down. They can choose to join one, the other, or both. But they passively experience both conversations.
Should two conversations decide to merge, though, they should be able to do that.
"topical conversations"
Conversation fields don't have "topics." There is no such thing as a "topical conversation field."
Rather, you can pull in a peg, representing a topic. When I'm not entranced by d.taylor, I'll work out diagrams that I think will make the concept of "pegs" clearer. Basically, just take this diagram…

…and change some of the icons of people for boxes. The boxes will represent "pegs"- non-humans with conversation fields. They're not a basic type- the technology probably sees humans and pegs alike.
Maybe Bayle is right; Maybe I should have never introduced the word "peg." Just look at the conversation fields, and understand that people and bots and … uh… "markers…" …have their own conversation fields that can be subscribed to. (Hm, marker is no better than peg.)
I mean: A peg could be a word. It could be a url. It could be an anything, basically. I don't really care what it is. Just that it's something that has a conversation field around it, that can be hooked into other conversations.
I'd write more, and make more diagrams, but I'm about to go to bed.
I'd like to make some diagrams of what a UserInterface might look like, too.
If you just subscribe, but do not participate, you are a lurker, and an icon indicates that. (Or some other UI mechanism.)
Furthermore, if you are subscribed, but do not participate, your subscribers do not hear what you are listening to.
That is, if C & D are talking with each other, and B is subscribed to C, and A is subscribed to B:
Otherwise, as soon as one person started talking with another- Everyone who knew someone who knew someone who knew someone who knew someone who knew one of the participants- would suddenly be part of the conversation. 
I would rather call this 'forwarding' - when you subscribe to someone he forwards to you all the messages he receives plus the messages he sends (C forwards to B, length of forwarding path = 1), when you join a him he forwards to you one layer more - that is he forwards to you what is forwarded directly to him (C forwards to B what D forwards to B, length of forwarding path = 2).
I agree that the merging metaphore is a problem. We can huck it.
I don't feel that "forwarding lengths" is the same thing as OverHear.
In OverHear, you only hear:
By the system you described, there is no differentiation between conversations. You couldn't carry on two seperate conversations, distinct from one another.
Furthermore, by the system you described- if you join a friend, suddenly you are hearing everything that they are hearing. There is no difference between participation and subscription, either, it seems. If they are listening to 3 guys talk that you don't care about, then you have to hear it all.
At least, that's based on what I understand of what you said. Could you draw an ASCII diagram to help explain the system? But it seems to me like it's very different than OverHear.
re: previous comment: yes, the system that Lion is describing is indeed different from just forwarding with transitive closure, or with some sort of "distance limit". As Lion said, it's essential that "subscribing" to a conversation is different from actually participating in it (although certainly, some sort of transitive or forwarded subscription mechanism would also be cool). In short, "participating in a conversation" is transitive, and "subscription" is not transitive. If A participates in conversation X with B, and B participates in conversation X with C, then A and C are both participants together in conversation X. But if A subscribes to B, and B subscribes to C, then A is not subscribed to C.
More in a minute..
A conversation is a set of textual events, e.g. "Lion: 'Hello there'", "Zbigniew: 'Why hi, Lion'". If conversation C and D are merged, then from then on (until they are separated), then every textual event in either C or D is in both C and D.
A conversational field is composed of two sets of conversations; a participation set and the lurking set. Each person has (at least one) associated conversational field, and we say that "person P is participating in conversation C" if C is in the participating set of P's conversational field. We say that "person P is lurking in conversation C", or, equivalently, "person P is subscribed to conversation C" if C is in the lurking set of P's conversational field.
If conversation field A is subscribed to conversational field B, then any conversation C in B's participating set also goes into A's lurking set.
So, note that merging is transitive, and subscription is not.
More formally:
Let e represent a conversational event. A, B, C represent conversations. Let f be a function which associates each conversation with a set of conversational events. Let Q, R, and S represent conversational fields. Each conversational field is a tuple (P, L) of two sets of conversations, the participating set, and the lurking set. We write Q_P to denote the participating set of conversational field Q, and likewise Q_L means Q's lurking set.
There is a binary relation merged on conversations. There is an binary relation subscribed on conversational fields.
merged(A,B) iff forall e \in f(A), e \in f(B). The relation merged is symmetric; if merged(C,D) then merged(D,C).
subscribed(Q,R) ("Q is subscribed to R") iff forall C \in R_P, C \in Q_L.
Now, let's consider which relations are transitive. Merged is transitive: if merged (A,B) and merged (B,C), then forall e \in f(A), e \in f(B), and therefore e \in f(C); therefore we may conclude that merged(A,C). However, subscribed is not transitive. If subscribed(Q,R) and subscribed(R,S), then it is quite possible for some conversation C to be in S_P, and therefore in R_L, but not in Q_L.
I was asking what is the difference between participation and subscription - I wanted you to explain that. In both cases the message is delivered to you. I guess you want to present it differently and I am asking you how.
Bayle's formalization is close, but not quite right. (More in a moment.)
I'm going to use Bayle's distinction between conversation and conversational field. The conversational field represents the person. The conversation represents a group of people talking.
Participation: If you are participating in a conversation, then everyone who is subscribed to your conversational field overhears the conversation.
Subscription: If you are subscribed to a conversational field, then you hear all of the conversations that it is participating in.
In both participation and subscription, you get the messages. But in the case of participation, other people who listen in on you- they overhear you talking. But if you are just subscribed to something, the other people aren't bothered by it.
(I hope this makes it clearer?)
Bayle: I like your formalism! It took a while to get it onto paper and figure it out.
But, I feel it has some problems- I would think that when a conversational field subscribes, it subscribes to another conversational field, not to a specific conversation.
In the language of your formalism, I'd say that a conversational field Q was made of two parts: Q_L (lurking) and Q_P (participating). The difference is that Q_L lurks on both conversational fields and on specific conversations. Whereas Q_P participates in conversations, always. (It doesn't make sense to participate in another conversational field- you can only participate in a full-on conversation with conversational events passing through. Conversational events do not happen in the field.)
I feel that the terms are getting confusing.
Perhaps we should change it like so: Turn "conversational field" into "a person." Let "conversation" be conversation. Turn "subscribes to" into "lurks on." Turn "participates in" into "talks in." Turn "conversational event" into "word."
A Conversation is a thing with words in it. A word comes from a Person, when the Person talks in the Conversation.
A person can lurk on either another person, or on a conversation. A person can talk in a conversation, but a person can't talk in another person. Saying that a person "talks in" another person doesn't make any sense. But saying that a person "lurks on" another person, and that a person "lurks on" another conversation- both of those make sense. (Both to our intuition, and to the formalism.)
Addition: There is always one conversation around a person, which is special because no one else can talk in it. It's called the "thought bubble," and it resembles an IM blog. (Not a major point, but something I'd want to point out.)
So we have:
Person = "Talks in" (some conversations) + "Lurks on" (some conversations and people)
Conversation = bunch of Words, lined up in a row
(We can ignore merging conversations for the time being; Let's just get this basis going first.)
Alex can lurk on Bayle. Bayle can lurk on Christopher. But that does not mean that Alex lurks on Christopher. When Christopher talks in his Thought Bubble, Bayle hears it, but not Alex. If Bayle talks into his thought bubble, Alex will hear it. That's because Alex lurks on Bayle, and Bayle talked in a Conversation- his Thought Bubble.
Christopher and David talk in a Conversation, "C1." I am not naming the Conversation, because that would imply that the conversation has a named topic. Because what people would call a "topical conversation" is made by another mechanism (namely, "pegs" or "markers,") that we're not introducing yet- I don't want to confuse the issue by naming the conversations. So we'll just call them C1, C2, C3.
Bayle hears Christopher and David talk C1, because Bayle lurks on Christopher.
Somehow, Alex learns about C1. Alex does not lurk on either Christopher or David, but Alex decides to lurk on C1. This is a demonstration of Alex lurking on a Conversation, rather than on a Person.
(I hope this makes things clearer? I'll make some diagrams later on to support this.)
but I was being confusing by using "subscribed" in two ways; the relation subscribed(), and that English interpretation. The relation subscribed() was about conversational fields. The English interpretation could be reworded as follows:
(implementationally, this wouldn't matter; it might be just as easy to have an invisible conversational field attached to every conversation, so that you can seem to subscribe to a conversation while actually subscribing to the conversational field; the conversational field being some sort of URN or address of a data object or something).
Re: a simplified language: "Alex lurks on Bayle" might be confusing. Howabout using "subscribe" throughout instead of "lurk"?
"Alex subscribes to Bayle, so when Bayle talks, Alex hears it".
A "conversation" consists of a bunch of words. Each person can either participate in a given conversation, or overhear it without participating in it, or not even hear it.
Any person can choose to participate in or overhear any (open) conversation.
However, people can also choose to subscribe to other people. If Alex subscribes to Bayle, then Alex automatically overhears every conversation that Bayle participates in.
Conversations can merge. If two conversations C1 and C2 merge, then any words said in C1 are also heard in C2 and vice versa (until such time as they are separated).
Transitivity: So, if C1 is merged with C2 and C2 is merged with C3, then C1 is merged with C3; it's like one big chatroom. However, subscription is different; if Alex subscribes to Bayle, and Bayle subscribes to Christopher, then Alex won't overhear all of the conversations that Christopher participates in.
Topical markers: Just as you can subscribe to a person, you can also subscribe to a topical marker. For example, "#wiki" might mark any conversation having to do with wikis. You can "subscribe" to #wiki just like you can "subscribe" to Alex, and if you do so, you will overhear all conversations about wikis. This is like chatrooms, but more flexible; a single topical marker can hold multiple separate conversations, and each conversation might be marked with multiple topics.
(we might implement this by making "#wiki" a "virtual person" who "participates in" conversations having to do with wikis).
ThomasKalka pointed me to chandler http://www.osafoundation.org/OSAF_Our_Vision.htm. It has a touch of OverHear. Asynchronous P2P was another thing I didn't understand. The coordinates xyz according to him would be foaf, asynchronous p2p (no servers), ontology, geo-coodination. Sorry Thomas for hopelessly copying without undestanding it. Feels to me, I may do so.
Bayle: Yes, I like your new terminology best. And it accurately describes everything. 
Mattis: Yes, you can draw visualizations of this. It might require abbreviating to make it nice in 2 or 3 D, but I don't see any reason why this couldn't be visualized.
I've been drawing new diagrams for our clearer understanding; I think that when I put the diagrams on the wiki, I'll overwrite the page "OverHear" with them.
Later, we can delete this page- the new terminology is much better.