[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at leas
[Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at least)
Mon, 16 Jul 2001 19:44:49 +0000
On Monday 16 July 2001 04:23, Adam Theo wrote:
> I have a proposal to make. I have been thinking about this all day, and
> believe I am ready to advocate such a position.
> Before this point I believed DotGNU's best idea was to take the fully
> client-side, P2P route for authentication, since it seemed to 'fit' with
> the GNU philosophy the best. But after some thought and reading the
> recent threads on this list, I have come to believe otherwise.
> And for Authentication and Identity for the Jabber system, this is being
> taken care of, as well. By none other than myself and a small group of
> others who are making fast progress on an open, flexible, powerful, and
> very secure Identity system that runs using Jabber. For more information
> on this, head over to http://www.theoretic.com/identity .
I read over the identity project. May I be so bold to make ask a few
questions, make some comments:
1) In a P2P or C2C transaction, how do you trust your peer? Do you by
default trust your peer? If so, this adds risk into the transaction.
2) Take ebay.com for example. It's a C2C transaction. Risk for ebay.com
transaction is very high. Ebay.com sets up a message board to increase the
trust of a C2C transaction. If there are a lot of high praise for this
individual it means the risk is lowered. In a sense, to verify trust in a
C2C transaction, you consult your peers to see the other peers are trusted.
> Now, if all of you are still skeptical about how Jabber can be used, I
> propose that this list choose one or two people from among us to learn
> about Jabber. Give them a week or so, and have the report back to the
> list on what they think. This way all of us can see how Jabber looks
> from a FSF and DotGNU perspective, without all of us having to learn
> about it.
I have a keen interest in Jabber as a messaging solution, i.e. groupware
application. I especially like the concept of "store and forward" messaging
technology. Last I saw someone used MS messenger or AIM do not have that
feature. Yahoo messenger does have "store and forward".
I just finished reading the spec for Jabber standard protocol and a draft
version. The draft version is getting a bit more sophisticated and added
digital signature. However, I'm curious how does the jabber framework do
message routing and workflow. For example, I want a message signed by 4
people. First by me, then by my manager, then by my manager manager, and
then by the CFO. How does Jabber draft protocol ensure the message integrity
and route this message accordingly?
> The only problem, and I repeat the *only* problem I can see any of you
> having with Jabber is licensing. The Jabber protocol itself is licensed
> undfer the Jabber Open Source License (JOSL), which is BSD and MPL in
> origin. This was decided the best license for their needs at the time
> because they wanted to get businesses and other developers to take up
> the Jabber system. Therefore they allowed proprietary extensions and
> narrowed the definition of 'derivitive work'. This has worked very well
> for the needs so far, and would allow everyone (including everyone here)
> to do what they want with the system.
I don't know much about license. I wish I learned more about laws. Right
now licenses are a mess. There are soo many open source licenses. And even
the highly accliam GPL is now being scruntize after so many years. (I'm
referring to the NuSphere vs MySQL AB)
> Now, the Jabelin server may not become GPL'ed. There have been a lot of
> contributors, some of whom may not want the GPL. Howevere, as I said
> above, it is the protocol, not the server, that makes the Jabber system.
> I, and I know Jeremie, would love to see another Jabber server being
> built. It would re-enforce the "Jabber is the protocol" point.
There a lot of great ides in the jabber as a protocol. I wouldn't mind if we
work together to draft up a General XML Messaging Protocol and license it
under GPL. This way we can work in the open while pissing the *ahem* company
who loath GPL with a passion.