Re: im2000 protocol base

clemens:
> what could an extensible protocol look like?  it can't define every
> "command" ever to be seen py participants, because new commands
> will pop up all over.  so how can new semantics be defined _within_
> a protocol?
[...]
> my suggestion is this:  im2000
>
> - can be visualized as connected nodes
> [Details removed]

You describe a very generic infrastructure for information transport
and trust-handling between paticipating entities. Perhaps I have not
completely grasped your underlying ideas, but my picture of the
protocol you describe can be summarized as three simple points:
  i) Information is transported between multiple connected nodes.
  ii) All nodes are free to do anything with the information they
     receive, but the idea is that they have some advertized role
     (eg., "recoding") which eventually results in communication
     with other nodes.
  iii) A node who has sent information to a connected node
     may investigate what actions the receiving node has taken on
     that information. If the sender node is not satisfied, it may
     terminate the connection to the other node.
Given the level on which you have specified this protocol, I
categorize all details about information content (eg. "headers",
"path-id:s") and specifics about key handling/agents, as being part
of the "implementation dependent" stuff you say are left for later
specification.

My only objection to the protocol itself is: doesn't this protocol
only describe how to loose trust? how do you gain trust? In specific:
how is a new node accepted into the network?

clemens:
> what do you think, will my connected nodes be able to fulfill
> [user] expectations?

With a protocol specification this general, I'm sure it is *possible*
to use it as a base for implementing im2000. However, I believe it is
absolutely vital to look more at specific implementation issues
before deciding if it is the best way; one may find another
trust model to come more natural.

clemens:
> reality will soon evoke hacked or malicious nodes that, for
> example, keep sending failure notifications to degrade nodes under
> attack and thereby mobbig or ousting them out of the 'net.  any
> ideas on this?

Still on a very general level: a node which can prove that another
node is "hostile" (as per it's own definition) sends out this proof
to other nodes. Nodes that agrees that this indeed proves "hostile"
behavior will disconnect both the hostile node, and other nodes that
refuse to act on the proof (and thus also being classified as
hostile). The end result is a "network split" that separates the two
kinds of nodes. Usually this should only mean that a smaller number
of attacking nodes are disconnected (but other scenarios are of
course possible). Allowing for a large-scale split of the network
could seem drastic, but with only the very generic definition of
information transfer above, it is needed to ensure compability
between the nodes.

However, I belive a larger part of the trust problem is hiding inside
the question above on how to accept new nodes; How do you avoid to
re-accept a "hostile" node into the network again and again? In the
context of spam, this is exactly the issue of: how do you prevent a
blocked spammer from just creating a new identity? I don't think I
have anything new to contribute to that discussion that has not
already been discussed on this list; but it may mean that one can not
trust new users more than ill-behaving old ones (which clearly is
a problem with usual email black-lists).

//Rickard