Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Fri, 26 May 2017 18:41:17 +0200 Daniel Gultsch wrote: > would sending in presence work? If we choose to use presences, then why even bother with putting caps in features? If we choose to use stream elements, we can send nonza. I think there should be some consistency.

Re: [Standards] OMEMO and Olm

Hi, 2017-05-26 19:28 GMT+02:00 Philipp Hörist : > We can make everyone happy, if we just ask around and find someone that is > willing to add XEdDSA to OLM. > > 1. Then we have it in a lib with a license that makes us happy > 2. We can write the XEP so that libsignal and OLM

Re: [Standards] OMEMO and Olm

On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon wrote: >> crypto is subtle, and it can be very easy to make mistakes that have >> catastrophic consequences. >> >> ... >> I haven't finished or tested it yet > > > This doesn't really give me much more confidence to be honest.

Re: [Standards] OMEMO and Olm

We can make everyone happy, if we just ask around and find someone that is willing to add XEdDSA to OLM. 1. Then we have it in a lib with a license that makes us happy 2. We can write the XEP so that libsignal and OLM can be used. 3. Even the Matrix people would probably use it for their protocol

Re: [Standards] OMEMO and Olm

> crypto is subtle, and it can be very easy to make mistakes that have > catastrophic consequences. > ... > I haven't finished or tested it yet > This doesn't really give me much more confidence to be honest. I understand that copy pasting code and to get a working version of the pseudocode is

Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Hi, 2017-05-26 18:38 GMT+02:00 Jonas Wielicki : > On Freitag, 26. Mai 2017 19:15:33 CEST Evgeny Khramtsov wrote: >> I >> assume the features should be cached by the peer, but how to update the >> cache if the server has changed configuration in runtime? > > That’s a good

Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

On Freitag, 26. Mai 2017 19:15:33 CEST Evgeny Khramtsov wrote: > I > assume the features should be cached by the peer, but how to update the > cache if the server has changed configuration in runtime? That’s a good point. I haven’t thought about that specifc issue, I was mostly concerned with

Re: [Standards] OMEMO and Olm

> Yes, it's true that there's currently no such thing [a permissively licensed > implementation] for XEdDSA … > implementing this yourself really isn't > that complex. You can re-use existing EdDSA code, all you need to do is > write the key conversion code yourself, for which there is

Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Fri, 26 May 2017 14:50:52 + (UTC) XMPP Extensions Editor wrote: > Version 0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. In section 5.2 there is the same problem as in the predecessor: I assume the features should be cached by the peer, but how to update the

[Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Version 0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. Abstract: This document overhauls the XMPP protocol extension Entity Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities.

[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Version 0.9.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been released. Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On Fri, May 26, 2017 at 9:43 AM, Kevin Smith wrote: > In the meantime, I’ve set up mail on the host and confirmed it can send to > XSF lists as edi...@xmpp.org. Thanks, that seems to be working; hardhats on for incoming mail flood please! —Sam

[Standards] DEPRECATED: XEP-0016 (Privacy Lists)

Version 1.7 of XEP-0016 (Privacy Lists) has been released. Abstract: This specification defines an XMPP protocol extension for enabling or disabling communication with other entities on a network. The protocol, which was first standardized in Section 10 of RFC 3921, can be used to block

[Standards] RETRACTED: XEP-0326 (Internet of Things - Concentrators)

Version 0.4 of XEP-0326 (Internet of Things - Concentrators) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification describes how to manage and get information from concentrators

[Standards] RETRACTED: XEP-0325 (Internet of Things - Control)

Version 0.5 of XEP-0325 (Internet of Things - Control) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification describes how to control devices or actuators in an XMPP-based sensor

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 26 May 2017, at 15:33, Kevin Smith wrote: > > On 26 May 2017, at 15:22, Sam Whited wrote: >>> email is an issue of Editor tooling, rather than iteam, and we can resolve >>> that there. >> >> Is it? I don't think it's a tooling issue; the script

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On Fri, May 26, 2017 at 9:10 AM, Kevin Smith wrote: > I’ve now given the editors the ability to deploy a new docker image with the > aforementioned script. Thank you; one down. > email is an issue of Editor tooling, rather than iteam, and we can resolve > that there.

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

> On 26 May 2017, at 14:56, Kevin Smith wrote: > > On 26 May 2017, at 14:41, Sam Whited wrote: >> Sam and Dave think it still involves manual steps. >>> >>> It does, as it has always done. >> >> Those manual steps have never involved being

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 26 May 2017, at 14:41, Sam Whited wrote: > >>> Sam and Dave think it still involves manual steps. >> >> It does, as it has always done. > > Those manual steps have never involved being dependent on another team > though, which is the actual problem. Well, the good news

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

>> Sam and Dave think it still involves manual steps. > > It does, as it has always done. Those manual steps have never involved being dependent on another team though, which is the actual problem. On Fri, May 26, 2017 at 3:31 AM, Kevin Smith wrote: > I did say that the

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

> On 26. May 2017, at 10:17, Kevin Smith wrote: > > I don’t see any reason to do this, we’re able to publish XEP updates just > fine. According to Sam, eos can’t send emails, like the XSF Editor emails that announce XEP changes or new

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 24 May 2017, at 14:48, Tobias Markmann wrote: > ## XSF Editor infrastructure state > > Tobias asks Sam (with his editor hat on) about the current state of XSF > Editor infrastructure and their ability to publish and otherwise process XEP > changes. Without this