Re: im2000 protocol base

Rickard Armiento <[email protected]>:

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

yes, this is what i'd like im2000 to be, just didn't find the words
for it.

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

these aren't real alternatives IMO: the nodes allow many things that
may not be always needed, so implementations will "transfer
information more or less unmodified" many times.

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

but that scenario was supposed to be an example for people not
wanting to analyze all the available options in a given
infrastructure and within a given budget.  i thought up a few
examples that are unneccessary complex with todays SMTP:

- notarization service
- "cron" feature for repeated delivery until some condition is met
- exclusion of unwanted features
- source routing (for UUCP type networking or gateways)
- preferences
- negotiation of goods or services on exchanges (contracting)
- voting
- translation services without prior contracting
- anonymizing
- list subscriptions: change of address etc.

stuff like this can be done with todays SMTP, but normally not without
preparation.  in cases where money is exchanged for goods or services,
participants have to draw up separate contracts first, and parts of it
have to be handled by humans.  people would have to forward emails
after beeing done w/ something, which they can forget or delay.  you
don't have to search for the service and set up conditions.  services
so invoked cannot track you: for this they'd have to know earlier
path-IDs, but they can only know those of the immediate predeccessor
and successor, and this only if they have been on the path themselves.

some of this requires im2000 messages to be properly authenticated,
and i'm still convinced that no message may call itself im2000
compliant if it left the im2000 infrastructure.  so nodes aren't
needed for benefits relating to im2000 users being authenticated, but
if you are an im2000 users, all the other benefits form a
communication platform that's simply much better and much more
flexible than SMTP can ever be.

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

and what is wrong about that?  on the other hand, you could put
headers into your message that result in the transfer of money for
some service.  say you want to communicate with a chinese partner
without knowing the language.  you know that there's an organization
certifying translators, and how much money you're willing to spend.
you could use headers like "ToChinese: XlatersGuild; < two days; < one
dollar USCurrency" into the message (please don't take this to be
what i think is the optimal syntax), and im2000 servers out there
would have find a translator accredited by the XlatersGuild and have
your post ready within two days for one buck.  this enables
specialized little companies to exist outside mainstream ISPs, but
drawing money the same way.

note that i'm still opposed to specifying details of cash management
into im2000s core protocol, but with electronic, authenticated
signatures we could have the protocol "credit card ready" easily.

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

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.

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

fact is that we can't have both a system capable of negotiating
contracts _and_ allow anonymity, but we need to provide both features.
we need not treat these diverting goals the same, though, but users
must be able to balance their need for privacy and their business
needs.  todays banks can do that, too, but they have to use special
software outside the regular internet channels.

but there's yet something that didn't show up in the last arguments:
mailinglists and preferences.  it's not much to do here, though:
given a message to your ISP ordering it to check for new messages at
certain places and apply your preferences.


  clemens