gmane.network.jabber.devel

Re: Inclusion of Pingpong at http://xmpp.org/xmpp-software/clients/

Dave Cridland — 2012-05-17T10:46:56

I'm afraid this doesn't really help me understand why you want it  
listed here.

If PingPong requires its own client, then presumably it's not XMPP -  
or at least, if it's not allowing any client, then it's not the kind  
of XMPP service we normally list.

If talk.to requires that it's used with your service, then again it's  
not really the kind of client we'd list. Lots of service specific  
clients exist, and we don't list them because they're of no use to  
someone looking for an XMPP client to use with a service of their  
choice.

This isn't a reflection on your service, of course - it's simply it's  
not really the kind of thing we include there, just as we don't  
include other, similar services and clients. If we did, then services  
such as Evolve would be listed, and we'd list TextOne as well as  
OneTeam. All of these types of services and specialist clients are  
very interesting, and maybe the XSF should publish a round-up  
interview about the use of XMPP in these services, but it's not cle

Re: Jingle WebRTC implementation

Yann Leboulanger — 2012-05-17T10:01:33


Gajim doesn't implement any transport itself, it uses farstream for 
that. So ask Collabora to implement SRTP in farstream instead.

Re: Inclusion of Pingpong athttp://xmpp.org/xmpp-software/clients/

Vishal Sukheja — 2012-05-17T08:34:29

Hi Peter,

Thanks for your mail.

To answer the questions raised in your mail, Pingpong is our hosted 
service that organizations can sign up for.
To access the Pingpong service, the user needs to use the Talk.to client.

Hope this clarifies.
Please revert in case any more information is required regards this.

Re: Inclusion of Pingpong athttp://xmpp.org/xmpp-software/clients/

Peter Saint-Andre — 2012-05-16T16:16:43

Hi Vishal,

It's slightly unclear to me whether Pingpong is a service that
organizations can sign up for, or a client that people can download to
run at their own domain or device. Could you please clarify?

Thanks!

Peter

Re: Federation discovery problem

Peter Saint-Andre — 2012-05-16T12:32:50

Just initiate communication with server2 or an account on that server
(e.g., send a service discovery request to server2 or a presence
subscription request to someuser< at >server2). If there's no federation,
you'll receive a remote-server-not-found error.

Peter

Federation discovery problem

Dariusz Kiełkowski — 2012-05-16T11:40:00

Hi all, 

I'm writing application which main purpose is to connect to xmpp server. Lest suppose that I have account on server1.com, friend of mine, have account on server2.com how do I know, how may I check, that they can communicate each other? 

Best regards
Lardux
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

Re: Jingle WebRTC implementation

Sergey Dobrov — 2012-05-16T11:21:41

Hello and thanks for your answer.


Thanks for clarifying.


Where can I post a ticket for that? :) This can help anyone to implement
this in their projects. And then it would be easier to make gateways to
other networks including WebRTC calls.

Re: Jingle WebRTC implementation

Emil Ivov — 2012-05-16T10:53:16

Hey there,

On 16.05.12 12:42, Sergey Dobrov wrote:

Just to be clear here: SRTP is a transport protocol and ZRTP is one key
negotiation mechanism among others, that works with SRTP. Another
popular key negotiation mechanism that also uses SRTP is SDES. I suppose
that in this case you were referring to SDES.

We do have SDES in Jitsi but it's currently only implemented for SIP.
Adding it for Jingle should be rather trivial.

Cheers,
Emil

--
http://jitsi.org

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

Re: Jingle WebRTC implementation

Sergey Dobrov — 2012-05-16T10:42:13

I have discovered that at the moment it's impossible to implement Jingle
on top of WebRTC because of this bug:
https://groups.google.com/forum/#!topic/discuss-webrtc/6K95fm0r2J4

Still can't understand if jitsi actually can do SRTP communications (and
not ZRTP).

Created a ticket for Gajim to implement SRTP:
https://trac.gajim.org/ticket/7157

On 05/15/2012 07:34 PM, Sergey Dobrov wrote:

Jingle WebRTC implementation

Sergey Dobrov — 2012-05-15T12:34:13

Hello,

I am trying to implement Jingle in my habahaba project
(http://habahaba.im/) and trying to find another Jingle implementation
to test with and see that the situation with them is awful.

To establish a connection, WebRTC requires to use SRTP and not RTP.
Okay, have we any client that can do that? I don't see any except of
jitsi that judging by code has some support of jingle:encryption
element. But in actual fact, it seems for me, that jitsi can use only
ZRTP for outgoing sessions and can serve SRTP for incoming sessions.

Okay, try to use it! Make outgoing call from my web client to jitsi.
Send "session-initiate" populated with my contents and transports and
expect for "session-accept" but suddenly receive "transport-info". Is
this behavior of jitsi correct? I look throw flows in XEPs and don't
understand how I can process "session-accept" here.

If anybody can suppose a client with SRTP support, I will be grateful.
Anyone interested in the project is welcomed for the discussion.

Inclusion of Pingpong athttp://xmpp.org/xmpp-software/clients/

Vishal Sukheja — 2012-05-14T13:35:25

Hi,

Hope you are doing great.

I would like to have our Pingpong service included in the Jabber client 
listing at http://xmpp.org/xmpp-software/clients/
Pingpong is a great instant messaging (IM) service that lets you chat 
with your colleagues using your official Id. Awesome features like 
Persistent groups, File sharing, Chat history, Company Directory, Read & 
Delivery notifications, Free SMS & more.

Name: Pingpong
Platforms: Desktop (Windows), Mobile (iOS, Android), Web, Chrome app for 
Linux and Mac (dedicated Mac app as well as client for Windows Phone 
coming shortly)
License: Freemium (features like unlimited chat history and increased 
file sharing limits for Pro)
Details: http://talk.to/pingpong

PAD file link for submission: 
http://talk.to/api/desktop/pingpong_padfile.xml<http://talk.to/api/desktop/talk.to_padfile.xml>

Please advice if any other info is required from our end.

Looking forward to a mutually rewarding relationship.

Re: High level XMPP Javascript client

Peter Saint-Andre — 2012-05-07T19:37:44

Added to the libraries list:

http://xmpp.org/xmpp-software/libraries/

Peter

Re: xmpp.org libraries: aSmack

Alexander Gnauck — 2012-05-02T18:42:13



I have updated the URL.

Alex

--
Alexander Gnauck
xmpp:gnauck< at >jabber.org
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

xmpp.org libraries: aSmack

Florian Schmaus — 2012-05-02T13:41:28

Hi everybody,

I'd like to suggest to change the URL for aSmack - which is the Smack 
port for Android - to another repository. The current link is to Rene 
Treffer's initial asmack repository, which hasn't seen any updates in 
the last 2 years. I'd really like to thank Rene for his work here! It 
resulted in forming a small community of Android developers that have 
taken care of asmack at:

https://github.com/Flowdalic/asmack

asmack is now in sync with smack, has full file transfer support on 
Android (XEP-0065, XEP-0096, XEP-0047), there are compiled jars ( 
https://github.com/Flowdalic/asmack/downloads ) and we idle at ##smack < at > 
freenode to help new users.

This version of aSmack is currently used by
- yaxim
- GTalkSMS

Oh, and it would be nice if you could add GTalkSMS to the lists of XMPP 
Apps. But since it's not really a XMPP client, a new section, maybe 
named "components", should be introduced. :)

Regards
  Florian
_______________________________________________
JDev mailing list
Info: http://ma

Re: current state of "invisibility"

Matthew Wild — 2012-04-30T17:08:25

It sure is :)

Regards,
Matthew
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

Re: current state of "invisibility"

Matthew Miller — 2012-04-30T17:08:39

On Apr 30, 2012, at 11:02, Peter Saint-Andre wrote:


Negative priority is potentially a hint to the UA not to display to the receiving user, but that requires the client to do the right thing and treat negative priority as offline/unavailable.  Few clients (most likely none) do the right thing today.

I believe it matters if that information is concerning or not.  If not, then simple negative priority is probably fine.  If it is, then negative priority + invisibility is necessary.


- m&m

Matthew A. Miller
<http://goo.gl/LK55L>

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

Re: current state of "invisibility"

Matthew Wild — 2012-04-30T17:07:44

Most clients will show clients with negative priority. You can still
send direct messages to them, for example - so I might do it on my
phone or another device I don't want to receive bare-JID messages. I
think Dave's case is more an automated client that doesn't want to
send any presence to contacts at all, but still wants to receive
presence from them.

Regards,
Matthew
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe< at >jabber.org
_______________________________________________

Re: current state of "invisibility"

Peter Saint-Andre — 2012-04-30T17:02:50

Isn't that presence with negative priority?

Peter

Re: current state of "invisibility"

Peter Saint-Andre — 2012-04-30T17:02:05

Sounds like a good starter project for someone who wants to get involved
with server or client development. :)

Peter

Re: current state of "invisibility"

Dave Cridland — 2012-04-30T16:45:08

I think the "right" thing is to use XEP-0186, but that's seen very  
limited support on the server.

I'm increasingly finding some interesting use-cases for invisibility,  
such as email clients that need to be presence aware - I don't see a  
need for confusing the contacts' roster by showing myself online when  
I'm not, as such.

Dave.

Re: current state of "invisibility"

Matthew Wild — 2012-04-30T16:43:56

For general compatibility, XEP-0126 is best - unlike XEP-0018 it
doesn't mess with core XMPP. From a high level it's also far from
ideal though. While privacy lists are already implemented in many
clients and servers, it makes for one ugly and complicated way to say
"Hey, I just want to be online without people seeing me!".

My eggs are in XEP-0186's basket. It would take an hour at most to add
support for it to Prosody, and it's likely as trivial for other
servers too. It also couldn't get any easier from the client's
perspective.

The main problem is that this isn't moving - most people, XMPP
developers at any rate, seem comfortable /enough/ with the current
situation to not be rushing to implement this.

Therefore if any client has or is implementing XEP-0186 support and
wants to test it against Prosody then feel free to poke me off-list.


You can get the list of lists:
http://xmpp.org/extensions/xep-0016.html#protocol-retrieve

Regards,
Matthew
_______________________________________________
JDev maili