On 5 October 2015 at 14:22, Matthew Wild wrote:
> This is technically achievable using security labels
> (http://xmpp.org/extensions/xep-0258.html ), though it hasn't really
> been deployed that way on the public network, and not many clients
> support it (though Swift and Gajim both do, and they
On 05.10.2015 at 03:04, Mike Barnes wrote:
> What we need to be doing is putting information about the quality of
> encryption used in a conversation in front of the users, and letting
> them make informed decisions, instead of fracturing the network
> invisibly.
What comes to my mind here, is how
Well as it is a standard for pretty much every protocol now why should we hold it back?17:57, 5 October 2015, Mathias Ertl :Hi,On Mon, Oct 05, 2015 at 09:45:11AM -0500, Sam Whited wrote: This all seems perfectly reasonable to me; if you don't have PFS enabled ciphers, I don't understand why you'd e
Hi,
On Mon, Oct 05, 2015 at 09:45:11AM -0500, Sam Whited wrote:
> This all seems perfectly reasonable to me; if you don't have PFS
> enabled ciphers, I don't understand why you'd expect to be able to be
> part of the network these days.
I completely agree. Support for PFS ciphers is not something
This all seems perfectly reasonable to me; if you don't have PFS
enabled ciphers, I don't understand why you'd expect to be able to be
part of the network these days.
Maybe as part of the 2016 compliance suites (which I'm in the process
of writing to propose to the XSF council, see standards@ for
That's actually a good idea,I should get around to adding a list of inaccessible servers on my site as well.15:39, 5 October 2015, Vicious Feline :Im running my servers since five years now. I have a good documentation on my page which servers are not reachable. It's a point where I am very strict.
Im running my servers since five years now. I have a good documentation on my
page which servers are not reachable. It's a point where I am very strict. No
s2s encryption no service. In those five years I had two tickets from users
which tried to reach a server which was not able to encrypt.
-
On 5 October 2015 at 02:04, Mike Barnes wrote:
> What we need to be doing is putting information about the quality of
> encryption used in a conversation in front of the users, and letting
> them make informed decisions, instead of fracturing the network
> invisibly.
I semi-agree. Once I would ha
+1
>> but we
>> desperately need the equivalent of the old email "non-delivery report"
>> going back when connections are refused or non-technical users on
>> older servers are never going to even know there's anything wrong. All
>> they'll see is less people on their roster and they'll install s
I don't believe you'd even get user requests from people who can't
contact someone. How many will seek out their server administrator to
check what's going on, and how many will just go and use Facebook or
Hangouts or something and forget about XMPP entirely?
It's great to have some specialised se
I completely agree,though I do not think there are planned mechanisms for this purpose. Though I put it harshly I'm only blocking servers I already can't communicate with.However I personally make sure to answer any user requests and so far anyone that had contacted me asking why certain servers co
11 matches
Mail list logo
