Re: [Standards] Delayed Delivery for CSI and possibly SM

On 30 May 2017 at 14:00, Daniel Gultsch wrote: > Hi, > > I noticed that some CSI implementations (and maybe some SM > implementations as well) add a delayed delivery tag where the from is > set to their own domain. > > However that gets us into trouble in at least one scenario:

Re: [Standards] OMEMO and Olm

On 27 May 2017 at 16:46, Sam Whited wrote: > On Fri, May 26, 2017 at 7:27 PM, Remko Tronçon wrote: >> - We change the XEP to use XEdDsa, and someone gets an implementation into >> an (peer reviewed and preferably established) crypto library, *independent*

Re: [Standards] OMEMO and Olm

On 27 May 2017 at 16:00, Daniel Gultsch <dan...@gultsch.de> wrote: > 2017-05-27 16:49 GMT+02:00 Dave Cridland <d...@cridland.net>: >> On 27 May 2017 at 15:48, Daniel Gultsch <dan...@gultsch.de> wrote: >>> 2017-05-27 16:41 GMT+02:00 Dave Cridland <

Re: [Standards] OMEMO and Olm

On 27 May 2017 at 15:48, Daniel Gultsch <dan...@gultsch.de> wrote: > 2017-05-27 16:41 GMT+02:00 Dave Cridland <d...@cridland.net>: >> You think Zom will introduce OMEMO? I seriously doubt that's possible >> in the current state of affairs. > > I'm not in contac

Re: [Standards] OMEMO and Olm

On 25 May 2017 at 14:15, Daniel Gultsch <dan...@gultsch.de> wrote: > 2017-05-25 14:56 GMT+02:00 Dave Cridland <d...@cridland.net>: >> Proponents of XEdDSA (and libsignal) have repeatedly made the claim >> that building an XEdDSA implementation is both safe and >>

Re: [Standards] OMEMO and Olm

, and could be layered on top of a >> libsignal-managed 1:1 channel just as much as an olm-managed one). > > Thanks for the clarification on this one. > > > Am 25.05.2017 um 10:47 schrieb Dave Cridland: > >> But it looks rather strongly as if every extant implementation o

Re: [Standards] Privacy Rules and MAM interaction

On 20 May 2017 at 17:45, Evgeny Khramtsov wrote: > Sat, 20 May 2017 11:12:18 -0500 > Sam Whited wrote: > >> I was simply advising that making your MAM module interact with >> privacy lists may be something you want to consider avoiding. > > But I simply

Re: [Standards] XEP-0223: Clarification

On 25 May 2017 at 12:16, Daniel Gultsch wrote: > Small clarification on my own wording: > > 2017-05-16 19:07 GMT+02:00 Daniel Gultsch : >> - If a certain form field is registered with the registry [1] all >> server implementations MUST behave according to the

Re: [Standards] OMEMO and Olm

On 25 May 2017 at 10:01, Florian Schmaus <f...@geekplace.eu> wrote: > On 25.05.2017 10:56, Dave Cridland wrote: >> On 25 May 2017 at 08:26, Florian Schmaus <f...@geekplace.eu> wrote: >>> On 25.05.2017 08:04, Remko Tronçon wrote: >>>> On 24 May 20

Re: [Standards] OMEMO and Olm

On 24 May 2017 at 21:55, Andreas Straub wrote: > Hey all, > > it has been brought to my attention that my recent silence on this matter is > being perceived as "unresponsiveness", so I guess I should clear up a few > things. > Yes, your recent lack of response has indeed been seen

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017 at 20:30, Evgeny Khramtsov wrote: > Wed, 24 May 2017 21:24:40 +0200 > Daniel Gultsch wrote: > >> The author is unresponsive and has been ignoring my feedback for over >> a year. > > Like always, hehe :/ Sorry, I wasn't aware that this one

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017 at 18:35, Daniel Gultsch <dan...@gultsch.de> wrote: > Hi, > > 2017-05-24 18:53 GMT+02:00 Dave Cridland <d...@cridland.net>: >> Authors didn't need to approve the feedback > >> Because authors now get PRs written for them as routine, we

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017 at 17:23, Sam Whited <s...@samwhited.com> wrote: > On Wed, May 24, 2017 at 11:04 AM, Dave Cridland <d...@cridland.net> wrote: >> As for Council members not reading the list, I really don't understand >> this attitude. This is, by my count, the tenth thre

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017 at 17:36, Daniel Gultsch <dan...@gultsch.de> wrote: > Hi, > > 2017-05-24 18:04 GMT+02:00 Dave Cridland <d...@cridland.net>: >> I consider any XEP Author unresponsive who fails to respond to >> discussion on this list - the primary discussion venue of

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017 at 16:41, Dave Cridland <d...@cridland.net> wrote: > Dave asked whether the Council would do something here, and said he > considered the author unresponsive at this point. Sam noted the author > has not yet been "pinged". Tobias said if he had not been

[Standards] Council Minutes 2017-05-24

1) Roll Call Tobias, Daniel, Sam, Dave, and Emmanuel all present. 2) Minute Taker Dave volunteered. 3) SHA-1 migration plan Emmanuel said he had no news. Tobias suggested removing it from Trello for now. 4) XSF Editor update Kev has reported to Tobias that the Editor should now be able to

Re: [Standards] OMEMO and Olm

On 18 May 2017 at 13:20, VanitasVitae wrote: > Regarding file transfer: I'll probably tackle that as part of my Google > Summer of Code project, so we might get in contact later :) I look forward to reading the discussion on this list... Dave.

[Standards] OMEMO and Olm

Folks, My understanding of OMEMO was that we (the XSF) took on the work explicitly under the assumption that it was not to be based on the Signal protocol, which had IPR issues, but on Olm, which was explicitly designed, documented, *and* implemented to avoid such issues. You may recall (I

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

On 19 April 2017 at 15:52, Sam Whited <s...@samwhited.com> wrote: > On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland <d...@cridland.net> wrote: >> I'd be interested in Sam's counter-arguments, mind. > > - Discoverability: if or or whatever is only > used from c

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

On 31 March 2017 at 11:17, wrote: > Hi Remko, > > I have some comments. > >> 1. We go back to Olm's protocol of establishing an initial shared >> secret, using regular 3DH instead of X3DH. >> >> + Moves us back to an audited, implementable algorithm >> >> + No need to

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

On 30 March 2017 at 16:00, Florian Schmaus wrote: > On 30.03.2017 15:54, Remko Tronçon wrote: >> On 30 March 2017 at 15:10, Andreas Straub > > wrote: >> You raise a valid point. I agree that this construction seems >> cleaner from a

Re: [Standards] Deprecating Privacy Lists (again)

On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: > > On 22.03.2017 20:37, Sam Whited wrote: >> >> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger >> wrote: >>> >>> One nice feature we also don't have with blocking command is blocking a >>> while group.

Re: [Standards] Deprecating Privacy Lists (again)

On 22 March 2017 at 19:08, Sam Whited wrote: > I'd love your thoughts before I bring this before the council for a vote. I'm in favour of deprecation (but not elimination). * Privacy lists are mammothly complicated, and therefore error-prone. * While it's possible to

Re: [Standards] Join and Create

On 23 March 2017 at 08:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> Consider an chess-game service build on top of MIX. Tim and Tom want to >> play a game and agree on the "TimAndTomsGame" as name. Now both clients >> want to

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

On 21 March 2017 at 08:06, Florian Schmaus <f...@geekplace.eu> wrote: > On 20.03.2017 22:32, Dave Cridland wrote: >> Loosely, this is OK, but, in order: >> >> 1) Section 6 must go. … This issue is a blocker for me. > > I don't have much hope, but have to ask an

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

On 21 March 2017 at 07:40, Florian Schmaus <f...@geekplace.eu> wrote: > On 20.03.2017 23:31, Dave Cridland wrote: >> Ah, but Kev noted to me that this is using namespaced attributes. >> >> We have, traditionally, avoided these, on the basis that nobody (well, >>

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

On 21 March 2017 at 07:44, Evgeny Khramtsov wrote: > Tue, 21 Mar 2017 08:40:26 +0100 > Florian Schmaus wrote: > >> I'd like to continue using them for ISR-SASL2 because I don't think >> they cause any issues. > > I'm ok with that, but only if there is a

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

Ah, but Kev noted to me that this is using namespaced attributes. We have, traditionally, avoided these, on the basis that nobody (well, almost nobody) understands them. I don't think these are actually required here; a child element will work just as well. Can we do that instead? On 20 March

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

On 20 March 2017 at 22:04, Florian Schmaus <f...@geekplace.eu> wrote: > On 20.03.2017 22:32, Dave Cridland wrote: >> Loosely, this is OK, but, in order: >> >> 1) Section 6 must go. I don't believe that the XSF has the required >> expertise to adequately re

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

On 18 March 2017 at 10:16, Dave Cridland <d...@cridland.net> wrote: > On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote: >> On 18.03.2017 09:43, Dave Cridland wrote: >>> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@r

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote: > On 18.03.2017 09:43, Dave Cridland wrote: >> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@ruff.mobi >> <mailto:m...@ruff.mobi>> wrote: >> On 11.02.2017 21:43, Florian

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

On 17 Mar 2017 21:52, "Ruslan N. Marchenko" wrote: On 11.02.2017 21:43, Florian Schmaus wrote: > It should be explicitly stated that the CSI state is *not* (because it > can not) restored after a stream resumption. I've created a PR to > address this:

Re: [Standards] [Council] Council Meeting Minutes for 2017-03-08

On 16 March 2017 at 12:31, Dave Cridland <d...@cridland.net> wrote: > On 8 March 2017 at 17:50, Daniel Gultsch <dan...@gultsch.de> wrote: >> Council agrees that this needs more list discussion on list on whether >> this should be an inplace upgrade to XEP-0115. If it bec

Re: [Standards] [Council] Council Meeting Minutes for 2017-03-08

On 8 March 2017 at 17:50, Daniel Gultsch wrote: > 2. Entity Caps 2 > > Vote on accepting Entity Caps 2 > (https://xmpp.org/extensions/inbox/ecaps2.html) as experimental. > > Daniel +1 > +1 to this. > Other to vote on list > > Council agrees that this needs

Re: [Standards] XSF Council Minutes: 28 February 2017

On 28 February 2017 at 16:37, JC Brand <li...@opkode.com> wrote: > 2) Georg opened an PR on MUC private messages, > https://github.com/xsf/xeps/pull/436 > > Dave Cridland thinks it needs some security considerations, in particular > around replacing/removing client-added

Re: [Standards] New Format for MIX proxy JID

Looks reasonable to me. I'd appreciate a namespace bump. On 16 March 2017 at 11:03, Steve Kille wrote: > > Georg has suggested a new order for proxy JID. I've discussed with Kevin > Smith and we think the rationale for change of order makes sense. > > The original

Re: [Standards] MIX, MAM, jidmap, and Jid-Hidden

On 15 March 2017 at 17:46, Kevin Smith <kevin.sm...@isode.com> wrote: > I’ve not done the research I should have before responding to this, so > apologies if what I say is patently stupid. > >> On 15 Mar 2017, at 14:36, Dave Cridland <d...@cridland.net> wrote: >>&

Re: [Standards] I propose to remove "Prefer Hidden" from core MIX

.ki...@isode.com> wrote: > > The recent message from Dave Cridland caused me to look at the details of > making "Prefer Hidden" user preference to hide JIDs work (which it does not > in the current version). > > This needs a third type of Channel. In addition to "JID Hidden

Re: [Standards] MIX, MAM, jidmap, and Jid-Hidden

On 15 March 2017 at 14:02, Steve Kille wrote: > What you are suggesting here is that messages for "JID hidden" and "JID > visible" channels are treated differently, and that you distribute real JIDs > in JID visible channels.This was discussed and I was persuaded that

[Standards] MIX, MAM, jidmap, and Jid-Hidden

Folks, [This is long, sorry, and has a series of smaller points near the bottom, feel free to skip down] As you may be aware, jid-hidden is a particular driver for our use of MIX. So, too, is historical access to MIX messages, since we're building an asynchronous message board type thing.

Re: [Standards] XSF Council Minutes: 28 February 2017

Thanks for doing these! Really appreciated. On 28 February 2017 at 16:37, JC Brand <li...@opkode.com> wrote: > XSF Council Minutes: 28 February 2017 > = > > Present: daniel, Tobias, Link Mauve, SamWhited, Dave Cridland > Minute taker: jc

Re: [Standards] SHA-1

On 23 February 2017 at 20:57, Florian Schmaus <f...@geekplace.eu> wrote: > On 23.02.2017 18:19, Dave Cridland wrote: >> On 23 February 2017 at 16:53, Florian Schmaus <f...@geekplace.eu> wrote: >>> On 23.02.2017 15:36, Florian Schmaus wrote: >>>> On 23.02.

Re: [Standards] SHA-1

On 23 February 2017 at 14:19, Peter Waher wrote: > SHA-1 is used in many places throughout XMPP. Examples include > authentication mechanisms (SCRAM-SHA-1) and entity capabilities (XEP-0115), > for instance. Concerning the recent report about vulnerabilities found in >

Re: [Standards] LAST CALL: XEP-0334 (Message Processing Hints)

On 8 February 2017 at 23:07, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Seems useful. > 2. Does the specification solve the problem stated in the introduction and >

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

On 13 February 2017 at 15:53, Evgeny Khramtsov wrote: > Mon, 13 Feb 2017 13:49:30 + > Alexey Melnikov wrote: > >> Initial SASL response was not in the original SASL specification, so >> it was added later. So some clients (possibly using older

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

On 9 February 2017 at 10:08, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Thu, 9 Feb 2017 09:41:43 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> Because the server has to send an empty string, not the absence of a >> challenge. > > When does it make

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

On 9 February 2017 at 08:58, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Thu, 9 Feb 2017 08:40:49 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> 3) > > I still do not understand, what's the point in sending > =? Because the server has to s

Re: [Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

On 8 February 2017 at 22:11, Tobias M wrote: > * providing guidelines to what terms to use for certain things the protocol > introduces, e.g. XEP-0319 could recommend “Idle since” or “last active at” > as possible phrases to use when presenting the time to the user > *

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

On 9 February 2017 at 05:50, Evgeny Khramtsov wrote: > Thu, 9 Feb 2017 02:05:35 + (UTC) > XMPP Extensions Editor wrote: > >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Extensible SASL Profile >> >> Abstract: This

Re: [Standards] RFC 6120 vs. XEP

On 8 February 2017 at 08:53, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Wed, 8 Feb 2017 08:19:17 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> Right, I understand, and largely agree. I might scribble a draft to >> address this, by clarifying what we

Re: [Standards] On making "Compliance Suite 20xx" a Non-XEP

On 7 February 2017 at 16:25, Georg Lukas wrote: > Hi, > > today the current Compliance Sutie work was discussed in xsf@ and I > asked again why it needs a new number vs. just updating XEP-0375. This > resulted in some yak shaving, and an interesting, albeit controversial, >

Re: [Standards] RFC 6120 vs. XEP

Right, I understand, and largely agree. I might scribble a draft to address this, by clarifying what we really meant here. On 8 Feb 2017 06:30, "Evgeny Khramtsov" <xramt...@gmail.com> wrote: > Tue, 7 Feb 2017 21:22:17 +0000 > Dave Cridland <d...@cridland.net> wro

Re: [Standards] RFC 6120 vs. XEP

On 7 February 2017 at 16:29, Evgeny Khramtsov wrote: > Tue, 7 Feb 2017 19:18:39 +0300 > Evgeny Khramtsov wrote: > >> Tue, 7 Feb 2017 09:57:07 -0600 >> Sam Whited wrote: >> >> > The rules for required stream features say that if

[Standards] Google Summer of Code 2017

Folks, At the XMPP Summit, there was general enthusiasm toward the XSF applying for Google Summer of Code 2017. Kev has agreed - once again - to be the org admin. Please do reply to this if you're able to produce an initial set of project ideas by MONDAY 1300Z. At this point Kev will make a

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 25 January 2017 at 11:23, Evgeny Khramtsov wrote: > Wed, 25 Jan 2017 10:59:19 + > Kevin Smith wrote: > >> Mostly because I don’t want to make 198 resumption mandatory for >> servers, where it’s somewhere between fairly difficult and >>

Re: [Standards] Advance XEP-0368 to Proposed

On 24 January 2017 at 20:13, Travis Burtrum wrote: > On 01/24/2017 10:20 AM, Sam Whited wrote: >> I agree with Zash, they're equivalant; 6120 says >> that even if STARTTLS isn't advertised you should attempt it, and this >> is the same thing. Falling back to plain is a bad

Re: [Standards] Advance XEP-0368 to Proposed

On 24 January 2017 at 13:38, Travis Burtrum wrote: > On 01/24/2017 08:08 AM, Kim Alvefur wrote: >> On Thu, Jan 19, 2017 at 03:19:12PM -0500, Travis Burtrum wrote: >>> I am proposing advancing XEP-0368 from Experimental to Proposed, and the >>> XSF MUC said to do this by

Re: [Standards] MIX use of type=groupchat?

On 23 January 2017 at 10:33, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Mon, 23 Jan 2017 09:37:44 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> If by a generic relay you mean "reflects traffic as-is too all >> subscribers", isn't that what MI

Re: [Standards] MIX use of type=groupchat?

On 23 January 2017 at 08:51, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Mon, 23 Jan 2017 08:06:39 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> XEP-0207? > > The XEP is only funny because Pubsub sucks. In fact, we need something > like generic

Re: [Standards] Advance XEP-0368 to Proposed

On 19 January 2017 at 20:19, Travis Burtrum wrote: > Hi all, > > I am proposing advancing XEP-0368 from Experimental to Proposed, and the > XSF MUC said to do this by sending an email to the standards list. > > https://xmpp.org/extensions/xep-0368.html > > It's been a bit over

Re: [Standards] Easy XMPP

On 17 January 2017 at 15:31, Sam Whited wrote: > On Mon, Jan 16, 2017 at 10:05 PM, Peter Saint-Andre > wrote: >>> And if your business plan doesn't involve federation, why bother with >>> the additional overhead and complexity? > > I don't have a good

Re: [Standards] Easy XMPP

On 17 January 2017 at 14:34, Holger Weiß wrote: > * Vitaly Takmazov [2017-01-17 17:10]: >> 2017-01-17 15:11 GMT+03:00 Holger Weiß : >> > I don't want to install >> > I don't want to be >> > I want to >> >> XMPP will

Re: [Standards] Easy XMPP

On 17 January 2017 at 04:05, Peter Saint-Andre wrote: > The world I work in has mostly migrated away from on-premises software, to > cloud services that are public or semi-private. I recognize that some > organizations simply can't go there - they have regulatory reasons or >

Re: [Standards] Easy XMPP

On 16 January 2017 at 18:08, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Mon, 16 Jan 2017 17:59:21 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> That's not what I said, I said that federation was an important >> feature. > > You have said exa

Re: [Standards] Easy XMPP

On 16 January 2017 at 17:57, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Mon, 16 Jan 2017 17:40:11 +0000 > Dave Cridland <d...@cridland.net> wrote: > >> Businesses simply buying an IM service, however, want to be able to >> talk to their supply-chain, custom

Re: [Standards] Easy XMPP

On 16 January 2017 at 17:32, Evgeny Khramtsov wrote: > Mon, 16 Jan 2017 09:28:41 -0700 > Peter Saint-Andre wrote: > >> I fully understand that XMPP can be useful for organizations who want >> to develop or deploy their own messaging systems, either

Re: [Standards] Easy XMPP

On 16 January 2017 at 16:28, Peter Saint-Andre wrote: > On 1/16/17 7:00 AM, Evgeny Khramtsov wrote: >> >> Mon, 16 Jan 2017 14:29:42 +0100 >> Georg Lukas wrote: >> >>> The goal of Easy* was to write down the things that can easily be >>> done today. However,

Re: [Standards] Expected behavior when blocking all unknown JIDs

On 15 Jan 2017 07:39, "Evgeny Khramtsov" wrote: Fri, 13 Jan 2017 20:36:39 +0100 Kim Alvefur wrote: > If we think of blocking strangers by default as a privacy protection > measure Not everyone wants such rude default privacy. I agree. I'd hate XMPP to be

[Standards] XMPP Council Meeting 20170111

http://logs.xmpp.org/council/2017-01-11/ 1) Roll Call - http://logs.xmpp.org/council/2017-01-11/#16:01:03 All present. [[ Dave forgot to do the joke about saying "Bacon please!". ]] 2) Minute Taker - http://logs.xmpp.org/council/2017-01-11/#16:03:03 Dave offered, and Tobias foolishly agreed.

Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

On 11 January 2017 at 08:01, Piotr Nosek <piotr.no...@erlang-solutions.com> wrote: > On Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland <d...@cridland.net> wrote: >> >> On 10 January 2017 at 14:37, Kevin Smith <kevin.sm...@isode.com> wrote: >> > >>

Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

On 10 January 2017 at 14:37, Kevin Smith <kevin.sm...@isode.com> wrote: > > > On 10/01/2017 14:27, Dave Cridland wrote: >> >> On 10 January 2017 at 13:30, Kevin Smith <kevin.sm...@isode.com> wrote: >>> >>> On 10/01/2017 12:05, Steve Kille wrote

Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

On 10 January 2017 at 13:30, Kevin Smith wrote: > On 10/01/2017 12:05, Steve Kille wrote: >> >> I have just issued a PR for MIX version 0.6.4. >> >> There is clear desire to have the option for MUC and MIX to use the same >> domain.The difficulty in achieving this was

Re: [Standards] XEP-0163: Personal Eventing Protocol - Clarification about the multi-items per node support

Loosely, I agree with Sergey, except I think he means: Rather than: On 4 January 2017 at 22:52, Jaussoin Timothée wrote: > Hi, > > After having a look at XEP-0163: Personal Eventing Protocol and XEP-0060: > Publish-Subscribe I'd like to have a clarification regarding the

Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

On 6 January 2017 at 08:36, Jaussoin Timothée wrote: > Hi, > > I'm currently in the process of implementing end-to-end encryption in my > project. I naturally had a look at the freshly published XEP-0384: OMEMO > Encryption and I have some feedbacks to give on it. > > 1. Usage

Re: [Standards] MIX and MUC sharing a domain

ing around forever. This is, as you say, something we can discuss further in Brussels - I just don't want it to be considered a lost cause from the outset. > > > We can discuss further in Brussels > > > > > > Steve > > > > > > > > From: Standa

Re: [Standards] MIX Discussion topics for the Summit

On 4 Jan 2017 09:34, "Steve Kille" wrote: I thought it would be helpful to set out a list of topics for discussion/review at the Summit at the end of this month. I will update this message if more topics are suggested or otherwise come to light before the meeting. I

Re: [Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX

On 2 January 2017 at 14:59, Sam Whited wrote: > On Mon, Jan 2, 2017 at 4:12 AM, Evgeny Khramtsov wrote: >> The problem is that spam/ham classification problem for SPIM is a bit >> different from those for email because IM messages are short. > > That's

Re: [Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX

On 29 Dec 2016 22:32, "Tobias Markmann" wrote: Hi all, So @hanno ( https://twitter.com/hanno/ ) did a presentation followed by a short discussion on Signal and how XMPP and other federated systems fail to provide a similar secure and usable system over federated

[Standards] Council Minutes 2016-12-21T16:00Z

Wise Men: Tobias Markmann, Sam Whited, Daniel Gultsch, Dave Cridland Absent: Emmanuel Gil Peyrot 1) Roll Call Dave asked for Ham and Cheese, and only later realised that he should have asked for Turkey or something. Honestly, I should think these gags through better. 2) Minute Taker

[Standards] XMPP-UK Security MeetUp: London, 8th Dec 2016

n the XMPP Council, he has implemented three different forms of end-to-end encryption in Conversations, and will be discussing their strengths and weaknesses. Dave Cridland - S2S Security Dave has put bugs into many of the leading XMPP Servers, and is currently project lead for IgniteRealtime's Open

Re: [Standards] XEP-0050 xml inconsistency

On 23 November 2016 at 16:01, Florian Schmaus wrote: > On 23.11.2016 16:41, Christian Schudt wrote: >> This has been discovered before, but nobody cared: >> >> https://mail.jabber.org/pipermail/standards/2014-October/029242.html > > Yep, would be great to sort this out. I have

Re: [Standards] Proposed XMPP Extension: Spoiler messages

On 2 Nov 2016 02:25, "XMPP Extensions Editor" wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Spoiler messages > > Abstract: > This specification defines an XMPP protocol extension that provides a > method for indicating a

Re: [Standards] "Self-destruct" message timeout deletion hints

On 1 November 2016 at 18:13, Chris Ballinger wrote: > People already have a casual understanding that you can't completely enforce > message deletion. Actually, I'm really not sure that's as true as you assert. People currently think that it requires an assertive effort on

Re: [Standards] XEP-0225: Component Connections (deferred status)

On 1 November 2016 at 14:23, jorge - w wrote: > If I understood it right XEP-0225 is meant to upgrade XEP-0114. Are there > technical issues still to be solved, so status is deferred? > It turns out that it doesn't solve any technical issues not currently addressed by '114,

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

Once a XEP is a XEP, it's owned by the XSF, and not the author. Prior to that, it is not owned by the XSF, and the XSF has no opinion on the matter except that on submission as a XEP, any authors agree to transfer ownership, perfecting as required, to the XSF. On 31 Oct 2016 19:02, "Daniel

Re: [Standards] "Self-destruct" message timeout deletion hints

On 18 October 2016 at 22:58, Chris Ballinger wrote: > Many other messaging apps are implementing features for self-destructing > messages. I dismissed the idea for a long time because of the impossibility > of actually enforcing deletion on the other side, but now I believe

Re: [Standards] "Self-destruct" message timeout deletion hints

On 19 October 2016 at 13:56, Brian Cully wrote: > >> On 18-Oct-2016, at 17:58, Chris Ballinger wrote: >> >> Are there other scenarios that I'm missing? Would people be willing to >> implement this into their apps? Is formalized spec for this something

Re: [Standards] Proposed XMPP Extension: Message Deletion

'correction', and replace 308? > It was discussed - we could do this as a message correction to a zero-length message - but firstly I think the semantics are somewhat different, and secondly I think this might be usable in some non-IM cases. I'm open to argument, mind. > On 18 October

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 17 October 2016 at 20:45, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Deletion > > Abstract: This specification defines a method for indicating that a message > should be retracted. > > URL:

Re: [Standards] XEP-0050: Ad-Hoc Commands

On 18 October 2016 at 08:11, jorge - w wrote: > I'm just trying to receive feeback from the community, since i have recently > joined it. > Sure - and it's appreciated. > In order to avoid client dependency, any programming should be done at > server side. I already know

Re: [Standards] XEP-0050: Ad-Hoc Commands

command line. My experience suggests the exact opposite, if anything. I follow how ":app_short_name" might work. What I don't understand is how one discovers that "app_short_name" exists, what it does, and what parameters can be used, and how those parameters are passed. Dave.

Re: [Standards] XEP-0050: Ad-Hoc Commands

On 17 October 2016 at 12:03, jorge - w wrote: > I'd like to discuss about the scope of XEP-0050. According to Motivation the > objetive is to expand Jabber beyond instant messaging. > However I see few XMPP clients feature command execution. I wonder if > another approach

Re: [Standards] Fwd: Internet of Things SIG

On 11 October 2016 at 20:37, Rikard Strid wrote: > f. I’ve reach out to people at the IETF MILE Working Group to invite them to > join and to learn more about their work. Join what? The MILE working group aren't doing IoT at all - I'd hate them to think that the XSF is

Re: [Standards] Fwd: Internet of Things SIG

Folks, I think it's probably more useful to discuss the IoT SIG proposal here. Firstly, it'd be useful to gather a sense of the current state of play. It seems to me we have a number of IoT-related XEPs and proposals - due to a huge amount of effort by Peter Waher - but its not clear to me which

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 30 September 2016 at 17:12, Kevin Smith <kevin.sm...@isode.com> wrote: > On 30 Sep 2016, at 10:01, Dave Cridland <d...@cridland.net> wrote: >> >> On 30 September 2016 at 09:49, Kevin Smith <kevin.sm...@isode.com> wrote: >>> >>>> On 29 Sep 2

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 30 September 2016 at 09:49, Kevin Smith <kevin.sm...@isode.com> wrote: > >> On 29 Sep 2016, at 22:58, Dave Cridland <d...@cridland.net> wrote: >> >> >> On 29 Sep 2016 22:00, "Kevin Smith" <kevin.sm...@isode.com> wrote: >> > >&g

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 29 Sep 2016 22:00, "Kevin Smith" <kevin.sm...@isode.com> wrote: > > On 29 Sep 2016, at 21:17, Dave Cridland <d...@cridland.net> wrote: > > (And please, folks, unless you can think of something I can't, a > > randomish string prefix and a counter is

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 28 September 2016 at 17:38, Kevin Smith wrote: > Sadly not, 6121 says > " It is up to the originating entity whether the value of the 'id' >attribute is unique only within its current stream or unique >globally.” Equally, absolutely nothing stops a client

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

On 29 September 2016 at 09:41, Kevin Smith wrote: > On 27 Sep 2016, at 17:18, Sam Whited wrote: >> >> On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille wrote: >>> A simple approach to address this more complex scenario is a two-step

Re: [Standards] XEP-0369 (MIX) - Approach to options for per-user preferences

On 21 September 2016 at 14:32, Steve Kille wrote: > I have not been able to think of any additional sensible per-user > preferences. Users might well want to control whether they receive private messages through the MIX or not. In general, unless there's a compelling

<    2   3   4   5   6   7   8   9   10   11   >