[DotGNU]Re: A Proposal for a Solution (Jabber)

[Adam Theo]

Norbert Bollow wrote:
> 
> > 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.
> 
> Let's move this discussion to the developers mailing list, so
> that it won't get in the way of the work of the auth list (which
> is to quickly create that that quick-and-dirty first incarnation
> of DotGNU virtual identities. )

yes, i agree, and am starting to do so now. from now on thius list will
be about advocating using Jabber as a basis or in *some* way for DotGNU.

> 
> "Dan Kuykendall (Seek3r)" <address@hidden> wrote:
> > I never agreed with those that think this can all be done peer to peer.
> > Sometimes it is best for companies to implment a trusted auth server in
> > their environment
> 
> Yes.  That's why the long-term implementation of "DotGNU virtual
> identities" will be done on the DotGNU platform, the
> http://dotgnu.org/arch.htm for some details.
> 

yes, i feel that Jabber has many benefits, and is powerful, flexible,
and with some work, more than secure enough for our needs at DotGNU. I
can easily see Jabber not only solving the Virtual Identities problem in
the long run, but also solving some web services and distributed
computing needs of DotGNU in general.

> The key point is that then the auth system, just like any other
> application that runs on this platform, can run in P2P mode, and
> it can run with a single trusted auth server, and it can run with
> a network of auth servers where the auth database is replicated
> on each auth server, and the copies of the database are
> automatically kept in sync.

not sure what your point is here, sorry. probably just because it is
after midnight here, and i'm tired a bit....

> Yes, XML has a lot of mindshare.  It will be wise for DotGNU to use
> protocols that are built on XML.

yes, this is something i agree with completely! XML is the way to go,
and pre-existing protocols are the way to go, as long as they fit in
perfectly with what you need to do. no need to re-invent *any* part of
the wheel just because you want to create something grand and new.

so, at the very least, XML. let's try to have DotGNU be a 100% XML
system. it is certainly possible, and has many benefits.

and, to hype my main point, let's take a look at how the Jabber protocol
can take care of what we need now. we are getting an idea of what we
need in this DotGNU system, so let's see how Jabber can fill in as many
of those needs as possible, so we don't have to take the massive amount
of time to do it ourselves.

after all, we *need* DotGNU to be nearly done and working well within a
year. or at least have something great to show for it. if we don't, we
stand a good chance of being left behind, even if we have a superior
technology (just think of all the times this has happened in the past to
others... oodles and oodles of times.). making use of technologies and
protocols that already exist and fit our needs while being 100% open
source/GPL will save us *so* much time.

> 
> > > 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 agree with this plan. I would jump in and start studying jabber in
> > more depth if you guys want.
> 
> Sounds good to me.  However before you do this, please have a
> good chat (perhaps on #dotgnu) with Myrddian <address@hidden>
> and Barry Fitzgerald <address@hidden>.
> 
> Myrddian and Barry are working on some ideas and specs that you
> should be aware of when you look at the Jabber for checking
> whether the protocol would be useful for DotGNU.

ok, will do. i don't use IRC, but i will contact them by email.

> 
> > 1) It exists, and is a working distributed solution
> > 2) Its been gaining acceptance over time
> > 3) It has several companies backing it as well as many in the free
> > software community
> > 4) Its got plenty of 'coolness' factor, which cant be overlook even tho
> > it may sound silly to outsiders, 'coolness' is a key ingrediant to a
> > successful free software project
> 
> I agree that these are good reasons for looking into Jabber.

yes, especially the first and fourth.

Myrddian wrote:
> Well Jabber as far as I see it is a good way for the Virtual Identities 
> system to work.
> However, the scope of DotGNU is far more larger and is a tad bit more scaled 
> that
> Jabber
> was intended for ( I feel any how ). So extensions as such and a better 
> mechanism
> might be needed. I'll have to read more on it any how, but it's quite good so 
> far :) 

ok, p2p: when jabber was first really being designed (back in 1998, i
believe), p2p was just hitting the streets. jabber was originally
designed with a server/client model, but now that p2p is proving itself
to be a worthy model, jeremie miller and the other founders are starting
to turn it into a p2p system, at least much more so than it already is.
and this will not take much work. the jabelin server (the OSS
implimentation of the protocol) is very small. small enough to be
embedded into a p2p client itself with minimal work, bringing it closer
to a true p2p model.

scaleability: jabber is very scaleable. it is currently being used by
many different organizations on many different networks for many
different needs. one person i know just installed it at his office, for
his co-workers to communicate with each other. he has easily set it up
on their internal network, and the boss knows they are not using it to
chat with friends or family while on the clock. the jabber.org local has
i think thousands of users on it, and it is not a top of the line server
at all, if i recall correctly.

anyone can run their own jabber server, like they can run their own
sendmail or nntp server... and it can talk to the outside world or only
be used for internal office talk.

it uses xml, and is open to embedding other xml specs in it's messages.
therefore it is easy to do SOAP and/or XML-RPC calls over the jabber
system, or to send custom formats only the recipient is intended to
understand and use.

one of the neat things about jabber is the username and resources. the
jabber user name (or JID as we call it) looks like an email address:
address@hidden but it can also (note: optionally) have a 'resource',
which comes after a slash at the end of the JID:
address@hidden/resource. a resource is like a 'sub-account' (or you
can think of it that way). a user can log into a resource under their
account for special purposes. and you can be logged into your account
simultaniously as long as it is from different resources. so say you
have 3 jabber client s running right now: your desktop comuter one,
named 'desktop', the one embedded into Mozilla which is embedded into a
kitchen net appliance next to your stovetop named 'kitchen', and another
in your car (for when you are on the go) named 'auto'. now, someone can
send to a specific resource, and you will get it only there, or can just
send to your account in general (normal) and get you wherever you are at
the moment.

i see the above thing of resources as having lots of potential, which i
explain below:

for DotGNU, you will need an addressing or ID scheme, right? some sort
of identifier system to use so the components and applications in DotGNU
know where each other are at. now, you could use the normal
http://www... URL system, except that depends on the www and web
servers, as well as the http protocol, correct?

how about using jabber's naming and addressing infrastructure? it
already exists, and already has support for it. so your DotGNU
application's 'name' could be address@hidden or if you want to
use resources: address@hidden/wordprocessor. it would log into it's
jabber/dotgnu account and send a SOAP-ized jabber message to some other
application, residing at address@hidden/tryme or whatever.
the other application could then reply, sending back the spell-checked
document.

this is just a beginning. but the advantage to using his, is that the
addressing, resolving, and identifier systems are already specified and
in place.