Re: [Standards] Disappearing timers for OMEMO proposal

> In federated environment you can't control what client is used > by remote party, and if it really does delete messages after timer expires. True, but it would still be a useful in a situation where you trust the other parties (e.g. non-federated setup where you know which clients are being

Re: [Standards] Proposed XMPP Extension: Message Markup

Hi, On 7 November 2017 at 21:34, Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > Minor remark: the XEP says that spans MUST NOT overlap. Is there a reason for this? I'm asking, because the systems I have seen that use external

[Standards] OMEMO Key Agreement

Hi, A few months ago, there were discussions around the OMEMO key agreement protocol, which we said we'd revisit once the XEP was changed to document the historical SIACS protocol, and we then could move on to making OMEMO future-proof. With all that out of the way, i'm picking this up again now.

Re: [Standards] XEP-0384 OMEMO questions

> The original authors of the XEP worked on a follow up version [1] which > put the wire format into the XEP This follow-up version is in its current state even more underspecified than the libsignal one (for example, it's impossible to know how to authenticate the sent payload IIRC). > and

Re: [Standards] XEP-0384 OMEMO questions

Hi Klaus, thanks for the clarification. Is there already something done for > OMEMO-next? Where can I contribute? > I have a long list of proposals I want to submit to the XEP (many of them here https://github.com/xsf/xeps/pull/463, but some might need revisiting in light of some discussions).

Re: [Standards] Permanent slots for HTTP Upload

> It seems that people, like Daniel, are reaching the limits of those > features and want to extend the XEP. > It sounded like Daniel's problems could be fixed with a simple addition to the XEP, and didn't warrant all the complexity of the PEP-based protocol you describe. This all sounds way

Re: [Standards] HTTP-Upload: Content-based slots

> Clearly, benefits, but I do wonder what can of worms this opens with > regards to confidentiality. "Wait, someone else uploaded this?" > I agree you need to be careful to leak information here, and e.g. only do this if it was the same user that uploaded it. Maybe there are other reasons for

[Standards] HTTP-Upload: Content-based slots

Hi, A server may want to provide optimized write-once storage of files that stores data based on hashes of file contents (such that identical files are only stored once, and that filenames are opaque). In this light, I was wondering whether the following extensions to XEP-0363 would make sense:

Re: [Standards] Reputation system for XMPP

> Also, it might be easier to control this sort of thing in a silo like > Signal than in a federated network like XMPP. It's definitely easier for them, since they don't have to federate with badly setup servers that leave doors wide open, and their own users need to verify a phone number before

Re: [Standards] Reputation system for XMPP

> On 5 Sep 2017, at 09:27, Kevin Smith wrote: > > Together with only accepting messages from entities you’ve sent presence to, > this should more or less completely prevent spam, This seems to be a recurring theme, and I'm not sure I like it. This couples presence

Re: [Standards] OMEMO Discussion Summary 2017

On 22 June 2017 at 09:48, Daniel Gultsch wrote: > Questions for OMEMO-NEXT for the new author to collect feedback on. > (Each of them deserves it's own thread) > Another category of questions that I think need to be added to that list is around key exchange and trust, bearing

Re: [Standards] OMEMO Discussion Summary 2017

Hi Ignat, I somehow got the feeling that some people on this mailing list actually > don't want the OMEMO standard to evolve, when it does not include the > changes they want. > I agree, I get the same feeling. > As it seems to be the "compromise" to not evolve OMEMO in the near future > and

Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

Hi, > This Last Call begins today and shall end at the close of business on 2017-03-14. FYI, this XEP seems to be in last call after its end date. > 1. Is this specification needed to fill gaps in the XMPP protocol stack or > to clarify an existing protocol? Yes. AFAICT, there's no other way

Re: [Standards] Encrypted Jingle File Transfer

> On 6 Jun 2017, at 13:02, Dave Cridland wrote: > > it might well be worth looking at XEP-0200 for full-stanza encryption Yeah, makes sense. Something like xmlenc gives you precise control over which parts you encrypt, but we probably don't need (or even want) that. This

Re: [Standards] OMEMO Key Agreement

Hi Sebastian, > I was going to suggest using seperate key-pairs: one for signing and one for DH. However, upon closer inspection it seems that the X3DH-specification requires XEdDSA signatures (https://whispersystems.org/ docs/specifications/x3dh/#cryptographic-notation), so if you did that you

Re: [Standards] Encrypted Jingle File Transfer

here's also XMLSec, the LibXML2-based C library, which has bindings in many languages: https://www.aleksey.com/xmlsec/ I used that to play around with xmlsec recently. Remko > > Am 04.06.2017 um 15:31 schrieb Remko Tronçon: > > Hi Vanitasvitae! > > I wonder if it would make sense

Re: [Standards] Encrypted Jingle File Transfer

Hi Vanitasvitae! I wonder if it would make sense to use something like xmlenc to have a 'generic' way to encrypt (parts of) stanzas. This way, you can decouple the encryption key info etc. from the things you want to encrypt, and you can choose to encrypt entire elements, or just parts of

Re: [Standards] OMEMO Key Agreement

Hi Sebastian, Thanks for your feedback, it's insightful. > Remko, generally speaking there are some issues with your proposal. I think we ended up agreeing that the way I was looking for compromises wasn't ideal for future-proofness. Apparently, it also has cryptographical problems. I don't

Re: [Standards] OMEMO Key Agreement

On 2 June 2017 at 09:56, Dave Cridland wrote: > Is that a fair summary? > Yes. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] OMEMO and Olm

Hi, I don't think this has much impact on the current discussion, but I'd like to come back to this for the record (and it may be relevant as an upgrade path): On 31 May 2017 at 01:40, Chris Ballinger wrote: > I don't have opposition to using Olm for any other reason

Re: [Standards] OMEMO Key Agreement

Hi Florian, On 31 May 2017 at 23:50, Florian Schmaus wrote: > I think it is unrealistic to > push a change that will render the currently used fingerprints invalid. > Just on this (because it might be relevant later): I think you're making fingerprint changes sound worse

Re: [Standards] OMEMO Key Agreement

Hi Daniel, a lot of what Dave said about future proofing spoke to me and I'm > starting to think he (and the others) are right. > Thanks for trying to see it from another perspective. My motivation in this discussion has indeed always been future-proofing. > It would become an > Informational

Re: [Standards] OMEMO Key Agreement v2

On 31 May 2017 at 21:02, Daniel Gultsch wrote: > Is the Curve25519 to Ed25519 conversion code available in a > significant number of liberally licensed crypto libraries? > Depends on what you call 'crypto libraries', but: LibSodium (C, so can have bindings in any language),

Re: [Standards] OMEMO Key Agreement

On 31 May 2017 at 20:44, Daniel Gultsch wrote: > Well not going against the entire OMEMO community would be a first > good step. > This is harsh, given all attempts I have done to find solutions that make 'the OMEMO community' happy, and open up the protocol to as many

[Standards] OMEMO Key Agreement v2

Hi, Here's a proposal for the OMEMO key exchange that requires *no* changes to libsignal: Public Identity keys are Ed25519 keys with the highest bit (sign bit) 0. - LibSignal-based clients convert their internal Curve25519 identity key to Ed25519 right before the device bundle publish IQ, and

Re: [Standards] OMEMO Key Agreement

Hi Chris, On 31 May 2017 at 20:26, Chris Ballinger wrote: > What if instead of all this, we just funded a liberally licensed XEdDSA > reference implementation and got it audited? To be honest, I still think it'd be suboptimal. It would make the XEP still dependent on

Re: [Standards] OMEMO Key Agreement

On 31 May 2017 at 17:42, Daniel Gultsch wrote: > The proposed solution would pretty much invalid the OMEMO protocol > audit (since important crypto parts are being changed) > If I give a solution that doesn't require *any* changes to libsignal (i.e. the compromise Chris

Re: [Standards] OMEMO Key Agreement

Hi Ignat, So just for the record (because you didn't answer that question from my > previous mail): > This is only an implementation detail and has no relevant influence (aka, > at most constant factor) on the cryptographic properties? > I'm not a cryptographer, but as far as my knowledge goes,

Re: [Standards] OMEMO Key Agreement

Hi Ignat, can you please describe the concrete benefits of your approach? > It gets rid of the non-standard XEdDSA dependency, which is blocking me (and likely others) in creating independent implementations that don't depend on libsignal. (see the other threads for my reasons). > The only

Re: [Standards] OMEMO Key Agreement

Hi Chris, On 31 May 2017 at 01:51, Chris Ballinger wrote: > So this is as simple as converting the Ed25519 key before ingesting into > libsignal (and vice versa)? Almost. The 'vice versa' (i.e. on the way out of libsignal) is true. The other way round (ingesting it

Re: [Standards] OMEMO Key Agreement

On 29 May 2017 at 07:53, Remko Tronçon <re...@el-tramo.be> wrote: > I may have a solution to our OMEMO key agreement discussion that satisfies > all of us. > FYI, to get some more confidence in this approach, I prototyped it using both libsignal and libsodium: https://github.

Re: [Standards] Depreciating XEP-0146: Remote Controlling Clients

Hi, I'm not advocating to keep this XEP, but I think it should be deprecated or obsoleted for the right reasons (even if it is a non-normative, simple XEP as this one). On 29 May 2017 at 16:49, Daniel Gultsch wrote: > Obsolete even due to the security implications the

Re: [Standards] OMEMO Key Agreement

On 29 May 2017 at 07:53, Remko Tronçon <re...@el-tramo.be> wrote: > - We change the Identity keys to be Ed25519 keys instead of Curve25519. > To clarify this a bit further: this is only about what is published (i.e. the public part of the identity key). Internally, libsignal-based

Re: [Standards] OMEMO Key Agreement

Hi Ignat, Unfortunately, libsodium is ISC licensed which requires carrying a > coypright/license header/file with all distributions of it. I don't > consider this a sufficiently liberal license. > This is raising the bar unreasonably high IMO. ISC is considered a permissive license (on par with

Re: [Standards] OMEMO and Olm

On 28 May 2017 at 16:47, Sam Whited wrote: > You'll notice that most (all?) of OWS's ed25519 code was > copied from here, > AFAICT, everything under additions/ is either new or modified ref10 code (_modified.*), hence only available under a GPL license. This includes

Re: [Standards] OMEMO and Olm

> eg. CMov is an operation that copies > data if some condition is true, but without actually branching, which > makes things a lot faster Is this really true? You can do *a lot* of branches+memcpys for 3 loops over all data as far as I know. I would have guessed this was a measure against

Re: [Standards] OMEMO and Olm

On 27 May 2017 at 17:46, Sam Whited wrote: > Here's the start of a submission to the Go crypto libraries (review > pending discussion of the proposal): > https://go-review.googlesource.com/c/44334/ > And you got all this just by looking at the XEdDSA spec? Maybe to you this

Re: [Standards] OMEMO and Olm

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

Re: [Standards] OMEMO and Olm

On 25 May 2017 at 15:53, Vanitas Vitae wrote: > So if that last part is resolved (which shouldn't be a big deal), then > Andys PR would be an accpetable compromise for everyone, am I right? > Don't forget the other part of your mail: if it also comes with one of your 2

Re: [Standards] OMEMO and Olm

> > There are concerns about the usage of XEdDSA, which could be solved by > either implementing the XEdDSA conversion function in a non-GPL way This would help, but I'll still feel very uneasy until it is available in an accepted crypto library. Other than that, I agree with your summary.

Re: [Standards] OMEMO and Olm

On Thu, 25 May 2017 at 11:02, Florian Schmaus wrote: > > Thanks Dave, but Remko's statement reads like *every* OMEMO > implementation based on libsignal is legally not in order I meant to say 1, not every. Remko > ___ Standards

Re: [Standards] OMEMO and Olm

On 24 May 2017 at 22:55, Andreas Straub wrote: > Yes, it's true that there's currently no such thing for XEdDSA, but is > this actually a concrete problem for anyone? Yes. I obviously can't speak for all the other clients that currently don't support OMEMO, but for Swift, XEdDSA

Re: [Standards] OMEMO and Olm

Hi Germán, On 19 May 2017 at 15:02, Germán Márquez Mejía wrote: > My only question is: Are there any potential privacy issues > here? > Good question. The only situation where i can see this happening is when this protocol is used in a broadcast situation, e.g.: -

Re: [Standards] OMEMO and Olm

Hi Andrey, My 2 cents: - Clarifications (like [2] and [3]) sound sensible. There's a lot that needs better wording, clarification, disambiguation, and rationale. I think this is something that should probably be done as the dust settles on the technical details of the XEP. - For [4]: I added

Re: [Standards] Proposed changes to OMEMO's use of PEP

On 3 April 2017 at 09:02, Florian Schmaus wrote: > Server side OMEMO support does not need to be mandatory to implement. > Given that server-side support was suggested mostly as a way for client developers to write less code, that would have the exact opposite effect. Remko

Re: [Standards] Proposed changes to OMEMO's use of PEP

On 26 March 2017 at 15:12, Andreas Straub wrote: > So even if we were to go this way, the timeline until we could in good > conscience actually enable this change in the client is on the order of > many, many months. Because I'm not about to break the protocol for my users. The

Re: [Standards] Proposed changes to OMEMO's use of PEP

On 26 March 2017 at 00:01, Timothée Jaussoin wrote: > This behavior can be fixed by setting pubsub#deliver_payloads to false in > the 'urn:xmpp:omemo:0' node configuration. > Bringing node configuration into a PEP-based protocol sounds like a slippery slope, and is maybe

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

Hi Matthew, On 31 March 2017 at 23:21, Matthew Hodgson wrote: > http://matrix.org/docs/olm_signing.html attempts to describe this > trade-off. > Thanks for sharing your insights. I didn't know about that document, and the tradeoffs and decisions you described make sense.

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

On 31 March 2017 at 15:40, wrote: > It just skips the conversion part altogether, which seems to be the > central point of discussion and is not widely implemented in any direction Interesting! I believe there *is* the open question whether using the same key for signing and

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

Hi Riba, > The attack is described in [1] and boils down to the following: > While I think that because of the noticability the possible damage is very limited, I kind of agree that it is not acceptable by design. One argument for 3DH might be its full deniability, which X3DH does not provide,

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

On 31 March 2017 at 12:46, Dave Cridland wrote: > Surely this is trivial to fully mitigate by having Bob "ping" Alice > over an encrypted message to ensure Alice can decrypt, prior to > sending actual message data? > This assumes Alice is online when Bob wants to talk to her,

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

On 31 March 2017 at 11:37, Daniel Gultsch wrote: > I think it is relatively fair to assume that a company or individual who > is able to create a Non-GPL implementation of the Double Ratchet will not > fail to do so just because of a missing XEdDSA implementation. I

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

> This requires huge changes in all OMEMO implementations, and there are > quite few already: https://omemo.top > I count 4 implementations in an incomplete list of 40 clients. As far as I understand, clients already need to fork and patch libsignal to be compliant with OMEMO anyway. 3DH takes 4

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

Hi Andy, Thanks for responding! On 30 March 2017 at 15:10, Andreas Straub wrote: > You raise a valid point. I agree that this construction seems cleaner from > a purely theoretical standpoint. > Actually, it's the practical standpoint that worries me most, in that this is not

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

Hi Daniel, On 30 March 2017 at 10:31, Daniel Gultsch wrote: > Are you looking for this: https://whispersystems.org/ > docs/specifications/xeddsa/ > No, I've seen the spec, thanks. I'm looking for implementations of it. This is low-level crypto, I would think you don't want

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

Hi, The upcoming version of the OMEMO XEP relies on X3DH for establishing an initial shared secret. In my extremely limited understanding of it, I'm wondering whether this is the best approach for OMEMO. X3DH relies on XEdDSA to be able to use Curve25519 keys to create EdDSA-signatures. As far

Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks

Hi Andy, On 29 March 2017 at 16:49, Andreas Straub wrote: > to make a long story short, a new revision of the spec has been in the > works for quite a while now and I just submitted the draft.[1] It should > resolve all of these questions. > Another question that pops up: the

Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks

Hi Andy, On 29 March 2017 at 16:49, Andreas Straub wrote: > to make a long story short, a new revision of the spec has been in the > works for quite a while now and I just submitted the draft.[1] It should > resolve all of these questions. > Great, thanks a lot! On first sight,

[Standards] OMEMO (XEP-0384) Crypto Questions/Remarks

Hi, I have a few outstanding questions/remarks about the crypto protocol part of OMEMO: - The XEP says it uses the Olm protocol, but it also mentions signed pre-keys (which I assume are about X3DH, which Olm doesn't use). Either the X3DH bits should be removed, or we should document our 'fork'

Re: [Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks

On 13 March 2017 at 09:39, VanitasVitae wrote: > The signed preKeys are used for authentication. > I understand this is the idea, but where is this described in the Olm/OMEMO protocol? AFAICT, this is an X3DH thing, which Olm doesn't use. > Deviceid collisions with

[Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks

Hi, I have a few questions/remarks about XEP-0384: - The examples mention signed pre-keys. This isn't part of the Olm protocol AFAICT, I only saw it in the original double ratchet spec. Is this a remnant of an older version of the XEP? Should this be dropped, or is the plan to use X3DH

Re: [Standards] Account Management protoXEP

For both account management and registration, using the ad-hoc framework seems most sensible - it would allow us maximum flexibility as well as near-instant deployment. I don't think registration fits the ad-hoc use case, because it is a special action outside of the general session flow,

Re: [Standards] Account Management protoXEP

If it's a well-defined FORM_TYPE, a client could do something fancy for the well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass gets a special strength meter nearby), and an advanced button/tab/overlay/etc for the non-standard things. Right, but I always found this to

Re: [Standards] LAST CALL: XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method)

I would also point out Tobias' request for clarification about the DST.ADDR computation: http://mail.jabber.org/pipermail/jingle/2011-August/001705.html

Re: [Standards] RTT, take 2

[ I don't like writing me-too e-mails, but you beat me by a minute to sending the exact same mail, so I'm doing it anyway ;-) ] So I'd say that we should refer to characters in a string, and deal with Unicode code-points in the abstract. I'd expect that implementations would convert this

Re: [Standards] RTT, take 2

So I'd say that we should refer to characters in a string, and deal with Unicode code-points in the abstract. I'm wondering whether 'code points' are any better than UTF-8 based positioning. Isn't it possible that a codepoint position also points inside a character/glyph/...? Peter could

Re: [Standards] RTT: no negotiation of the feature

Hi Mark, On Fri, Jun 24, 2011 at 5:15 PM, Mark Rejhon marky...@gmail.com wrote: The earlier spec covered feature negotiation via XEP-0020. However, it was encouraged by a few people that spec simplification became more important, and to focus chiefly on the most basic, core interop issues, at

Re: [Standards] hash agility in file transfer

I support Jingle FT with universal hashing, and I support Foo with universal hashing, and the hashes I support are X, Y, and Z, with a preference for Z. Or do we want to say: I support Jingle FT with hashes X, Y, and Z. I support Foo with Y, and Z. I think 99% will want to say 1, but I

Re: [Standards] hash agility in file transfer

They're lowercase. The usual way that IANA names differ from other names is that IANA always hash the hyphen in SHA names Ok then, even better :) One drawback of approach 2 and the agreement that all iana hash names are ok as elements is the potential clash between hash names and element

Re: [Standards] RFC vs privacy lists

under 'incoming IQ requests' for 2 reasons: they're not 'incoming' , and they're not 'requests'. I take one of both back, since the XEP talks about IQ stanzas, not requests. The conclusion remains the same, though: the server should not block them ;-) cheers, Remko

Re: [Standards] RFC vs privacy lists

I thought we had established incoming means incoming from the client's POV. Right, i actually meant the whole chain, up to and including the server part (up to the stanza router). It doesn't make sense to filter out stanzas from your own server (not talking about the ones from other users on

Re: [Standards] RFC vs privacy lists

That's normal because RFC [1] says that Privacy lists MUST be the first delivery rule applied by a server, superseding ... XEP 16 (copied from the RFC), section 2.14 says that the server should return service-unavailable. cheers, Remko

Re: [Standards] RFC vs privacy lists

XEP 16 (copied from the RFC), section 2.14 says that the server should return service-unavailable. And by 'should', i mean MUST. cheers, Remko

Re: [Standards] RFC vs privacy lists

So a client is not allowed to send an iq to its server if this anti-spam rule is set? I'm not quite following why it's not ok to send an iq to your own server? The XEP says that privacy lists block *incoming* IQs (that is, 'incoming' from the point of view of the client, so from other entities

Re: [Standards] Correcting last message

Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM

Re: [Standards] XEP-0184 1.1rc7

Done: Looks good to me! cheers, Remko

[Standards] XEP-0184 1.1rc7

Hi, Something still feels weird about the latest version of XEP 184. When sending back a receipt, the id of the message must mirror the id of the incoming message. So far, I always thought that id's were unique to the sender domain, except when the stanza is of type 'error' (or type 'result' for

Re: [Standards] XEP-0184 1.1rc7

As each message is in a stream with a particular direction Well, not really. Clients usually generate IDs based on some simple algorithm, and don't take into account IDs from incoming messages. For example, 2 clients with a simple incrementing counter would give this: C1-C2: (id=1) bodyhi

Re: [Standards] NEW: XEP-0279 (Server IP Check)

The clean separation of RFC 3920 and RFC 3921 allows this. XEP-0279 breaks this and causes tight coupling of these layers. On the other hand, if your server implementation has a hard time figuring it out, don't support it. If all the stories are true, this XEP is a use case that will only be

Re: [Standards] XEP-0048 bookmarks

I think the sensible thing for clients to do is to use 223 if it's available, and fall back to 49 if it's not. And, if 223 is available but contains no data, to check 49 anyway (in case the server upgraded and supports 223, and you want to transfer your bookmarks)? Or do we assume that servers

Re: [Standards] PDFs!

So highlighting should work for all XEP htmls now. They HTML files are rebuild right now. Looking good. Adding a border around the examples unfortunately reveals that we always have trailing whitespace at the end of the verbatim XMPP stanzas (to make the XML sources look prettier). It would be

Re: [Standards] PDFs!

XML source in the PDFs is now(might take some minutes until all XEPs are rebuild) using a mono spaced typeface. In our case it's in Inconsolata, http://www.levien.com/type/myfonts/inconsolata.html . I hope it meets your high font standards. :P I like Inconsolata, but never used it because it

Re: [Standards] PDFs!

I hope it meets your high font standards. :P Just checked the PDF. Inconsolata is no TheSansMonoCd (it feels a bit too loose to my taste), but I'm willing to shut up about it now. The copy pasting is still a bit off, but I'm sure you're working hard to fix that as we speak :) thanks! Remko

Re: [Standards] PDFs!

from http://xmpp.org/extensions/xep-0012.pdf in your editor you have different line breaking as you see in the PDF? No, i means that I get spaces in between characters. Copy pastng from Preview (OS X) gives me: i q f r o m = ’ r o m e o @ m o n t a g u e . n e t / o r c h a r d ’ i d = ’ l a

Re: [Standards] PDFs!

We're still working out a few glitches here and there, so your feedback is appreciated. Cool. Something seems wrong with the example stanzas, though: there's too much space between the characters, making the examples less readable. Perhaps a bad font selection, or forcing fixed with on a

Re: [Standards] Action rules in XEP-0050

Is that kind of structure commonly used for short-cuts in wizards, and suchlike? Unfortunately, it is. Horrible UI: there's no way of knowing what is behind 'next' unless you press it, so you basically have to press it anyway (unless you know your way around the wizard like a pro, and remember

Re: [Standards] Action rules in XEP-0050

There are less horrible scenarios, too. Good point. cheers, Remko

Re: [Standards] XEP-0136 - Message archive retrieval issue

I would say - both useful and practical: I don't think I agree: I'm still convinced resources should be treated as opaque strings. Historically, clients filled in hostnames, or worse, ask the user to provide his resource name, but nothing prevents servers to auto-assign resource names (GTalk

Re: [Standards] XEP-0030 - to attribute required?

Why is this? Should it be there? (For what it's worth, I'm not even sure it *can* be there - XEP-0030 can't change iq/ semantics). Odd indeed. I agree that it shouldn't be there. Maybe it's a historical leftover? cheers, Remko

Re: [Standards] xep - 144

We have two clients, A and B, only A supports the new protocol. A registers with the gateway so that contacts are not set in the main roster. Then B sends its presence and the gw what should do? If if does nothing, since the client won't get roster we just miss the contacts, but it is worse

Re: [Standards] Initial presence. Was Roster changes

- does anyone have any thoughts on this, because it seems to me that this is the underlying problem we're trying to solve here. I think most of us agree there is no protocol problem to solve. Either fix the client to use the long established delay protocol, and/or fix your server's

Re: [Standards] Initial presence. Was Roster changes

If for example an s2s link would only be closed if it has been inactive for 48h, then you know it's really not going to be used anytime soon. I think keeping it for 48h and exchanging and caching presences would be ok and And which part of that needs fixing in the protocol? Sounds more like a

Re: [Standards] Roster changes

Plus you don't know how long you have to wait to be sure if you got all presences. We're going in circles, all these problems have been addressed in the past threads. Everybody but one perosn seems to agree. Can we stop this thread now, and discuss the more interesting things we were

Re: [Standards] Roster changes

Yes? Sounds good to me! cheers, Remko

Re: [Standards] xep - 144

I'm sure there were good reasons for both these suggestions - I can understand why if we upgrade the usage we can upgrade the namespace, but what is the motivation for suggesting two different namespaces for the same job? It will take some time until server software is upgraded to 3921bis,

Re: [Standards] xep - 144

Two small issues: - it won't work until servers route the packets (small fix, but upgrades are needed) Indeed. This could be solved by using a new protocol. - transition will be difficult, since if it can't work while using two different clients of which just one supports it (and the case

Re: [Standards] Roster changes

A new roster proto could also include the presences of the contacts so you don't get thousands of presences, but get them with the roster. IMO, that would needlessly complicate things (duplicated functionality/information/...) at virtually no gain. cheers, Remko

Re: [Standards] Roster changes

work for me, as it takes 5 minutes until I see all presences (which SUCKS!). Sounds like you have a much bigger problem then. If your server takes 5 minutes to process all presence from your contacts, it means your initial roster get with your schema will take 5 minutes as well, so you won't be

Re: [Standards] xep - 144

Openfire allows this, and the gateways use jabber:iq:roster. It works fine, but in order to use too roster sequencing I'd like to have a centralized repository of the roster, and the best approach, if we don't want to hack into the server, is to directly tell the client what to do. Openfire

Re: [Standards] reliable messaging

It's possible, I suppose, that the remote client went offline before the message/, and came back online after, just in time to get the iq/, but it seems terribly unlikely, especially as you'd also see a presence/ update as it came back online. Well, there's not much worse than a reliable

  1   2   >