Re: [Standards] XEP-0300 and a future without reading tea leaves

> On 17 Jan 2017, at 15:33, Goffi <go...@goffi.org> wrote: > > Le mardi 17 janvier 2017, 14:08:54 CET Tobias Markmann a écrit : >> On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith <kevin.sm...@isode.com> wrote: >>> It sounds like a sensible enough a

Re: [Standards] bind2

ng-solutions.com > > On 13 January 2017 at 12:24, Florian Schmaus <f...@geekplace.eu> wrote: > On 13.01.2017 10:27, Kevin Smith wrote: > > On 11 Jan 2017, at 20:09, Evgeny Khramtsov <xramt...@gmail.com> wrote: > >> > >> Wed, 11 Jan 2017 19:56:43 +

Re: [Standards] XEP-0300 and a future without reading tea leaves

On 17 Jan 2017, at 13:08, Tobias Markmann <tmarkm...@googlemail.com> wrote: > > > On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith <kevin.sm...@isode.com> wrote: > It sounds like a sensible enough approach to me, unless we think Gajim is the > only deployment us

Re: [Standards] Easy XMPP

On 7 Jun 2016, at 16:04, Georg Lukas wrote: > I think we can improve significantly for the XMPP IM use case (I have > not much expertise in other use cases), if we simplify the things that > can be simplified, make them consistent between clients, and give the > whole thing a

Re: [Standards] Easy XMPP

Thread necromancy. > On 8 Jun 2016, at 18:59, A. Bikadorov wrote: > you may wanna have a look at the Kontalk project which already has a client > implementing > some simplifications you are proposing: > - server list + automatic server selection (and option to override) > -

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

On 23 Aug 2016, at 22:09, Dave Cridland wrote: > > > On 23 Aug 2016 21:56, "Georg Lukas" wrote: > > > > Hi Steve, > > > > thanks for the clarifications. I'm still not quite sure about the > > implications of some of the things though, maybe you can clarify...

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

> On 6 Sep 2016, at 09:00, Daurnimator wrote: > > On 6 September 2016 at 00:59, XMPP Extensions Editor wrote: >> Version 0.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been >> released. >> >> Abstract: This document defines Mediated

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:20, Georg Lukas <ge...@op-co.de> wrote: > > * Kevin Smith <kevin.sm...@isode.com> [2016-09-07 11:19]: >> It’s not clear to me that another stanza is necessary, and that this >> can’t come out of normal caps handling by the server. It’s probab

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:32, Dave Cridland <d...@cridland.net> wrote: > > > On 7 Sep 2016 11:28, "Kevin Smith" <kevin.sm...@isode.com> wrote: > > > > On 7 Sep 2016, at 10:22, Dave Cridland <d...@cridland.net> wrote: > > > > > If t

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:07, Dave Cridland <d...@cridland.net> wrote: > > In the xsf@ chatroom, Georg Lukas, Ralph Meijer, Kevin Smith, and I had a > quick discussion on how clients might interact with PAM in order to select > and filter based on information type and source.

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

t; is set >>> >>> In MUC it didn't have to be; infact, often joining a room was no different >> to >>> updating your presence. >> [Steve Kille] >> >> Kevin Smith responded on this point. > > The muc element is optional, see > https://xmpp.

Re: [Standards] Proposed DTD fixes

On 30 Aug 2016, at 18:47, Steve Kille wrote: > Edwin, > >> Our DTD seems to reject the vast majority of our XEPs. In part, this is >> because there are true mistakes in XEPs – e.g., where the author >> actually >> should've used – which aren't converted to the expected

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:22, Dave Cridland wrote: > > > If this seems right, I'll write this up formally into the XEP and go from > > > there. > > > > It’s not clear to me that another stanza is necessary, and that this can’t > > come out of normal caps handling by the server.

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

> On 16 Sep 2016, at 12:39, Tobias M wrote: > > Hi, > > Under 4. Business Rules XEP-0308 mentions: > >> A correction MUST only be allowed when both the original message and >> correction are received from the same full-JID. > > However, it has little discussion on

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

On 27 Sep 2016, at 10:06, Tobias M <tmarkm...@googlemail.com> wrote: > > >> On 27 Sep 2016, at 00:33, Kevin Smith <kevin.sm...@isode.com> wrote: >> >>> However, it has little discussion on why there is this restriction. While >>> it certainly

Re: [Standards] XEP-0359 Client vs. non-client IDs

On 29 Sep 2016, at 18:22, Guus der Kinderen wrote: > What's the purpose of the distinction between "Unique Stanza IDs" and "Client > generated stanza IDs"? Why not add a unbounded list of stanza-id elements > (each with a unique 'by' attribute value), and not worry

Re: [Standards] XEP-0359 Client vs. non-client IDs

On 29 Sep 2016, at 19:08, Florian Schmaus wrote: > > On 29.09.2016 19:22, Guus der Kinderen wrote: >> Hi, >> >> What's the purpose of the distinction between "Unique Stanza IDs" and >> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id >> elements (each

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

> 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: > > > > On 29 Sep 2016, at 21:17, Dave Cridland <d...@cridland.net> wrote: > > >

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

On 28 Sep 2016, at 21:18, Tobias M <tmarkm...@googlemail.com> wrote: > >> >> On 28 Sep 2016, at 18:38, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 27 Sep 2016, at 10:06, Tobias M <tmarkm...@googlemail.com> wrote: >>> >

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

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 >> approach where the inviter starts by sending a message to the channel to >>

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

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 2016, at 22:58, Dave Cridland <d...@cridland.net> wrote: >>> >>> >&

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

On 30 Sep 2016, at 17:25, Dave Cridland <d...@cridland.net> wrote: > > 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

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

On 2 Oct 2016, at 18:47, Florian Schmaus <f...@geekplace.eu> wrote: > > On 30.09.2016 18:12, Kevin Smith 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...

Re: [Standards] XEP-0359 Client vs. non-client IDs

> On 2 Oct 2016, at 18:46, Florian Schmaus <f...@geekplace.eu> wrote: > > On 29.09.2016 20:18, Kevin Smith wrote: >> On 29 Sep 2016, at 19:08, Florian Schmaus <f...@geekplace.eu> wrote: >>> >>> On 29.09.2016 19:22, Guus der Kinderen

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

On 21 Sep 2016, at 16:21, Steve Kille wrote: > The sort of thing I am looking to avoid is where the server provides the > user with a form to fill in. By standardising common fields, we can avoid form requests in the common case without forcing clients to do the request

Re: [Standards] Deprecating Message Archiving

On 19 Sep 2016, at 18:09, Florian Schmaus wrote: > I think it's to early to deprecate Message Archiving while MAM is just > experimental. That said, I suggest adding a disclaimer to Message Archiving > stating that new installations should consider MAM instead. I think that

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

On 29 Sep 2016, at 21:17, Dave Cridland wrote: > (And please, folks, unless you can think of something I can't, a > randomish string prefix and a counter is fine). The dangers of using counters in stanza IDs and leaking information :) /K

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote: > On 18 October 2016 at 11:12, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 18 Oct 2016, at 10:09, Guus der Kinderen <guus.der.kinde...@gmail.com> >> wrote: >> > I

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:31, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote: > On 18 October 2016 at 11:18, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com> >> wrote: >&g

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:09, Guus der Kinderen wrote: > I don't have much of an argument other than the obvious: both affect data > 'after-the-fact'. Concerns raised against one should likely also be tested > against the other - it's pretty much the same thing. As for

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

On 18 Oct 2016, at 07:54, jorge - w wrote: > My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. > > But what is fine for admins is not always the same for regular users. That's > why i think there should be a different interface for regular users mostly

Re: [Standards] Verifiability of stanza-ids

> On 29 Oct 2016, at 11:51, Daniel Gultsch wrote: > > Hi, > > When an entity injects stanza-ids (for example to communicate) the MAM > archive id those IDs need to be verified by the receiving entity. > Meaning when I receive a stanza-id and later use that id to query my >

[Standards] Thanks for the meetup

Not really sure whether here or members@ is the better place, but I wanted to drop a quick note saying thanks! to Dave, Laura and Paul (and anyone else involved) for setting up the XMPP Meetup in London last night, and the (other) speakers. Was a good night (good pizza :)). /K

Re: [Standards] Unread syncing

On 14 Dec 2016, at 11:46, Michal Piotrowski wrote: > > > On 2 December 2016 at 18:18, forenjunkie > wrote: > Ah now im understanding, basically the server should give you a list of > contacts to

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

On 10/01/2017 15:16, Sam Whited wrote: On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith <kevin.sm...@isode.com> wrote: I think you'd need to build so much extra stuff on top of burner JIDs … that you end up with vastly more complexity than proxy JIDs give you. I'm not so sure; you get a

Re: [Standards] XEP-0369 Proxy JIDs and MIX

On 10/01/2017 15:23, Sam Whited wrote: 2. While burner JIDs may be helpful to provide a user with complete anonymity in a channel, I think that channel administration needs access to the real JIDs. It would not be acceptable to manage a public MUC and just have a stack of anonymous

Re: [Standards] Obsoleting vCard-Based Avatars

On 08/01/2017 14:59, Sam Whited wrote: Hi all, XEP-0053: vCard-Based Avatars [1] is a historical specification that has been superseded by XEP-0084: User Avatars [2] for quite some time. However, since it's historical it still shows up in the list on xmpp.org and this seems like a possible

Re: [Standards] Obsoleting vCard-Based Avatars

On 11 Jan 2017, at 20:09, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Wed, 11 Jan 2017 19:56:43 +0000 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> I’m obviously just about the last person to say we shouldn’t be >> trying to modernise XMPP, g

Re: [Standards] XEP-0300 and a future without reading tea leaves

On 12 Jan 2017, at 09:48, Tobias Markmann wrote: > This can be seen as a continuation of my classic thread on this very channel > from 2014 titled "File Hashes in XEP-0234". It was so popular, that even I > did lost interest in it. :D > > Back to the future, today.

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

On 06/01/2017 16:15, Sam Whited wrote: On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs? Using this removes the

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

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: 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

Re: [Standards] Obsoleting vCard-Based Avatars

> On 11 Jan 2017, at 16:44, Sam Whited <s...@samwhited.com> wrote: > > On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith <kevin.sm...@isode.com> wrote: >> FWIW, give the remaining widespread deployment of vcard avatars compared to >> pubsub-based, and of re

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

On 11 Jan 2017, at 21:13, Daniel Gultsch wrote: > And yes there are a few users out there for which blocking strangers is an > effective way of fighting spam. However so is blocking messages with Cyrillic > letters in them. This doesn't mean we should make a standard for

[Standards] Unread syncing

A question: I’ve always assumed that we would do sync of the unread (or, rather read) status of messages between contacts via private PEP and, indeed, this is the approach we verbally specced at a summit a while back (which I have yet to write up). I’ve been thinking about this further, in

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 11:44, Kevin Smith <kevin.sm...@isode.com> wrote: > > A question: > > I’ve always assumed that we would do sync of the unread (or, rather read) > status of messages between contacts via private PEP and, indeed, this is the > approach we verbally

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 13:42, Christian Schudt wrote: > >> I think you possibly don’t :) >> >> This is for synchronising the ‘read’ status between all of my clients, such >> that a) they’re consistent and b) when a new client comes online it can >> quickly determine

Re: [Standards] [Council] 2016-11-23 Council Meeting Minutes

On 29 Nov 2016, at 12:25, Daniel Gultsch wrote: >> >> ## 6a) https://github.com/xsf/xeps/pull/204 > > +1 > There has been some debate over where registry entries are actually > defined and whether this additional form value should be defined in > the XEP or directly in the

Re: [Standards] References and XHTML-IM interoperability

> On 2 Dec 2016, at 22:50, Tobias Markmann <tmarkm...@googlemail.com> wrote: > > >> On Fri, Dec 2, 2016 at 9:51 PM, Kevin Smith <kevin.sm...@isode.com> wrote: >> We are, but that shouldn't stop me confusing things! >> >> Tobi mentioned that we sh

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 15:37, Tobias M <tmarkm...@googlemail.com> wrote: >> On 2 Dec 2016, at 16:07, Kevin Smith <kevin.sm...@isode.com >> <mailto:kevin.sm...@isode.com>> wrote: >> >> I don’t see why the ids need to be UUIDs (indeed, it seems activel

Re: [Standards] Unread syncing

never did write a implementation of MAM myself, but if im reading the XEP, > you can filter with various attributes, you dont have to step through EVERY > message. > >> Am 02.12.2016 um 16:57 schrieb Kevin Smith: >>> On 2 Dec 2016, at 15:49, forenjunkie <forenjun...

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 14:35, Christian Schudt wrote: > > >> Except that they’re not chat messages, so won’t be stored, and if they were >> you’d be potentially up to doubling the size of your archive (I guess adding >> a quarter to, on average) as you fill it with read

Re: [Standards] Unread syncing

On 2 Dec 2016, at 15:26, forenjunkie wrote: > in a single chat conversation, it makes no sense to query unread messages. I’m not sure that’s true at all, but putting that to the side for the minute... > you could just query the last 10 MAM Messages, if no readmarker comes

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 15:44, Tobias M <tmarkm...@googlemail.com> wrote: > > >> On 2 Dec 2016, at 16:39, Kevin Smith <kevin.sm...@isode.com >> <mailto:kevin.sm...@isode.com>> wrote: >> >> They’re long and (as far as I can see at the moment) unnece

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 14:56, Sam Whited wrote: > > On Fri, Dec 2, 2016 at 6:00 AM, Tobias Markmann > wrote: >> One approach would be requiring IDs on the tags you want to reference. This >> way the reference tag could simple refer to that ID, which

Re: [Standards] Unread syncing

dreds or thousands of messages older than my messages from contact B, all of which are read. If I merely read the archive backwards until I found a read marker, I wouldn’t find the unread messages for contact A. /K > > > Am 02.12.2016 um 16:34 schrieb Kevin Smith: >> On 2 D

Re: [Standards] References and XHTML-IM interoperability

> On 2 Dec 2016, at 18:38, Peter Saint-Andre <stpe...@stpeter.im> wrote: > >> On 12/2/16 11:32 AM, Kevin Smith wrote: >> >> >>>> On 2 Dec 2016, at 18:22, Peter Saint-Andre <stpe...@stpeter.im> wrote: >>>> >>>> On 12

Re: [Standards] Unread syncing

ages. /K > > -- Christian > > Gesendet: Freitag, 02. Dezember 2016 um 12:44 Uhr > Von: "Kevin Smith" <kevin.sm...@isode.com> > An: "XMPP Standards" <standards@xmpp.org> > Betreff: [Standards] Unread syncing > A question

Re: [Standards] A possible MIX approach: hiding multiple clients

> On 6 Jan 2017, at 07:50, Steve Kille wrote: > > > The recent discussion on the difficulty of proxy JIDs has triggered me to > write up a more radical idea I have had floating around. > > For the most part, a MIX channel deals with users (not clients). Messages > are

Re: [Standards] A possible MIX approach: hiding multiple clients

On 6 Jan 2017, at 10:01, Kevin Smith <kevin.sm...@isode.com> wrote: > >> >> On 6 Jan 2017, at 07:50, Steve Kille <steve.ki...@isode.com> wrote: >> >> >> The recent discussion on the difficulty of proxy JIDs has triggered me to >> writ

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

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 incompatible disco results. This version has made a change to add node='mix' to

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

On 30 Mar 2017, at 14:10, Andreas Straub wrote: >> So, I'm wondering whether it wouldn't make more sense to not carry the >> Signal legacy around in OMEMO, use Ed25519 keys as identity keys, and >> adapt X3DH to use these for creating an initial shared secret (with the >> same

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

> On 30 Mar 2017, at 17:30, Florian Schmaus <f...@geekplace.eu> wrote: > > On 30.03.2017 18:24, Kevin Smith wrote: >> OMEMO’s initial publication was delayed for some time, in large part because >> of the need to move away from a situation where it can only be

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

On 30 Mar 2017, at 17:13, Florian Schmaus wrote: > > On 30.03.2017 18:02, Dave Cridland wrote: >> 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

[Standards] Server loss

Hi folks, As many of you will have noticed, we had a ‘minor issue’ with the server at the weekend. To cut a moderately long story short, there was a failure at the hosting provider, destroying the server that hosts the xmpp.org XMPP service, website, wiki, xmpp.net service, etc. etc. Because

Re: [Standards] [Members] Server loss

On 29 Mar 2017, at 12:07, Daniel Pocock <dan...@pocock.pro> wrote: > > > > On 29/03/17 12:49, Kevin Smith wrote: >> Hi folks, >> >> As many of you will have noticed, we had a ‘minor issue’ with the server at >> the weekend. To cut a modera

Re: [Standards] XEP-0313: Storage Rules for Archives

On 30 Jan 2017, at 22:52, Tobias Kräntzer wrote: > > Hi, > > I searched the archive to see, if this has already been discussed recently, > but didn’t finde anything. Please bear with me, if this has been already > discussed too much. > > I’m recently implemented

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

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 wrote: >> On 15 March 2017 at 14:02, Steve Kille wrote: >> What you are suggesting here is that

Re: [Standards] XEP-0369: xmlns in disco#info feature elements

On 2 Mar 2017, at 21:02, Jonas Wielicki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Donnerstag, 23. Februar 2017 08:05:23 CET XMPP Extensions Editor wrote: >> Version 0.8.1 of XEP-0369 (Mediated Information eXchange (MIX)) has been >> released. >>

Re: [Standards] XEP-0357: Adding last-message-priority

Just a holding message that I’ve seen this thread is in my inbox and I need to read/reply - I’ve just not got down to it yet. /K > On 28 Jul 2017, at 02:23, Chris Ballinger wrote: > > This adds an optional "high" and "low" priority value, where "high" depends > on

Re: [Standards] XEP-0234: Denote used hash function in session-initiate

On 17 Aug 2017, at 21:23, Paul Schaub wrote: > > Hi! > > I stumbled across another inconvenience in the Jingle File Transfer XEP: > > The session-initiate MIGHT contain a hash-element which contains the > checksum of the file. Alternatively the hash-element can also be

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On 10 May 2017, at 21:08, Sam Whited wrote: > > On Wed, May 10, 2017 at 2:29 PM, Daniel Gultsch wrote: >> IMHO the hypothetical service operators who maintain their own service which >> are self-branded are very welcome to step forward now and try to get

Re: [Standards] Don't let today be the day we bury OMEMO

> On 7 Jun 2017, at 22:15, Ignat Gavrilov wrote: > > Before anyone (including me) gets outrageous here, I wonder what this > compromise is exactly: > > a) The OMEMO-siacs is put into the/a XEP and all future standardizing work is > put into OMEMO-NEXT (not

Re: [Standards] length of time in ProtoXEP state

On 21 Jun 2017, at 16:47, Daniel Gultsch wrote: > > The problem here is that XEPs usually don't move up the ranks as it is > intended by XEP-0001. We have countless - very essential - stuck in > very low ranks like experimental and draft. This leads to developers >

Re: [Standards] OMEMO Discussion Summary 2017

On 21 Jun 2017, at 15:47, Peter Saint-Andre wrote: > > Thanks for the summary, Tobias! > > On 6/21/17 8:35 AM, Tobias Markmann wrote: > > >> With that, the media and client developers can point to the version of >> XEP-0384 that is currently widely implemented and the XSF

Re: [Standards] length of time in ProtoXEP state

On 22 Jun 2017, at 22:23, Dave Cridland wrote: > > On 22 June 2017 at 21:49, Sam Whited wrote: >> On Thu, Jun 22, 2017 at 3:30 AM, Dave Cridland wrote: >>> If it really is the name, then let's call it "Stable". >> >> I actually do

Re: [Standards] OMEMO Discussion Summary 2017

On 21 Jun 2017, at 18:03, Daniel Gultsch wrote: > > 2017-06-21 18:58 GMT+02:00 Daniel Gultsch : >> I think the meaning of that compromise is overstated. >> The main reason for doing this is that we have a stable version which >> can be addressed and linked

[Standards] Push. Was Re: Council Minutes 2017-05-24

> On 24 May 2017, at 20:24, Daniel Gultsch wrote: > > 2017-05-24 21:16 GMT+02:00 Evgeny Khramtsov : >> Since we're discussing this: what about XEP-0357 (Push Notifications)? >> Is it gonna be deferred? What's its state? > > The author is unresponsive and

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

> On 26 May 2017, at 14:56, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 26 May 2017, at 14:41, Sam Whited <s...@samwhited.com> wrote: >> >>>> Sam and Dave think it still involves manual steps. >>> >>> It does, as it has always

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

On 26 May 2017, at 15:33, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 26 May 2017, at 15:22, Sam Whited <s...@samwhited.com> wrote: >>> email is an issue of Editor tooling, rather than iteam, and we can resolve >>> that there. >> >> Is it

Re: [Standards] OMEMO and Olm

On 25 May 2017, at 10:01, Florian Schmaus wrote: > > On 25.05.2017 10:56, Dave Cridland wrote: >> On 25 May 2017 at 08:26, Florian Schmaus wrote: >>> On 25.05.2017 08:04, Remko Tronçon wrote: On 24 May 2017 at 22:55, Andreas Straub

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

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

On 30 May 2017, at 15:18, Daniel Gultsch wrote: > > 2017-05-30 16:02 GMT+02:00 Dave Cridland : >> Presence, mind, I'm not so sold on - I think it's significantly less >> important, since presence is stateful rather than an event. But I'm >> not averse to it

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

On 30 May 2017, at 15:37, Daniel Gultsch <dan...@gultsch.de> wrote: > > 2017-05-30 16:28 GMT+02:00 Kevin Smith <kevin.sm...@isode.com>: >> On 30 May 2017, at 15:18, Daniel Gultsch <dan...@gultsch.de> wrote: >>> >>> 2017-05-30 16:02 GMT+02:00 Dave C

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

On 30 May 2017, at 15:02, Dave Cridland <d...@cridland.net> wrote: > > On 30 May 2017 at 14:48, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 30 May 2017, at 14:00, Daniel Gultsch <dan...@gultsch.de> wrote: >>> I noticed that some CSI implementations

Re: [Standards] OMEMO Key Agreement

> On 2 Jun 2017, at 11:57, Daniel Gultsch <dan...@gultsch.de> wrote: > > 2017-06-01 13:12 GMT+02:00 Kevin Smith <kevin.sm...@isode.com>: >> On 1 Jun 2017, at 11:22, Daniel Gultsch <dan...@gultsch.de> wrote: >>> I went ahead an created a PR for XEP-0384

Re: [Standards] Don't let today be the day we bury OMEMO

Hi Flo, This feels somewhat like trying to torpedo the current compromise that’s on the table, so I’d like to make some comments. On 7 Jun 2017, at 14:48, Florian Schmaus wrote: > The council will likely soon [1] decide if the currently used OMEMO > protocol will be

Re: [Standards] Don't let today be the day we bury OMEMO

Hi Ignat, > On 7 Jun 2017, at 19:22, Ignat Gavrilov wrote: > Just that I understand this topic correctly: > The intention is to put the currently implemented OMEMO (a.k.a. siacs OMEMO) > into the XEP and then no longer update that XEP and put all effort into >

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:00, Ignat Gavrilov wrote: > IMHO a new encryption scheme change should be a new XEP or this will confuse > users even more I can understand that argument, but I think a lot of people want to have the currently deployed thing-that-isn’t-OMEMO

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:49, Vanitas Vitae wrote: > I agree. Its not exactly nice to deny the existing implementations the > name OMEMO, since those implementations are what gave OMEMO its > reputation, so could we please agree on the fact, that existing > implementations are

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:46, Ignat Gavrilov <ignat.gavri...@mailfence.com> wrote: >> From: Kevin Smith <kevin.sm...@isode.com> >> I can understand that argument, but I think a lot of people want to have the >> currently deployed thing-that-isn’t-OMEMO (OMEMO-siac

Re: [Standards] OMEMO Key Agreement

On 1 Jun 2017, at 06:03, Daniel Gultsch wrote: > > Hi, > > a lot of what Dave said about future proofing spoke to me and I'm > starting to think he (and the others) are right. > > It makes me wonder if we should work towards making OMEMO a good > standard for a more distant

[Standards] XEP-0280 (Carbons) proposals

Hi all, I promised to review and start a thread on the pending PR for Carbons updates ( https://github.com/xsf/xeps/pull/434 ), so here we are. Removing no-copy: https://github.com/xsf/xeps/commit/aac8f94b0df64b250f7d5320d9f2e5e76b38d2ff I think this goes beyond just removing no-copy, and makes

Re: [Standards] OMEMO Key Agreement

Hi Daniel, On 1 Jun 2017, at 11:22, Daniel Gultsch wrote: > I went ahead an created a PR for XEP-0384 to match what is actually > implemented in the wild. > ... > I changed the track from Standards to Historical. > I checked: Track changes have happened before and are

Re: [Standards] XEP-0280 (Carbons) proposals

On 2 Jun 2017, at 08:59, Dave Cridland wrote: > > On 1 June 2017 at 12:51, Georg Lukas wrote: >>> Requiring servers to implement particular delivery rules: >>> https://github.com/xsf/xeps/commit/9c388a51c61541507c599832038b6562f3d01841 >>> >>> I don’t think

Re: [Standards] XEP Authors

On 9 Jun 2017, at 14:08, Peter Saint-Andre wrote: > > On 6/9/17 5:37 AM, Philipp Hancke wrote: >>> However, I don't think this is particularly contentious. We have lots >>> of documents for which one of the "Authors" hasn't made any input for >>> several revisions. >> >>

Re: [Standards] XEP Authors

On 9 Jun 2017, at 11:41, Dave Cridland wrote: > However, I don't think this is particularly contentious. > I see, on the other hand, no advantage to *not* having a Previous > Authors section This seems like a sensible change to me, whether driven by Dave’s non-lawyerness or

Re: [Standards] (MIX) - When to increment Namespace

On 14 Jun 2017, at 08:12, Steve Kille wrote: > > Jonas, > >> >>> I have not pushed as a PR because of namespace numbering. It seems >>> likely that if a change is pushed every time we make a protocol tweak, >>> there is going to be a serious problem of namespace

Re: [Standards] XEP-0369 (MIX): Early stages of a clients connection

On 14 Jun 2017, at 08:36, Steve Kille wrote: >> One thing I could imagine is for the server to include that information in >> the >> roster version. E.g. if it usually versions the roster with incrementing >> numbers, it could add "+mix" to the stringified number if MIX

Re: [Standards] XEP-0369 (MIX): When to deliver messages to a client

On 14 Jun 2017, at 09:02, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 14 Jun 2017, at 08:53, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 14 Jun 2017, at 08:23, Steve Kille <steve.ki...@isode.com> wrote: >>> >>> Jonas, >

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