[JDEV] RE: PUMP/PIMP...

[Thomas D. Charron]

>Yoni just left me with a list of email addresses for people he'd been
>talking to about PUMP, yours was on the top, sorry for the minor
>misunderstanding.

  Not a problem at all..  I am still interested in the entire idea of the PUMP protocol.  I think it is a VERY good idea.  Keep me on any lists regarding it, please..  ;-P

>My interest in the PUMP project is solely for the encryption. I believe that
>it is the most important part to Yoni as well. He and I have talked some
>about Jabber and possible absorption of PUMP by Jabber... I'm not sure where
>he stands emotionally on the issue, but I have some concerns that I would
>want addressed if we were going to merge. All of which have to do with
>encryption and it's implementation.

  After sitting back and looking at it, I'm not sure the projects really could ever merge, mainly do to the 'intent' of each.  Jabber's primary motives are for a sturdy, namespace independent system.  From what I have gathered regarding PUMP, it is more a 'secure communications method'.  In order for jabber to take on all aspects of PUMP, it would require the equivilent of building it into SMTP.  What we are more aiming at is the equivilent of SMTP with PGP extensions..  Unfortionalty, full encryption of messages will be an 'option', and not a 'requirement'.  Instead, I think the projects can borrow from eachother, instead of merging.  As it stands now, we COULD take the entire jabber system, and with VERY little rework, turn it into a PUMP system.  What I would like to see from a jabber standpoint is being able to use some of the encryption code that PUMP comes up with, and create a jabber transport around it.  This would allow us access to a transport with a high level of security, which we currently do NOT HAVE due to export limitations..  At the same time, your project would be free to use our code as you see fit, as it is all GPLed..

>I'm positive we'd be more than willing to supply you that information. We
>were aiming more at designing a protocol and implementing a compliant client
>and server, not necessarily the only implementation possible, but more of an
>example for how it could work. I'm also for submitting an RFC for the
>protocol, but I'm not sure how possible it would be, or how willing Yoni is
>to do it... We've only been talking a week or so.

  As I said, I'm still extremely interested, so keep me on the list..  Since our possible encryption methods are not set in stone, we can take your protocol and use parts of it to help ours..

>I know Yoni has strong feelings about that, I agree with him, I think that
>the client list is just as important to secure as the actual messages are. I
>would be willing to store the data on the server if I were sure that it were
>secure, I'm not sure Yoni would be so easy to convince.

  That's one the the reasons why I tend to think that they would not merge.  There are slight differences in the way we want to approach instant messenging.  We want something simular to the way IMAP works, and give users the ability to use anywhere, without worry of the implentation of the client..

>I have no issue with requiring that the user carry around a file which
>contains his contact list and personal keyset. I don't like the idea of
>storing the keys on a server, even if they are password protected....
>security, like all things, is only as strong as the weakest link, and the
>user password is usually that link. An 8 character password is at most 64
>bits strong, in reality an 8 character password is usually much closer to 20
>bits strong due to people's choices of passwords (i.e. no one uses the upper
>ASCII characters...). Hope to talk to you again soon.

  Security based point of view..  NOT a bad one, just different..  A client system could easily be made that would not store this data on the server, but on disk.  Again, we could implement that part of it, but completely throwing away the idea of beings 'Grandma's Instant Messenger' would be out of the question..

  Feel free to join the Jabber Development list if you want to discuss with the group possible implementations.  I think we would all benifit from eachother existence..



--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.