QT Messenger Join Venture

Hi

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-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

On 10/22/07, Michael Schmidt <schmidtm524googlemail.com> wrote:
> 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)
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

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

Regards Mike

2007/10/23, Hal Rottenberg <halhalr9000.com>:
> On 10/22/07, Michael Schmidt <schmidtm524googlemail.com> wrote:
> > 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)
> _______________________________________________
> Psi-Devel mailing list
> Psi-Devellists.affinix.com
> http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com
>
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

Hello Michael,


On Tue, 23 Oct 2007 07:22:08 +0200 "Michael
Schmidt" <schmidtm524googlemail.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

_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

Hi Mike,

> 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
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

On 22 Oct 2007, at 23:13, Michael Schmidt wrote:
> (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
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

2007/10/23, Remko Tronçon <remkoel-tramo.be>:
> 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 <kevinkismith.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=17723
58&group_id=178712&atid=886242

so why not a serverless jabber implementation of rs into
psi?

Regards.
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

2007/10/23, Remko Tronçon <remkoel-tramo.be>:
> 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 <kevinkismith.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=17723
58&group_id=178712&atid=886242

so why not a serverless jabber implementation of rs into
psi?

Regards.
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

On 23 Oct 2007, at 07:40, Michael Schmidt wrote:
> so serverless jabber is quite interesting
> found this jabber2 description:
> https://so
urceforge.net/tracker/index.php? 
>
func=detail&aid=1772358&group_id=178712&atid=886
242
> 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://w
ww.xmpp.org/extensions/xep-0174.html
We will support this in the future.

/K
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com

Kevin, thanks for the info,
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
"usernamemachine-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 <kevinkismith.co.uk>:
> On 23 Oct 2007, at 07:40, Michael Schmidt wrote:
> > so serverless jabber is quite interesting
> > found this jabber2 description:
> > https://so
urceforge.net/tracker/index.php?
> >
func=detail&aid=1772358&group_id=178712&atid=886
242
> > 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://w
ww.xmpp.org/extensions/xep-0174.html
> We will support this in the future.
>
_______________________________________________
Psi-Devel mailing list
Psi-Devellists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com