Re: IM2000 over XMPP (warning: long)

* Wes Morgan:

> For the one-to-many emails, I assume that these lists can be stored
> on the list creator's IM2000 server (at their ISP, I'm
> assuming). Then, when someone sends a message to the list,
> [email protected], let's say, the IM2000 component will send a new
> message notification to [email protected]. Then the IM2000 component
> at myhost.com, upon receiving this notification, will look up the
> addresses in the mylist list and forward the new message
> notification to each of them.

since gmane.org came into existance, the community enjoys yet another
variant:  read http://news.gmane.org/gmane.mail.im2000 and post there,
no subscriptions needed!  although some list-admin choose to make
their lists non-public, which makes users subscribe to be allowed to
post.  i think most gmane lists are public, thanks to gmanes rigorous
anti-spam measures and (optional) the automatic TMDA "encryption" of
every contributors address.

so this hypothetical type of mailinglist doesn't need subscribtion,
thus there's no memeber-list.

users interested in [the next batch of] some mailinglist would send a
"wildcarded" download-request to a (cooperating/mirroring)
message-store, possibly send along the PGP/X509 key they want the
message contents to be encrypted to and the PGP/X509 keys they would
accept as signatures.  these keys must be an optional feature, highly
dependant on the lists setup and user preferences.

> As for negotiation, we can simply add flags to the new message
> notification that informs the receiver what kind of payload is being
> sent to them. They can then elect which parts they want to download,
> if any. We can send basically any data that cannot be easily made to
> grow ridiculously large by the sender (so, for example, size of
> attachment would be OK, but an unlimited length 'description' field
> would not). As long as we limit it to computed data (and not
> sender-input data), the new message notifications can be quite
> informative. And, because they're XML and inherently machine
> parsable, we can allow users to automate any part of that
> negotiation they desire (e.g.  auto-download attachments <=100KB of
> type text/plain, but nothing else).

keys would propably come from special keyservers, like the set of
servers keeping pgp.net, but with more control over the authenticity
of the keys and an option to withdraw/revoke keys.  i proposed a
scoring feature for this and other "agents" working on im2000, whereby
successful transmissions gain a "better reputation" than unsuccessful
ones, but others on this list fear this would open nastier cans of
worms, so this is anything but final.

nevertheless you should think about possible future services on the
net.  there may be a break-through in speech technology. my favourite
example is the nephew wanting to send a voice-greeting to his granny.
but her hearing-aid broke, so she set her preferences "text-only",
causing im2000 to negociate automatic conversion of said nephews
little song to text by some otherwise unrelated service.

i mean:  you should be aware of possibly long and complex
negotiations, since staying within im2000s namespace could mean
several unanticipated recodings and re-encryptions.  this is just to
keep that idea warm, the two basic bases im2000 has to cover are still
private and public emails with enough authentication to finally stop
spamming and enough reliablity to allow any amount of roaming and any
set of preferences.

> So, it would simply take the person's existing email address, and
> append '/im2000client' to the end to create a valid XMPP id. This
> packet, because of its XML namespace, would be forwarded to the
> IM2000 component by the XMPP server. The IM2000 component could then
> do whatever voodoo it needed to to the packet, and send it off to
> the recipient's XMPP server. Now, here's where it gets
> interesting... If the recipient's domain resolves to an IP address
> w/o a listening XMPP server (maybe we need to propose an MX-type DNS
> record for XMPP servers?), then the packet will bounce. When this
> occurs, the IM2000 component can simply use the Jabber -> SMTP
> gateway to send the message to the same address (minus the resource,
> obviously) via SMTP.

that's good!  easy transition from SMTP.

  clemens