Re: im2000 protocol base

clemens:
> [... protocol details removed ...]

Okay; my view of your proposal is now a structure of protocol layers
rangning from the most generic 'Nodes and data transport' to very
specific layers 'im2000 email headers (eg. Subject:) transported by
SIP/SDP'. To participate in im2000 email transport, a node must
implement all layers as specified by you, but by allowing nodes that
implements the lower layers differently, this structure can be
extended to handle almost any kind of information transfer.

I'm sure this is a possible and very flexible implementation of
im2000, but I also think it may be unnessecarily complex.

Your "connected nodes" structure has a degree of "beauty" with some
theoretical benefits. The alternative approach is to transfer
information more or less unmodified directly from the sender to the
receiver. In the later case any extra processing, such as conversion
and re-coding, can be initiated by request from either the sending or
the receiving side. Such a more direct approach seems simpler to me,
but perhaps I have not fully understood the advantages of the node
structure. (I belive a real-life scenario would be of much use here,
but I think the Andy/Bertha-scenario you gave can be handled with the
more direct structure, as explained in my reply to that mail). To
summarize: I'm sorry, but I have to rewind the discussion to the
very basic question:
  Why do we need the node structure?

I have some more specific points too:

clemens:
> note that a users signature for a service can be viewed as a
> monetary value:  many signatures from happy users draw business.
> [...] the ideal behind this is at the same time idealistic and
> cooperative, but also pragmatic and capitalistic.

When you say "draw business", what kind of business do you mean?
Few external services would serve users for free, only for the sake
of the trust of serving yet more users. If that is the idea, you
would probably quickly end up with a system with ISP:s providing a
set of services only to its own paying customers (quite similar to
how most services are handled today).

Rickard:
>> 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?

clemens:
> good point.  so what happens if a spammer creates a new identity and
> fools 10 of 10.000 people into downloading his "product info"?  (i)
> the requesting users (or call them nodes) will have to sign his key
> to make their MTA even talk to him, and these signatures will be
> revoked rapidly as soon as the user is disappointed and presses the
> "rejection" button.
>
> this is why i want im2000 key servers to be special:  identities can
> be created rapidly, but users can see how many good signatures and
> how many revoked signatures they carry.  so they may specify rules
> like:  "don't use services with only one signature, and don't use
> sevices with more revokes then good sigs."

You still have the problem that you trust a new identity more than
a rejected one. This creates an incentive for hostile nodes to
re-appear under a new identity.

As old users withdraw their keys, new users will provide the hostile
node with new keys until the reputation of its service becomes too
bad. Then it simply swaps its identity and re-appear into the system.
Now, with the combined effect of lots of such hostile nodes (the
internet is a scary place...), I think you have a real problem.


//Rickard