Re: [Standards] XEP-0198 stream resumption with too high 'h' parameter

* Michal Piotrowski [2017-02-14 12:18]: > I'm currently investigating following situation. The server sent to the > client 10 stanzas and clients sends accept which is not valid > (too high). > In XEP-0198 I didn't find any information what should happen if clients > sends too high 'h' parameter.

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* Ruslan N. Marchenko [2017-02-12 16:33]: > No, the no-copy use is ambiguous. Are private and no-copy equivalent? Are > they complementing each other? what is the server behaviour when only one of > them is provided? > I personally am in favour of order for owner and no-copy hint for > remote par

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* XMPP Extensions Editor [2017-02-09 00:07]: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? yes > 2. Does the specification solve the problem stated in the introduction and > requirements? yes, to approximately 90%. The last bul

Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

* XMPP Extensions Editor [2017-02-09 00:34]: > Version 0.1.0 of XEP-0387 (XMPP Compliance Suites 2017) has been released. good work on this, Sam! I've created a PR at https://github.com/xsf/xeps/pull/411 : | This PR contains three diffs to XEP-0387, in increasing order of | controversy: | | -

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

* Tobias M [2017-02-08 23:12]: > I suggest adding a mandatory “Usability Considerations” to XEPs, even > if some XEPs will just say “This protocol provides no recommendations > to usability.” or something like that. +1 I think it would be useful to have the XEP template contain the “Usability Co

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

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, proposal: Can we make the "Compliance Suite" a stand-alone document that is not an

Re: [Standards] CSI and Carbons state after SM resumption

* Sam Whited [2017-02-06 10:15]: > > Ah right, another unfortunate design decision. > > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. I principally agree with your point, and I'm not explicitly blamin

Re: [Standards] CSI and Carbons state after SM resumption

* Florian Schmaus [2017-02-05 20:54]: > CSI uses Nonzas, which are not covered by Stream Management, so you > can't restore the CSI state after resumption. Ah right, another unfortunate design decision. signature.asc Description: Digital signature ___

Re: [Standards] CSI and Carbons state after SM resumption

* Florian Schmaus [2017-02-05 19:41]: > I've just submitted https://github.com/xsf/xeps/pull/402 I really really don't understand why 0198 should change any of the session properties on resumption. This should be as transparent to the client as any possible. 0198 simply happens when the user is

Re: [Standards] 2017 Compliance Suites

* Sam Whited [2017-01-29 01:16]: > I'm not sure; I originally submitted an update changing all the dates > to 2017, but was asked to submit a new one. I don't recall what the > reasoning was, but as the old one will be retracted and superseded > properly I don't think it will be confusing. It app

[Standards] XEP-0280 Carbon Rules for MUC-PMs

Hi, I know everybody hates MUC PMs, but still. People are using them, and they are broken in the wild as soon as you have more than one client. We need to fix XEP-0280 and our server implementations, and probably also XEP-0045 and our MUC implementations, to tackle this. Problems TL;DR --

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

* Georg Lukas [2017-01-26 12:56]: > It also needs to be added into 0280 to reflect current practice. PR: https://github.com/xsf/xeps/pull/382 Because the XSF can't decide whether 'no-copy' is better or worse than 'private', I've added both to the client side. I

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

* XMPP Extensions Editor [2017-01-18 03:17]: > XEP-0334 (Message Processing Hints) has been Deferred because of inactivity. Can we get this advanced, please? It is used by 0313, 0364, 0384 and 0384. It also needs to be added into 0280 to reflect current practice. Georg -- || http://op-co.de +

Re: [Standards] 2017 Compliance Suites

* Sam Whited [2017-01-18 17:44]: > We discussed moving forward the 2016 compliance suites today [..] I'm curious why we don't just rename XEP-0375 from 2016 to 2017? That would reduce the number of deprecated XEPs and implementer confusion. > - Remove MIX as an optional spec to satisfy the multi

Re: [Standards] Advance XEP-0368 to Proposed

* Peter Saint-Andre [2017-01-24 22:29]: > To NOT assign. especially when they are already assigned to other applications. signature.asc Description: Digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

[Standards] Secure Attribution of Mediated MUC Invitations

Hello, TL;DR: for implementing Easy Group Chats[0], it would be great to have a secure way to automatically follow invitations from trusted users. While MIX does it right, the situation with MUC isn't as nice and clear. To slightly improve, I would like to mandate MUC mediated invitations to conta

[Standards] MIX Invitations and PARS (XEP-0379)

Hi, while pondering about Easy Group Chats[0], I realized that there is some similarity between the MIX invitation token (§5.1.17 [1]) and PARS (XEP-0379 [2]), but also some differences that I would like to streamline and better understand. Both expose an authentication token, which is forwarded

Re: [Standards] Proposed XMPP Extension: Bind 2.0

* XMPP Extensions Editor [2017-01-17 16:24]: > Abstract: This specification provides a single-request replacement for > several activities an XMPP client needs to do at startup. I know this is a bold request, but as a client developer, I wish for the following from bind2: 1. Client performs aut

Re: [Standards] Easy XMPP

Evgeny Khramtsov : > Well, my company (ProcessOne) has been doing this since 2002 or so. We > are trying to convince customers that XMPP is a worthy technology, but > it is becoming harder and harder to do. Actually, I see xmpp as a possible solution here for multiple reasons. There is a hype

Re: [Standards] Easy XMPP

Peter Saint-Andre : > So, at this point, I wonder what we're doing here. :-) Signal is a single company providing a centralized product. I think what's missing the most for our user community is the federation and the choice of clients. While I agree with you that they have achieved significan

Re: [Standards] Easy XMPP

Sam Whited : > I recently ran an experiment with a non-Technical friend where I gave > them some prompts, and then answered direct questions without hand > holding them through anything and more or less recorded a transcript > of what was said and what they clicked on. This is exactly what client

Re: [Standards] Easy XMPP

Kevin Smith : > It’s worth noting that I think you mean the ‘Public/unaffiliated > Internet XMPP IM use case”. Lots of XMPP use is either pre-provisioned > or off-Internet, or both. Indeed. If you have some catchy name for it, I'll gladly apply that label to make my intentions more clear. >> ht

Re: [Standards] MIX Discussion topics for the Summit

Hello, please find inlined my talking points and questions for the summit, which I'm not able to attend in person: * Steve Kille [2017-01-04 10:36]: > Q1.Should MIX Channels and MUC Rooms be allowed to share a domain? GL: This is actually the wrong question to ask. I don't think anybody wan

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

Responding to myself from members@ to standards@, as the latter is probably more adequate (PS: could we continue on standards@ only?). * Georg Lukas [2016-12-30 22:58]: > Some months ago, I've started brainstorming ideas for "Easy XMPP" - > improving the UX side, espec

Re: [Standards] MIX clarity, MAM, and client-proxy interactions

* Steve Kille [2016-12-22 12:32]: > > All this is very complicated and demands clear language and a proper spec of > > all the steps involved in an action. > I think that the approach to address this is to identify specific > points that are not clear and improve the text. You are right of course

[Standards] MIX clarity, MAM, and client-proxy interactions

Hi Steve, let's agree to disagree on the design decisions. I think this really needs to be tackled in Brussels, where we have a larger number of experienced protocol designers. It would just be important to discuss the trade-offs imposed by the alternatives, and to write down the design decisions

Re: [Standards] MIX Status (0.6.1), review, and Brussels Summit

Hi Steve, thanks for the reivew of the review, I'd like to add some more reasoning to some of my arguments below. * Steve Kille [2016-12-21 11:50]: > You are right that a high bar has been set. [...] > > Operationally, I believe that this will be mitigated by server > implementations that supp

[Standards] Securely converting a 1:1 chat into a MUC

Hi, a modern XMPP messenger needs to provide a seamless way to create a "privte" group, either by inviting a bunch of folks or by upgrading a 1:1 chat into a conference. XEP-0045 §7.9 explicitly defines this use case as follows: | Now the first person decides to include a third person in the | d

Re: [Standards] MIX Status (0.6.1), review, and Brussels Summit

* Steve Kille [2016-12-05 16:25]: > Careful expert review and work on initial implementations is going to raise > issues that will lead to updates. Thanks very much for your work so far. I've finally worked through the XEP and will try to organize my points a bit. # General issues ## Required S

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

* Daniel Gultsch [2016-10-27 21:17]: > is there a reason you are including the SID in the URL? > > If not I would just propose doing > > xmpp:fe...@allfools.lit?omemo=070c42a11644a78b2f6f56213be4686374222895eb67b781abc44b860c47656c,e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871

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

* Dumaine, Xander [2016-09-20 19:20]: > While I can understand the use case, I also believe it’s low value compared > to potentially negative consequences. I'm interested in the possible side effects. Could you please outline the potential consequences you see? Georg signature.asc Description

[Standards] MUC Invites are no MUC PMs (Was: Multi-client operation and read-until-X markers)

Nothing is better than a corner case hidden inside of a corner case. * Georg Lukas [2015-05-05 16:35]: > 4. Carbons of MUC private messages. If user@host/A has joined to a MUC > and receives a private message from muc@domain/participant, that message > is carbon-copied to the other reso

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

* Tobias M [2016-09-16 13:41]: > What would speak for allowing edits across resources: +1 for allowing this use case. I think it would improve the consistency of the XMPP UX, and increase user confidence. > Another case is where a server sends different carbons messages to different > resources

Re: [Standards] PAM Source Selection

* Kevin Smith [2016-09-07 11:28]: > I think there’s two blocks of data. One is capabilities, which we > already have a mechanism for sorting out, so I think it’d make sense > to re-use here (and this is already public). +1 to that. > The second is the effective blocklist. It’s clear this shouldn

Re: [Standards] PAM Source Selection

* Kevin Smith [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 probably > not the end of the world to have one, but I think I would be inclined > to start investigating things in terms of the tra

[Standards] Multi-Client and PAM (XEP-0376: Pubsub Account Management)

Hi, PAM was pointed out to be a major building block for MIX, but it is lacking in regard to multi-client and filtering support. While not strictly required for the basic operation of MIX and PAM, a question that needs to be solved mid-term is: WHICH of the user's clients need to know WHAT informa

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

Hey Steve, thanks for keeping up with all our requests :) * Steve Kille [2016-09-02 18:06]: > > A consequence of this is that messages HAVE to go to the bare JID. > > > > I suggest that this very rationale and the related fundamental design > > decision > > of MIX should be put into the XEP. >

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

Hello again, * Dave Cridland [2016-08-23 23:09]: [MUC JID reference in a MIX] > I think it's needed to allow a MIX client to communicate a MUC jid to > another client. Yes, unless the MUC JID is the primary (or the only) identifier of the chat room, we need two-way references for interop, with t

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

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... * Steve Kille [2016-08-17 17:33]: > MIX permits three modes with MUC: > > 1. No MUC. There is no requirement to support MUC. This may make sense

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

Hi, * XMPP Extensions Editor [2016-08-16 12:33]: > Version 0.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been > released. Thanks to everybody involved! Let's get this one moving fast, now! :) I like the overall design, but I think some aspects of it can be improved. 1. Sharing a d

Re: [Standards] [XEP-0375] Unclear Wording (Was: MIX should not be in 2016 compliance list)

* Sam Whited [2016-08-13 19:56]: > At least for this particular example there is a footnote for this: "§ > Only one of the recommended providers must be implemented for > compliance. " Oops, I totally missed that one :> > > I'd like to see an improved vocabulary in the XEP - what are "items", >

[Standards] [XEP-0375] Unclear Wording (Was: MIX should not be in 2016 compliance list)

Hello, * Goffi [2016-08-10 17:08]: > After having a look at XEP-0375 (XMPP Compliance Suites 2016) I realized that > MIX is named in recommandations. While it's most probably the future of group > chat and it's going in the right way IMO, it should definitely not be in 2016 > compliance list,

Re: [Standards] How many delay elements?

* Holger Weiß [2016-07-13 21:05]: > | Information about the delivery delay is communicated by adding to the > | or stanza one and only one child > | [...]. This information is added by the server or component that > | delivers the stanza. > 1. a given stanza should never contain more than a s

Re: [Standards] MIX progress

* Kevin Smith [2016-07-05 12:07]: > Discussing the decisions made at the summit, or making further > suggestions, presumably. What is the appropriate place to read up the decisions? And where to discuss them? The summit wiki links to https://pad.riseup.net/p/XMPPSummit20 which links to a January

[Standards] XEP-0045 join when already in MUC

Hi, TL;DR: whenever a client (re)sends a join, the MUC service should return everything a newly joining client needs to know. According to XEP-0045, an initial join presence needs to contain an 'x' element with 'http://jabber.org/protocol/muc' namespace (§7.2.2), whereas a regular presence update

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

* Peter Saint-Andre [2016-06-22 17:44]: >A is not eligible for carbons delivery if it is >determined to have been sent by a MUC room or service, even if it >would be otherwise eligible (this also includes private messages >from MUC participants). IMHO, this rule is more relevant

Re: [Standards] Easy XMPP

Thanks very much for the feedback, everyone! I'll try to address the points in a single mail. 1. "Silo creation": the goal is to make the Easy* proposals backwards compatible, so that interop with legacy clients is well-defined. The specifications are all open, so everybody can implement them in t

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

Hello, I've collected some feedback off-list, removed the 'returntoken' element and have a git repo tracking the changes now: https://op-co.de/tmp/xep-pars.html https://op-co.de/tmp/xep-pars.xml https://github.com/ge0rg/proto-xeps/commits/master One feedback I received was a strong objection to

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

Hello, thanks very much for the feedback on my Easy XMPP suggestions. It looks like there are really many possibilities to optimize the initial onboarding, so for now I'd like to focus on the easier roster invitations. I think they can be implemented in a straight-forward way and provide an immedi

[Standards] Easy XMPP

Hi folks, in the last weeks we've seen that XMPP is too hard for the WhatsApp generation. Instead of blaming them for not understanding federation, we should make it as easy as possible to use XMPP (IM) in a secure fashion. In the last days, I've collected some ideas on how to accomplish that int

[Standards] XEP-0147: "?subscribe" or "?roster"

Hi, I want to expose an xmpp: URI of the user's account in my client to allow easy "contact sharing" to other IM users. Fortunately, XMPP is ultra flexible, allowing for any reasonable or potential usage form due to its separation between "roster" and "presence subscription". Now, as an IM applic

[Standards] "Chronological" order in XEP-0313 (Message Archive Management)

Hi, we just had a discussion in the prosody MUC, regarding message ordering in MAM, and I realized there is some ambiguity in the XEP when handling incoming elements. The XEP explicitly states that messages must be sorted chronologically: "The collection is ordered chronologically by the time e

Re: [Standards] Proposed XMPP Extension: OpenPGP for XMPP

* XMPP Extensions Editor [2016-04-12 16:18]: > Title: OpenPGP for XMPP I see multiple security problems in this XEP (which I addressed on this list[0] and in private conversations with the authors, where I unfortunately failed to convince them): 1. The XML element embedded in the OpenPGP message

Re: [Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)

* Kevin Smith [2016-01-26 13:27]: > Thanks Georg. > > On 26 Jan 2016, at 12:07, Georg Lukas wrote: [Share JID between MUC and MIX] > I think this would be excessively hard for relatively little benefit (I could > be wrong). From the discussion in xsf@: - disco#items on a MUC w

Re: [Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)

Hi, * XMPP Extensions Editor [2016-01-06 11:14]: > The XMPP Extensions Editor has received a proposal for a new XEP. It's really awesome to see MIX going forward. As I haven't participated in the last summit and won't be able to come to Brussels, I'd like to write down my questions and feedback

Re: [Standards] OX (OpenPGP for XMPP): A new OpenPGP XEP

* Sergei Golovan [2016-01-08 10:49]: > I don't think any API can tell you in advance that the encrypted message is > signed inside. Though, probably exposing this information isn't a good idea, > and you're right about the generic element as a container. I think that exposing this information is

Re: [Standards] Deprecating IBR

* Dave Cridland [2015-11-11 08:58]: > > What do you suggest to replace it with? > [...] we need, I think, a mechanism which takes a potential new user > through new account creation, and helps in configuring their client, > and ideally works across multiple servers. And it needs to be as easy as

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

* Travis Burtrum [2015-11-05 20:56]: > That was a deliberate decision on my part, and does not affect > security in the way you mentioned because I explicitly state: > > TLS certificates MUST be validated the same way as for STARTTLS. > (ie, as specified in XMPP Core). So lets assume I want to co

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

After reading up on ALPN, another security note: From Section 3: | For clients, this provides a virtually no overhead way to bypass | restrictive firewalls that only allow HTTP over port 80 and HTTPS over | port 443, as xmpp-over-tls is indistinguishable from http-over-tls. Except that the client

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

* Travis Burtrum [2015-11-05 18:45]: > This proposal defines a procedure to look up _tls SRV records in > addition to _tcp and mix weights/priorities. One point that stood out to me is this: 6. Client or server SHOULD set SNI TLS extension to the host in the SRV record. Is that a deliberate dec

Re: [Standards] Move Carbons to Last Call ("Proposed")

* Kevin Smith [2015-08-17 15:47]: > After discussion in the XSF MUC, I’ve pushed another change, so > probably best to track via the > https://github.com/Kev/xeps/commits/carbons branch. I'll see your patch and raise you $200. https://github.com/ge0rg/xeps/tree/carbons After some more discussio

[Standards] MUC Nick-Sharing and XEP-0280

The 0045+0280 interaction has made me think about the other implications of nick sharing, so I've written down everything that came to my mind: http://wiki.xmpp.org/web/MUC_Nick_Sharing Please feel free to extend, modify, and improve the little pieces of information. I still think that 0280 shou

Re: [Standards] Move Carbons to Last Call ("Proposed")

* Dave Cridland [2015-08-12 11:55]: > > * Carbons for non-"chat" messages. > That use-case won't work anyway because Jingle calls are initiated with an > . Ah, the discussion thread for that somewhat complicated use case can be found here: http://mail.jabber.org/pipermail/standards/2014-August/02

Re: [Standards] Move Carbons to Last Call ("Proposed")

* Steve Kille [2015-08-12 08:14]: > Given that a MAM based approach may be the preferred medium term > approach, it seems to me that we should focus efforts to work out what > the medium term approach is going to be. +1 > Also, if there is a list of issues that some people view need fixing > wi

Re: [Standards] Move CSI to Last Call ("Proposed")

* Sam Whited [2015-07-28 17:04]: > On Tue, Jul 28, 2015 at 1:57 AM, Matthew Wild wrote: > > Out of curiosity, what clients do you know of that are using it? > Conversations, Kontalk, Converse.js, Bluejabb, probably others. yaxim has a quick&dirty google:queue implementation that at least prosod

Re: [Standards] Move CSI to Last Call ("Proposed")

* Christian Schudt [2015-07-28 10:22]: > I think this has already been discussed once, but wouldn't it be more > intuitive to use IQ semantics for this instead of sending a message > which confirms the (de)activation? +1 for an IQ. Basically just what google:queue does, with a properly declared n

Re: [Standards] File Transfer Roadmap

* Sam Whited [2015-07-27 00:35]: > With that in mind, I'd like to know what the council (and everyone > elses) opinion is of moving Jingle File Transfer forward in the process? I am strictly against pushing forward a mechanism that does not specify strong, mandatory, end-to-end encryption. We hav

Re: [Standards] Proposed XMPP Extension: Mobile Considerations

* Dave Cridland [2015-07-21 12:52]: > However, I expected this to be a (sorely-needed) major edit to XEP-0286, > which I wrote some years ago and has lagged behind the times. For the > record, I'm perfectly happy to completely hand over authorship of that > specification to Sam. I would also favo

Re: [Standards] Dealing with offline messages in times of MAM

* Daniel Gultsch [2015-06-10 07:01]: > However if the MAM capable client is the only client in the game it > will (with normal setups) regularly receive both the offline messages > and the messages downloaded from the MAM archive. This is one of the specific aspects that I have in mind when propo

Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs

* Daniel Gultsch [2015-06-05 13:01]: > And I'm currently not really seeing the point of a client adding an id > since the client can already set the stanza id. Besides of the MUC-eating-your-message-ID use case there is another one that was heavily discussed as a possible motivation for client-id

Re: [Standards] XEP-0198 minor enhancement

* Steffen Larsen [2015-05-30 08:37]: > No, I would go for a version bump, because it could break some clients. A version bump, on the other hand, would break all clients. Some clients haven't yet implemented the sm:2 to sm:3 bump, and implementing different versions of the protocol in parallel is

Re: [Standards] Multi-client operation and read-until-X markers

I'm following up to myself with another issue that just happened to me: > MUCs > As stated above, nick-sharing is the only sane way to do MUCs with > multi-clients, and we have multiple problems to solve here: > [1-3] 4. Carbons of MUC private messages. If user@host/A has joined to a MUC and rece

Re: [Standards] Nonzas: What are they and do we need them?

* Matthew Wild [2015-04-20 18:33]: > > In the XEP-0352 case, "Nonzas" could get lost without resending them > > upon stream resumption, leaving the client under the impression that > > it's active, although the server thinks it's inactive. > This can't happen, because new streams are always active

Re: [Standards] Nonzas: What are they and do we need them?

* Florian Schmaus [2015-04-20 15:27]: > Contra: > - Messages and IQs could be used instead > - Can't be used with BOSH As you pointed out below, they can be used in theory. I just assume that most implementations will not expect them and might break in subtle ways. IIRC, it required significant r

[Standards] Carbons as a MAM Subscription (Was: Encrypted Storage)

* Georg Lukas [2015-04-18 11:42]: > I really dislike (ab)using carbons as a MAM pseudo-subscription. Another case in point: Carbons are not reflected to the sender, so if you send a message, you have no way (yet) to know its archive ID. Basically, we need to ensure two things here:

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

* Kim Alvefur [2015-04-18 12:49]: > I don't see why you couldn't have a bot that signs in to your account, > enables Carbons and then stores all messages in a local archive, which > could then be exposed via MAM to your other clients. How would that bot (or the off-server archive service) handle

[Standards] Encrypted Storage (Was: off-server archives with MAM)

* Peter Saint-Andre - &yet [2015-04-18 04:59]: > [MAM privacy concerns] I wholeheartedly agree with you here, but I would like to see another solution to this - use of asymmetric crypto storage on the server, a la Lavabit: 1. When a user logs in for the first time, an asymmetric keypair is creat

Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages

* Joe Hildebrand (jhildebr) [2015-04-13 17:39]: > Headline also has the nice property that servers doing offline SHOULD > NOT hold on to headlines; that seems to fit the intent here. Probably > needs some testing in the real world. I see value in offline storing of ACKs, as it provides (visual)

[Standards] Multi-client operation and read-until-X markers

Hi, to bring todays discussion in jdev@ to a more formal ground, I'd like to write down the list of problems I see with the operation of multiple clients (e.g. desktop and mobile) on the same bare JID, regarding notifications, MUCs, and the read-state of messages. This is slightly related to the o

Re: [Standards] OTR

* Bartosz Małkowski [2015-01-26 07:58]: > https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ This is a great writeup. Having multi-device end-to-end encryption with offline storage will significantly improve the security and usability of XMPP for normal people

Re: [Standards] XEP-0313 adding archive id to live incoming messages

* Kevin Smith [2015-01-22 14:14]: > > How would you deduplicate a mix of messages received normally and MAM > > messages? Are you supposed to delete all normal messages when syncing up > > with MAM? > Yep. Hmm. My gut feeling is that I don't particularly like that approach. Maybe we can really de

Re: [Standards] XEP-0313 adding archive id to live incoming messages

* Kevin Smith [2015-01-22 12:59]: > > I don't care too much about actually receiving the message twice (I > > would still query the entire archive since the last time I have been > > online) I just want to be able deduplicate messages in my own local > > history. > That bit’s straightforward - you

Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

* Dave Cridland [2014-07-26 17:09]: > Firstly, many of your other comments rely on the uniqueness and stability > of ids. An example is your (7) - this relies on all messages sent from the > same occupant jid having unique ids. You'll probably realise some problems > with this approach fairly quic

Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

Hello, * Kevin Smith [2014-07-25 18:53]: > I agree with the intention, but I think making a breaking change to > xep45 at this point wouldn't be appropriate. Existing protocols need to be changed occasionally, and I am pretty sure no point in time is appropriate for that. However, the change I

[Standards] RFC: XEP-0045 MUC should not rewrite message IDs

Hi, XEP-0045, section 7.4 states: "Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18])." I suggest changing that line to: "The service SHOULD reflect

Re: [Standards] Security consideration for XEP-0198

* Kevin Smith [2014-05-08 12:34]: > Consider the case of a paused client in a MUC. The MUC sends a > message, and gets a bounce because the buffer's full. The client > resumes the session, but now its out of sync - it thinks its in the > MUC and the MUC has removed it due to bounces. I can see th

Re: [Standards] Security consideration for XEP-0198

* Dave Cridland [2014-05-07 23:05]: > It's probably worth noting, yes. The solution is to request an > acknowledgement, and if one isn't forthcoming, to ditch the connection, of > course. It is not that easy, unfortunately. If the client is currently disconnected, the ultimate purpose of the stan

Re: [Standards] Carbons - inbound messages to bare jid

Hello, [this is a slightly modified version of a message that got lost in moderation] * Thijs Alkemade [2014-04-25 16:02]: > Thinking about this a bit more, I actually disagree with this proposal. I second the suggestion to remove or strongly reword section 6. It should keep a reference to XMPP

<    1   2   3