Re: im2000 protocol base

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

clemens:
> this is one of the reasons i want authentication be part of im2000.
> keys used for this would have to be back tracable to a natural
> person.  if this goal can be reached, im2000 users could verify
> messages to a practically useful degree.  it is not some anonymous
> node suddenly starting spamming, there's always somebody real
> behind it, and it seems easy to check certificate chains.

Okay... If you do plan to base your trust model upon a fully
traceable "one identity" => "one physical person" model, then you
have opened a whole septic tank of worms :-). Until you are able to
describe how to build the infrastructure to handle this, other
technical details of such an approach are less relevant.

I belive that in designing a trust model for an email protocol the
true challenge lies into being sucessful *despite* not trying to
uphold a fully traceable "one identity" => "one physical person"
model. I do belive this was the problem domain that the original im2k
idea of 'publish/subscribe' aimed for: "I only trust you if you have
access to a good outgoing email storage and can keep your message
there; if it is spam, people will complain and the message will be
removed.". But discussions lead to the insight that this approach is
only partially successful. Hence, the list has also discussed
combining it with a cash or HashCash approach: "I only trust you if
you pay me; if many people think you are not worthy of trust it will
be very expensive for you (either in real money or in 'computational
time')". The later seems to solve the problem of trust, but has nasty
side effects. A further comment in favor of a cash approach is that
this is how the trust issue is solved in so many other system, eg.
postal letters, mobile phone calls. But, surely I understand that you
think that the cash/HashCash approach is unnessecary if you anyway
plan to go for a traceable "one identity" => "one physical person"
infrastructure.

To be specific, these are the most basic questions:

* How does an international social/society infrastructure handing
  out im2k identities work? How should it be constructed?
  Who should pay for it?

* If someone hacks my computer and turns it into a hostile node; can
  I ever be forgiven by the system? Since I cannot reappear under a
  new identity, do I risk being negatively "marked" forever?


Some other points:

Rickard:
>> 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).

clemens:
> and what is wrong about that?

Then there is very little need for a generic node-network. If there
is only a handfull "external" services available it would be very
easy for every user to keep track of these and, using your own
words, "analyze all the available options in a given infrastructure
and within a given budget".


clemens:
> fact is that we can't have both a system capable of negotiating
> contracts _and_ allow anonymity [...]

Perhaps the capability of negotiating binding contracts without any
prior key-exchange has to be left out. This does not remove the
possibility of using im2k to charge for services: for example, the
mobile phone SMS service are used today to charge for small business
services, despite there not being a traceable "one identity" => "one
physical person" relationship.


//Rickard