Create a MUC room for every screen and join / leave it as appropriate. Then
display the room roster in place of the users roster you currently have.
Much easier :-)
Hm, that's clever but I realize I may have misstated the situation a
bit. The user doesn't merely need to know whether those other
Am 25.11.2015 um 07:55 schrieb Daniel Dormont:
Hi,
I have an XMPP-enabled web application. In that I have several screens
where a user may see a list of names of several other users. I would
like that user to be able to see, in near-real time, basic presence
information for all of those names.
Am 15.06.2014 16:25, schrieb Emil Ivov:
Hey Marcel,
Thanks for responding. I certainly didn't mean to appear aggressive or
criticise the client as a whole. I definitely think it is an awesome
project and wish you good luck maturing and extending it!
I don't really agree with the views you expre
Am 13.06.2014 14:02, schrieb Emil Ivov:
Hey Marcel,
Congrats for the release.
same here, ^5 Klaus!
One question
On 12.06.14, 18:40, Marcel Waldvogel wrote:
* End-to-end encrypted audio and video calls from Firefox and Chrome
without plugin
Is this referring to WebRTC's use of DTLS-SRTP?
Am 04.12.2013 23:49, schrieb Dave Cridland:
Since we've been discussing XML parsers a lot...
https://github.com/dwd/rapidxml contains a fork of rapidxml that's been
randomly hacked^W^Wcarefully optimized to make it more useful in XMPP
projects that need particularly fine and/or controlled XML ha
Am 07.11.2013 22:03, schrieb Mathieu Pasquet:
On updating software/hardware, I think it is reasonable to assume that
anything that runs today is able to negociate TLSv1, which I consider
the baseline. The manifesto says that software that endorses it must
be able to negociate and prefer TLSv1.2;
Right now the manifesto is praising the merits of PFS too much and not
taking these implications into account. Or is there some way I don't
know about to make all above moot?
It's a manifesto. I suppose it will have to be adapted to match
deployment reality after the test runs.
I think setti
On Thu, 7 Nov 2013, Kwadronaut wrote:
That in itself isn't bad at all, rather the opposite, it's great. But
yes, what are the implications of a push towards this?
Openssl supports and accepts 16-bit DHE-group. [1] Current Java 6&7
don't like any DHE >1024bits (workaroud exists by using Bouncycast
Am 06.11.2013 21:02, schrieb Alexander Holler:
Not exactly the same, but I don't like the part
"or require cipher suites that enable forward secrecy"
for the same reason. OpenSSL 1.x isn't around that long, and there are
still many systems which do use e.g. Debian squeeze. And I assume the
stat
Whereas the deployment piece says
>o require the use of TLS for both client-to-server and server-to-server
connections
Doesn't that exclude Server Dialback? Please help me understanding this.
No. You use this (called starttls+dialback) if, after setting up TLS you
notice that you can't trust
Am 16.07.2013 21:36, schrieb Peter Saint-Andre:
[...]
Also helpful might be an automated service (xmpp.net?) that would
give you a report about your domain's s2s security status, if you
opt in of course.
+1 That would be cool!
OK, that sounds like a fun project. ;-)
I think buddycloud has s
Am 12.07.2013 23:01, schrieb Peter Saint-Andre:
But the real problems seem to be in deployments, not implementations.
Well, it's an awareness problem. Currently, nothing breaks when an s2s
certificate expires. That means those are continued to use for years.
Nobody notices. Heh, it still work
mattj thinks this ought to be announced here, too. Announcement text is
mostly courtesy of ralphm :-)
strophe.jingle is a webrtc connection plugin for strophe.js. Strophe is a
popular library for writing XMPP client applications that run on any of
the current popular browsers. Instead of the n
On Fri, 10 May 2013, Dave Cridland wrote:
On Fri, May 10, 2013 at 2:11 AM, Peter Saint-Andre wrote:
Thanks for sending your message. Unfortunately, I've only had time to
glance at the subject and haven't actually read it.
Right - true "read" receipts are impossible. But receipts a
has somebody experience with TLS level stream resumption in XMPP software?
http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions-00 is still
worth reading...
Has anybody implement this and made some tests? Is it worth the effort,
considering that in some situations (e.g. mobile) you ha
Unfortunately, I don't think I'm getting that error response with the
version of ejabberd that I'm using. I'll double check it and inquire
in the ejabberd list if this turns out to be the case.
if the error is delivered to the client the server is doing something
wrong. Even though (iirc) 6121
Matthew Miller typeth:
This is not official, and subjective to my personal views, but I would
recommend using the following to determine which to display:
1) highest priority (treat a missing as0)
2) timestamp, via jabber:x:delay or urn:xmpp:delay (treat a missing timestamp
as timestamp==rec
Dave Cridland wrote:
So the question is, can anyone not "see" me?
I can't see you. But then, I could not see you before because bidi +
sasl features on your side, so that does not change anything :-p
cheers
philipp
___
JDev mailing list
Info: http
Dave Cridland wrote:
Different servers do, and do not do, CRL checking. M-Link R14.6 does
not, whereas M-Link R15.0 can do (if asked). I don't think servers trust
incorrect or expired certificates ever, do they?
I don't think any servers trust incorrect or expired certificates (or
certificates
Badlop wrote:
bear wrote:
We will be setting up a test domain and will be providing a CA, so
each server would:
- have an issued Certificate(s)
2010/11/10 Philipp Hancke:
Testing cases where it should not work (like revoked certificates) is more
interesting than making sure things work
bear wrote:
I'm starting to gather information and get things in place for S2S
(and C2S) Interop and in that vein I would like to find out from the
XMPP world who would be able to participate.
The following are the thoughts in my head and have not gone thru any
formal discussion or XSF Board dec
Simon Tennant wrote:
Traffic can be intercepted, replayed and whatever... but sharing a
secret between users as a way to access a common resource without a
per-user audit trail, seems like something that should never fly in the
first place. Especially not in 2010.
No, that's 1990. The feature w
Daniel V. Grillo wrote:
Hi Folks,
I've built a minimal xmpp client to keep track of contacts presence
status. In previous versions, if a user asked a contact for a
subscription to
presence, my client automatically granted it. Now I want to notify a
contact of such a request and let them gran
Peter Saint-Andre wrote:
[...]
As a result, it is possible that admins might feel the need to request
multiple Class 1 certs in order to deploy an XMPP service (if they are
not able to obtain a Class 2 certificate). For example, at the
jabber.org service we might use one Class 1 certificate for t
Waqas Hussain wrote:
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
>
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.
and because XEP 0255 - example 7 shows the right way to do it.
___
Peter Saint-Andre wrote:
Because we want to do this:
openssl s_client -connect example.com:5223 -CAfile ca.crt
AFAIK there is no good way to do something similar for STARTTLS
connections. If you know of a way, please do let us know.
adding a xmpp-starttls to s_client is not that difficult...
Hi Sergei,
5) googlemail.com sends a key over the same TCP connection (!):
That's called "piggybacking".
=INFO REPORT 2007-09-19 20:35:32 ===
I(<0.5062.0>:ejabberd_s2s_in:317): GET KEY: {"nes.ru",
"googlemail.com",
Artur Hefczyc wrote:
On Tuesday 17 April 2007 08:09, Janne Savukoski wrote:
So, I guess the dialback has then some scalability advantages over
SASL. Naturally, supporting multiple domain connections over a single
TCP session lets you cut down the number of sessions to a fraction.
As far as I
Norman Rasmussen wrote:
- ejabberd-ircd: requires irc client, admin chooses muc server/component
one more (caution, advertisement follows):
- psyced: requires irc client, lets local ircers join local* rooms,
and talk to remote xmpp people (using xmpp:[EMAIL PROTECTED] syntax**)
Magnus Henoch wrote:
Indeed. I "solved" this by silently dropping private messages.
I don't know much of the IRC protocol beyond what's in RFC 1459. Is
there any way of abusing extending user specifications to achieve
something like this?
Even though iirc the ABNF in 1459 "forbids" it, you
Magnus Henoch wrote:
Sometimes the idea to move a discussion channel from IRC to XMPP MUC
is brought up, but fails for social and technical reasons: there are
more people who know how to use an IRC client than an XMPP client, and
IRC clients (and servers) are (allegedly) much better at handling
h
Peter Saint-Andre schrieb:
I can't remember why we even thought about allowing a client to bind
connection-timeout magic which pings the conflicting active resource
and hopes for a timeout before session binding happens possibly?
multiple resources with the same identifier, since it would pla
Vinod Panicker wrote:
According to to specification, resource must be unique, therefore it
>>is not allowed to have two same resources.
There's no such requirement in the RFC.
rfc 3920, section 3.4:
An entity MAY maintain multiple connected resources simultaneously,
with each connected resour
On Wed, 8 Mar 2006, Peter Saint-Andre wrote:
0. Image url can be disco'd given a jid.
1. Needs to be opt-in (no presence leaking)
Integration with JEP-0070 might also be desirable.
3. Jabber server and web server need to share information
alternatively, the jabber server has a built-in w
Justin Karneges wrote:
> For now, servers implementors seem to be taking matters
> into their own hands, and so not only do we have 1.0
> without SASL, but we have TLS+dialback.
What if SASL is implemented but there are no usable methods?
Let us assume we have successfully used starttls.
The serv
35 matches
Mail list logo
