[Psi-Devel] QT Messenger Join Venture
Michael Schmidt
just a short question, from QT I came to your PSI Messenger, which
uses as well c++ and QT.
As far as I know, only 2 other messengers use QT:
sim-im.org (less activity, multiprotocol)
http://sourceforge.net/forum/forum.php?forum_id=618174
(serverless encrypted messenger)
(1) my request is, if there is interest to implement other protocols
like the serverless one
(2) if there is interest to merge all three project in PSI ?
So a serverless + jabber + multiprotocol ??
Regards mike.
_______________________________________________
Psi-Devel mailing list
Psi-...@lists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com
Hal Rottenberg
> So a serverless + jabber + multiprotocol ??
I don't see why we would want to do that. :)
--
Blog: http://halr9000.com
Webmaster, Psi (http://psi-im.org)
Co-host, PowerScripting Podcast (http://powerscripting.net)
Michael Schmidt
users (for ICQ, ao, msn, yahoo etc). and as rs serverless im will use
the QT gui of psi, here the question is, why psi should not add as
well serverless im- or to organize even a project merge to present a
common installer on both locations, once with the name psi and once
with the name rs - as rs will bring maybe as well a multimessenger
under the gui, to have the icq/aol/jabberfriends as well under the
gui.
Why not a commobn gui all three projects use ad the basic code merges
and then there developers as well, as this will bring more resources
and power to the team.
If this is not your focus to work together on a complementary product,
or QT gui, then change this request into implementing the serverles IM
as well into PSI
Regards Mike
2007/10/23, Hal Rottenberg <h...@halr9000.com>:
wwp
On Tue, 23 Oct 2007 07:22:08 +0200 "Michael Schmidt" <schmi...@googlemail.com> wrote:
> well is psi multiprotocol ? so some code from sim-im would bring more
> users (for ICQ, ao, msn, yahoo etc). and as rs serverless im will use
> the QT gui of psi, here the question is, why psi should not add as
> well serverless im- or to organize even a project merge to present a
> common installer on both locations, once with the name psi and once
> with the name rs - as rs will bring maybe as well a multimessenger
> under the gui, to have the icq/aol/jabberfriends as well under the
> gui.
>
> Why not a commobn gui all three projects use ad the basic code merges
> and then there developers as well, as this will bring more resources
> and power to the team.
>
> If this is not your focus to work together on a complementary product,
> or QT gui, then change this request into implementing the serverles IM
> as well into PSI
I do use ICQ, MSN and other protocols in Psi, w/o more problems than
the ones I was getting w/ other messengers in GNU/Linux (other
messengers who implemented direct protocols - Psi allows other protocols
using jabber gateways). Knowing this, what's the point in implementing
other protocols?
Regards,
--
wwp
Remko Tronçon
> Why not a commobn gui all three projects use ad the basic code merges
> and then there developers as well, as this will bring more resources
> and power to the team.
Psi's philosophy has always been to be a pure Jabber client. This is a
choice from religious (i.e. we don't want to promote non-open
protocol), legal (you're not allowed to connect to networks like MSN
with something else but MSN), and practical (focusing your client on
one protocol allows you to create a good, focused user interface, with
all the features that the protocol provides, instead of a common
denominator).
The lack of implementations of other protocols is compensated by the
fact that Jabber allows you to connect to other networks server-side
(transports), without having to implement the protocol yourself. So,
if we want Psi to be more MSN-friendly, we should improve the user
interface to make it easier to connect to Jabber transports, which
would make it 'seem' more multi-protocolish, without going against the
philosophy. Such an effort *would* be interesting.
cheers,
Remko
Kevin Smith
> (1) my request is, if there is interest to implement other protocols
> like the serverless one
> (2) if there is interest to merge all three project in PSI ?
There is a Jabber protocol for serverless messaging, and Psi will
implement it.
Other protocols, however, are not planned. Psi aims to be a very good
Jabber client, and bringing other protocols on board is only going to
compromise this.
/K
Michael Schmidt
> The lack of implementations of other protocols is compensated by the
> fact that Jabber allows you to connect to other networks server-side
> (transports),
2007/10/23, Kevin Smith <ke...@kismith.co.uk>:
> There is a Jabber protocol for serverless messaging, and Psi will
> implement it.
>
Hi Kevin, Remko and wwwp & List
serverless is better than serverbounded.
A Transport is always serverbounded (ok as the original protocol as well,
but you need to register a second server account in jabber to get access to aol)
so serverless jabber is quite interesting
found this jabber2 description:
https://sourceforge.net/tracker/index.php?func=detail&aid=1772358&group_id=178712&atid=886242
so why not a serverless jabber implementation of rs into psi?
Regards.
Michael Schmidt
> The lack of implementations of other protocols is compensated by the
> fact that Jabber allows you to connect to other networks server-side
> (transports),
2007/10/23, Kevin Smith <ke...@kismith.co.uk>:
> There is a Jabber protocol for serverless messaging, and Psi will
> implement it.
>
Hi Kevin, Remko and wwwp & List
serverless is better than serverbounded.
A Transport is always serverbounded (ok as the original protocol as well,
but you need to register a second server account in jabber to get access to aol)
so serverless jabber is quite interesting
found this jabber2 description:
https://sourceforge.net/tracker/index.php?func=detail&aid=1772358&group_id=178712&atid=886242
so why not a serverless jabber implementation of rs into psi?
Regards.
Kevin Smith
> so serverless jabber is quite interesting
> found this jabber2 description:
> https://sourceforge.net/tracker/index.php?
> func=detail&aid=1772358&group_id=178712&atid=886242
> so why not a serverless jabber implementation of rs into psi?
As I said previously, there is a protocol for serverless
communication as a Jabber extension, and we will implement that.
It has nothing to do with retroshare though. It turns out that the
post you reference seems to just be an attempt to push themselves
higher in the search engine ratings (or perhaps give the illusion of
some endorsement). The linked document claiming to be an RFC written
by a member of the jabber coder foundation is not an RFC, and there
isn't a jabber coder foundation; there /is/ an XMPP Standards
Foundation (formerly the Jabber Software Foundation), but the author
of that document is not a member. Jabber2 was presumably cynically
chosen to cash in on the success of Jabber, despite being entirely
unrelated.
The official protocol for serverless messaging is available at
http://www.xmpp.org/extensions/xep-0174.html
We will support this in the future.
/K
Michael Schmidt
this was a real interest, heard about jabber serverless, but did not
know, that is is already such elaborated, that clients build it in. As
I read here, for the RS DHT a protocol adjustment is planned and
possible, maybe they switch as well to xep174.
http://retroshare.wiki.sourceforge.net/devel-core-im
Would you suggest this? and then.. why not a cooperation in this development?
Did you read this:
"4. Discovering Other Users
In order to discover other users, a client sends an mDNS request for
PTR records that match "_presence._tcp.local.". The client then
receives replies from all machines that advertise support for
link-local messaging. [11] The client MAY then find out detailed
information about each machine by sending SRV and TXT queries to
"username@machine-name._presence._tcp.local." for each machine
(however, to preserve bandwidth, the client SHOULD NOT send these
queries unless it is about to initiate communications with the other
user, and it MUST cancel the queries after it has received a
response). Note: The presence name to be used for display in a
link-local "roster" SHOULD be obtained from the <Instance> portion of
the received PTR record for each user; however, the client MAY instead
display a name or nickname derived from the TXT records if available."
A DHT is much better than DYNDNS or forholding the IP, which may dynamically.
So lets talk about the serverless implementation into PSI.
Why not a DHT?
Kind regards Mike
2007/10/23, Kevin Smith <ke...@kismith.co.uk>:
> On 23 Oct 2007, at 07:40, Michael Schmidt wrote:
> > so serverless jabber is quite interesting
> > found this jabber2 description:
> > https://sourceforge.net/tracker/index.php?
> > func=detail&aid=1772358&group_id=178712&atid=886242
> > so why not a serverless jabber implementation of rs into psi?
>
> As I said previously, there is a protocol for serverless
> communication as a Jabber extension, and we will implement that.
> The official protocol for serverless messaging is available at
> http://www.xmpp.org/extensions/xep-0174.html
> We will support this in the future.
>
Remko Tronçon
> So lets talk about the serverless implementation into PSI.
> Why not a DHT?
What is DHT? And DynDns is indeed useless, since requires a central
(DNS) server, so you're no longer 'serverless'.
Why do you think serverless messaging is so interesting? The only
interesting thing about serverless messaging is when you are in a
network without any connection to the internet. This is what
link-local messaging is about, and this is what we will design in psi.
This is what we will implement.
cheers,
Remko
Andreas Ntaflos
> > A DHT is much better than DYNDNS or forholding the IP, which may
> > dynamically. So lets talk about the serverless implementation into PSI.
> > Why not a DHT?
>
> What is DHT? And DynDns is indeed useless, since requires a central
> (DNS) server, so you're no longer 'serverless'.
DHT means, as far as I know, Distributed Hash Table and can be used by
peers/nodes in a distributed system to talk to each other without a central
authority/server managing the communication. Trackerless Bittorrent is a
popular use case for this I think.
> Why do you think serverless messaging is so interesting? The only
> interesting thing about serverless messaging is when you are in a
> network without any connection to the internet. This is what
> link-local messaging is about, and this is what we will design in psi.
> This is what we will implement.
I think it has more to do with valid "paranoia". Serverless IM probably allows
more secure communication between two people as there is no server in-between
them that could have a malicious admin who likes to eavesdrop or do a
man-in-the-middle-attack. Of course using GnuPG for end-to-end encryption
would effectively prevent such a scenario but knowing how most people think
setting up GnuPG is too big of a hassle.
Serverless IM presumably would feature encryption on the transport level
somehow so it woud be easier and more secure "out of the box", without users
having to set up end-to-end encryption manually.
Assuming, of course, I understood the concept correctly. It seems like much
talk and little walk at the moment. :)
Andreas
--
Andreas "daff" Ntaflos
Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Hal Rottenberg
> A DHT is much better than DYNDNS or forholding the IP, which may dynamically.
> So lets talk about the serverless implementation into PSI.
> Why not a DHT?
We are talking about implementing an existing XMPP standard, Link
Local Messaging, into Psi as our chosen means of providing serverless
IM. Psi could be called one of the "core" XMPP clients. We are major
proponents of the XMPP protocol and what it stands for. Arguments for
DHT are irrelevant as there is not a peer-reviewed,
standards-body-approved, method of using distributed hash tables for
IM and presence that has anything to do with XMPP.
If you have a compelling technical argument to make, make it on JDEV
(and bring your own implementation because that's a developer list) or
the XMPP Protocol Extension mailing lists. Those can be found here:
http://www.xmpp.org/about/discuss.shtml
--
Blog: http://halr9000.com
Webmaster, Psi (http://psi-im.org)
Co-host, PowerScripting Podcast (http://powerscripting.net)
Hal Rottenberg
> I think it has more to do with valid "paranoia". Serverless IM probably allows
> more secure communication between two people as there is no server in-between
> them that could have a malicious admin who likes to eavesdrop or do a
> man-in-the-middle-attack. Of course using GnuPG for end-to-end encryption
> would effectively prevent such a scenario but knowing how most people think
> setting up GnuPG is too big of a hassle.
>
> Serverless IM presumably would feature encryption on the transport level
> somehow so it woud be easier and more secure "out of the box", without users
> having to set up end-to-end encryption manually.
I think you've described the argument well. However the lack of a
server does not make something inherently more secure. That was a
fallacy which came about in the early P2P days, but has since been
very stoutly disproven. You can find this out by reading almost any
"YRO" story on Slashdot. Honeypots and fake clients infect all the
P2P systems nowadays, extracting all kinds of useful information.
--
Blog: http://halr9000.com
Webmaster, Psi (http://psi-im.org)
Co-host, PowerScripting Podcast (http://powerscripting.net)
Remko Tronçon
> somehow so it woud be easier and more secure "out of the box", without users
> having to set up end-to-end encryption manually.
Weird as it may sound, serverless IM is *a lot* more subject to
security attacks than server-based IM, unless you check identity
thoroughly (something that is easier to check in the server-based
case). Bottom line: you need end-to-end encryption to be perfectly
safe, and if you have that, you might as well use server-based IM.
dev
point is ... SSL can be used as e2e encryption if it is serverless.
But SSL can't be used if you are routing it through the server. and
SSL kicks ass unlike some of the other encryption proposals we know :)
.. It is simple , fast and well tested .
I don't know how valid this is for XMPP(meaning if it is possible to
use SSL in serverless XMPP) , but this is what I have noticed in
general for any distributed system
my 2c.
Regards,
dev
Michael Schmidt
http://retroshare.wiki.sourceforge.net/devel-core-openpgp
2007/10/23, dev <dev.a...@gmail.com>:
Kevin Smith
> yes, RS uses PGP (Open pgp me) and it is very convenient.
> http://retroshare.wiki.sourceforge.net/devel-core-openpgp
Okay, this has been a reasonable thread as far as it's gone, but I
think it's time to wrap it up now, I've read some of your other
threads; I've seen you approaching thunderbird and evolution and
openoffice and ... etc. The simple truth here is that Psi is not
going to implementing retroshare, both for technical reasons, and for
the fact that the whole 'Jabber2' thing is downright insulting.
/K
Andreas Ntaflos
> > Serverless IM presumably would feature encryption on the transport level
> > somehow so it woud be easier and more secure "out of the box", without
> > users having to set up end-to-end encryption manually.
>
> Weird as it may sound, serverless IM is *a lot* more subject to
> security attacks than server-based IM, unless you check identity
> thoroughly (something that is easier to check in the server-based
> case). Bottom line: you need end-to-end encryption to be perfectly
> safe, and if you have that, you might as well use server-based IM.
Of course. All serverless IM protects you against is a malicious admin, and
some derivations thereof (for example an overly nosey employer).
Nonetheless a well-designed, well-implemented serverless IM protocol (not
talking about XEP-0147 now, which is something else entirely) would probably
go a long way to ensure enhanced security with less responsibilities on the
user-side, but an ultimate solution it certainly cannot be (and far be it
from me to know how to design and implement such a system).
And, as Hal mentioned, most P2P and distributed systems can be attacked with
fake clients and honeypots so the advantage of not having a dirty admin on a
server is probably outweighed by much by the disadvantages of a DHT-based
system.
You are of course right, the only really safe choice is end-to-end encryption
initiated by the user.
Anyway, I was just trying to articulate what I think Michael Schmidt's point
was. :)