[Standards] XEP-0077: In-Band Registration - Account creation via XMPP and HTTP
Hi, At the moment, it is not recommended to provide a web registration URL if the server supports account creation via IBR. I created https://github.com/xsf/xeps/pull/1299 to provide a web registration URL in addition to account creation via IBR. The client or user can decide which one to choose. Please let me know what you think about it. To the Council: 1. What exactly do you mean by *The language is weird*? 2. I tried to describe the use case. Could you please explain your doubts? 3. Why would such a change be problematic for a final XEP? 4. Where should I add that change instead? Thanks in advance :) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: UPDATED: XEP-0453 (DOAP usage in XMPP)
Hi, Thanks for the update! Only the year is wrong. We are not yet in 2024 :) ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2023
Thanks for your feedback! > While usage of this command is certainly restricted to certain > "bubbles", those bubbles are wider than just the XMPP community. > "/me" > is implemented and used in various commercial platforms such as Slack > and Discord. Do they process that command in an advanced way or do they only display the name? > As a counter-argument, it is widely used, and by not supporting it a > client will present weird messages to its users when presented. > If this was an onerous XEP to implement, the argument might be > different, but this isn't hard to implement, and by not having it > 'weird things' happen. At least parsing and a language-specific command could be avoided. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2023
Hi, I would like to propose the removal of "The /me Command" from the IM Compliance Suite. In my opinion, it is neither necessary (users can type their name instead) nor a substantial functionality that many users (outside of our geek bubble) need for chatting. It does not mean that clients should not support it but I think it should not be listed as an (implicitly important) feature clients must support in order to comply with the compliance suite of 2023. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Editor intends to resign
Thank you very much for your great job! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Versioning
Hi Dave, thanks for your explanation! What is the reason for having a state such as Stable or Final and a redundant state (major) version? In my opinion, it would make more sense to have a separate state and semantic versioning as specified by https://semver.org . Or, if for any reason the state must be declared by the version, the version scheme state.major.minor.patch as Zash said in xmpp: x...@muc.xmpp.org?join would make more sense to me. The namespace would then change when the major version changes. Developers as well as XEP lists could quickly determine if there was a breaking change by checking the major version. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP Versioning
Hi, I created a PR for precisely specifying the versioning of XEPs: https://github.com/xsf/xeps/pull/1200 Here is the reason: https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948 Please let me know what you think. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements
Thanks for the history! I think that there are two main questions: 1. Should it be possible to publish or retract multiple items within one request? 2. May event notifications contain multiple items (if batch processing is possible or if the server caches multiple requests)? Even if multiple items may be published or retracted within one request, event notifications could still be sent out for each published or retracted item. But that should be clarified by the specification. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements
Hi, I am wondering why the XML schema for PubSub events ( https://xmpp.org/extensions/xep-0060.html#schemas-event) specifies that the "items" element of events may contain multiple "item" and "retract" elements: While https://xmpp.org/extensions/xep-0060.html#publisher-publish-request and https://xmpp.org/extensions/xep-0060.html#publisher-delete-request specify that it is not allowed to publish multiple items, https://xmpp.org/extensions/xep-0060.html#impl-batch allows that explicitly. I could imagine an event containing multiple items triggered after such a batch processing or if the server caches multiple single item publications before sending an event notification. But if that should be possible and handled by clients, where is that specified? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XEP-0060 Changes
Thanks for the constructive discussion! Editing XEP-0004 sounds good. > Incomplete Submission Form Handling > > Incomplete submission forms are forms of the type 'submit, where are > all required fields are set, but some non-required fields are > omitted. > The receiving entity of an incomplete submission form SHOULD only > process (e.g., apply) the submitted fields. If applicable, the values > of the omitted fields keep their current value (often the "default" > value found in the corresponding 'form' type form). 1. Should I add that as § 3.5 to XEP-0004 (after https://xmpp.org/extensions/xep-0004.html#protocol-results)? > Note that the [rules for incomplete submission form handling apply > (XEP-0004 § > TODO)]( > https://xmpp.org/extensions/xep-0004.html#incomplete-submission-form-handling > ). 2. Should I change https://github.com/xsf/xeps/pull/1126/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R3734 to that? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-406] Questions
Hi Manuel, I am working on Kaidan's (https://kaidan.im) MIX implementation and will create a pull request with various fixes for the MIX XEPs including the wrong example you found. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-12-02
Hi Zash, I used "OOK" as an abbreviation for "only one key". You can find it here: https://xmpp.org/extensions/inbox/automatic-trust-management.html#use-cases > If the encryption protocol used with ATM involves only one key for > all endpoints of the same identity, only the use cases for > authenticating and distrusting keys of a contact's endpoint are > relevant. Those use cases are marked with OOK for only one key. If you use ATM e.g. with OpenPGP for XMPP and each chat partner has only on key for all own devices, you would only need to implement the "OOK" use cases. >> 4d) Proposed XMPP Extension: Automatic Trust Management - >> https://xmpp.org/extensions/inbox/automatic-trust-management.html >+1 > >What's "OOK" tho? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0434 (Trust Messages (TM))
e contacts. She has already authenticated their keys with her smartphone and would like to use a new notebook. She can simply scan with her smartphone the QR code of her notebook. Her smartphone automatically sends a TM for the key of each contact to her new device. As soon as Alice scanned with her notebook the QR code of her smartphone, her notebook uses the TM to automatically authenticate the keys of all three contacts. Let me know if that was helpful ;) > I mean, what 'remaining authentications' are you referring to? > > Can you describe a scenario, like, Romeo with a smartphone and Juliet > with > desktop computer want to initiate an encrypted chat, what do they do? > > On Mon, Dec 7, 2020, 00:00 Melvin Keskin wrote: > > > Hello Andrew, > > > > thanks for your questions! > > > > The authentication of public long-term keys is needed to ensure > that > > those keys are the keys of the pretended owners. > > > > Trust Messages (TM) is intended to provide a basis for XEPs such as > > Automatic Trust Management (ATM) ( > > https://xmpp.org/extensions/inbox/automatic-trust-management.html). > > > > ATM minimizes the effort of authenticating all keys manually. You > need > > to manually authenticate a key (e.g. by verifying its fingerprint) > only > > once. The remaining authentications are done automatically. > > > > Additionally, ATM can improve the security because verifying many > > fingerprints involves the time and concentration of the verifier. > > Mechanisms such as QR code scanning might improve the latter > problem > > but it is still time consuming. > > > > Thus, QR code scanning should be preferred for the initial > > authentication of a key which ATM needs to automate all remaining > > authentications. > > > > I hope that helped to understand the purpose of both XEPs better. > > > > > > Kind regards, > > > > Melvin > > > > > Can someone explain this to me like I'm 5 years old? Why is this > > > needed and how it improves security over regular 0384? Isn't > > > fingerprint matching enough a caution? > > > > > > вт, 1 дек. 2020 г. в 22:37, Jonas Schäfer : > > > > > > > > Version 0.2.0 of XEP-0434 (Trust Messages (TM)) has been > released. > > > > > > > > Abstract: > > > > This document specifies a way to communicate the trust in > public > > > long- > > > > term keys used by end-to-end encryption protocols from one > endpoint > > > to > > > > another. > > > > > > > > Changelog: > > > > Improve explanations, descriptions and examples, introduce new > > > > attribute and complete all sections: > > > > * Remove link to encryption protocol namespaces. > > > > * Add short name > > > > * Shorten and improve introduction. > > > > * Use emphasizing text formatting instead of quotation marks. > > > > * Add new section for explaining the core properties of trust > > > > messages. > > > > * Add examples comparing trust messages to public key > certificates. > > > > * Improve description of trust message structure. > > > > * Introduce 'usage' attribute for 'trust-message' element. > > > > * Focus on and adjust examples accordingly. > > > > * Complete sections 'IANA Considerations', 'XMPP Registrar > > > > Considerations' and 'XML Schema'. (melvo) > > > > > > > > URL: https://xmpp.org/extensions/xep-0434.html > > > > > > > > Note: The information in the XEP list at > > > https://xmpp.org/extensions/ > > > > is updated by a separate automated process and may be stale at > the > > > > time this email is sent. The XEP documents linked herein are > up-to- > > > > date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0434 (Trust Messages (TM))
Hello Andrew, thanks for your questions! The authentication of public long-term keys is needed to ensure that those keys are the keys of the pretended owners. Trust Messages (TM) is intended to provide a basis for XEPs such as Automatic Trust Management (ATM) ( https://xmpp.org/extensions/inbox/automatic-trust-management.html). ATM minimizes the effort of authenticating all keys manually. You need to manually authenticate a key (e.g. by verifying its fingerprint) only once. The remaining authentications are done automatically. Additionally, ATM can improve the security because verifying many fingerprints involves the time and concentration of the verifier. Mechanisms such as QR code scanning might improve the latter problem but it is still time consuming. Thus, QR code scanning should be preferred for the initial authentication of a key which ATM needs to automate all remaining authentications. I hope that helped to understand the purpose of both XEPs better. Kind regards, Melvin > Can someone explain this to me like I'm 5 years old? Why is this > needed and how it improves security over regular 0384? Isn't > fingerprint matching enough a caution? > > вт, 1 дек. 2020 г. в 22:37, Jonas Schäfer : > > > > Version 0.2.0 of XEP-0434 (Trust Messages (TM)) has been released. > > > > Abstract: > > This document specifies a way to communicate the trust in public > long- > > term keys used by end-to-end encryption protocols from one endpoint > to > > another. > > > > Changelog: > > Improve explanations, descriptions and examples, introduce new > > attribute and complete all sections: > > * Remove link to encryption protocol namespaces. > > * Add short name > > * Shorten and improve introduction. > > * Use emphasizing text formatting instead of quotation marks. > > * Add new section for explaining the core properties of trust > > messages. > > * Add examples comparing trust messages to public key certificates. > > * Improve description of trust message structure. > > * Introduce 'usage' attribute for 'trust-message' element. > > * Focus on and adjust examples accordingly. > > * Complete sections 'IANA Considerations', 'XMPP Registrar > > Considerations' and 'XML Schema'. (melvo) > > > > URL: https://xmpp.org/extensions/xep-0434.html > > > > Note: The information in the XEP list at > https://xmpp.org/extensions/ > > is updated by a separate automated process and may be stale at the > > time this email is sent. The XEP documents linked herein are up-to- > > date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> You might have wanted to respond to all list, not just me personally. Yes, thanks. > ср, 10 апр. 2019 г. в 14:25, Melvin Keskin : > > > Thanks for explaining critical aspects of secure communication. > > > > But end-to-end encryption is about sending encrypted messages from > one > > secure endpoint to another secure endpoint. It is not about > securing > > the endpoints themselves. If an endpoint is compromised, no end-to- > end > > encryption can help. > > > > yes, but you should not breed endpoints with automatic trust transfer > anyway. Manual verification has a very distinct purpose: it should be > done > NOT via the potentially compromised channel, but after personal > interaction > with a person you are granting trust. But this ATT thing blindly > allows > different forms of abuse. > > We're actually having some issues with similiar subject too. We've > created > a brand new type of group chat, and we're considering a protocol to > make it > secure. And if a group chat has 10 participants with 3 devices each, > that's > a staggering number of manual verifications. Blind trusting in > conferences > like some clients do is absolutely out of the question, but manual is > hardly feasible too. Most likely we'll go with some form of CA, with > one of > the participants acting as one, deciding whom to trust and whom to > not, but > he should do it manually in decidedly NOT automatic way for every new > device encountered. > > > -- > Andrew Nenakhov > CEO, Redsolution, Inc. > https://redsolution.com <http://www.redsolution.com> A semi-automatic form of ATT (manual sending of trust messages but automatic authentication by a recipient) could also be used for group chats. That could fit your needs but it is not (yet) specified. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
Thanks for explaining critical aspects of secure communication. But end-to-end encryption is about sending encrypted messages from one secure endpoint to another secure endpoint. It is not about securing the endpoints themselves. If an endpoint is compromised, no end-to-end encryption can help. In the case of revocation I wrote: > // TODO Further discussion has to take place before finalizing this > section. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
Hello Andrew, ATT simply eliminates the disadvantage in usability which comes from using one key per device so that you can have all advantages of OMEMO but without the disadvantage of many manual authentications. It does not diminish the security level of OMEMO or other benefits. Pleas have a look at the XEP under "Advantages": > For creating the described complete graph with n nodes, a total of > T(n) = (n*(n-1))/2 ∊ O(n²) mutual authentications are needed. When > using ATT, only T(n) = n-1 ∊ O(n) of them have to be made manually. > All remaining authentications can be performed automatically. Thus, > less user interaction is needed for authenticating all keys involved > in the secure communication while preserving the same security > level. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> I already replied: if we produce both XEPs, we'll end up with some > devices with manual/ATT verification and others with EAX. This will > further degrade UX. So the XEPs interaction is required to be > documented. I appreciate that you think of UX aspects but ATT should not degrade UX when another way of authentication is implemented alongside it. For ATT no user interaction is needed and it can always be used. It is not necessary to deactivate it. It can just be extended by other mechanisms covering other cases. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> I kinda misread your proposal, so it's irrelevant in the context of > the > proposal, sorry for confusion. OK, you're welcome. > Well, I understand all this. However, a complete picture I see is > CA-signed certificates by default, and ATT and/or manual > verification > when you need more rigid authentication. > So my suggestion is to stop > taking positions (whether CAs are bad or whether manual verification > is > usable for regular users) and create a more general "framework". I > also > would like to note that MLS supports both ways. And, yeah, I see how > ATT can improve UX as well (in theory). Every way has its advantages and its disadvantages. Currently, OMEMO is the best supported and most widely-used (if not said only) end-to-end encryption in my community. That was the reason for creating ATT. I wanted the users to benefit from automating the whole process of key authentication now and not some day in the future. If we only concentrate on the future, we will forget the problems current XMPP users are facing nowadays. My main focus are new XMPP users. It was hard for me to get them to XMPP and we will lose them again if we do not provide solutions for current problems. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Voting Summary 2019-03-31
You wrote in your first message on ATT: > This alone is absolutely not a blocker to adoption in my view. Then I read: > -1 - I don't think there's evidence of this being anything beyond a > very > high-level sketch. Designing a cryptographic trust system is complex, > and > I'm not convinced we have the expertise to adequately do such a > thing. I am confused now because I thought you would accept ATT but it needs more improvement. What did you mean by "This alone is absolutely not a blocker to adoption in my view."? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> Maybe one could bundle all those verifications up in some data > structure and then either send 1! message or even do it over IQ. In the next version of ATT fingerprints of keys of multiple contacts will be bundled. Thanks for your proposal. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> In the series of body semantics rants, I feel the need to mention > that I > don't like the wire format. I don't see any reason to overload body > semantics with this new feature. > > Clients that don't support this XEP won't be able to do anything with > it > and that would only appear raw to the user who would most likely be > clueless about it. > > Is there anything we can do here? Yes, as stated in my email message to Dave Cridland, the next version of ATT will not overload the body anymore. Special thanks to Paul Schaub for finding a better solution and of course thanks to you for your tenacity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
> If the Council accepts both XEPs as is, then we raise inconsistency in our XEPs. ATT does not depend on EAX. It just tackles the challenge of key authentication when using end-to-end encryption with multiple devices having different keys. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
Hello Evgeny, thanks for your comments. > I don't understand how this will work in practice indeed. > 1) The "trusted" graph is not connected (i.e. you cannot reach any > vertex from any other vertex), thus, in the worst case the > complexity > of verification will remain the same. In all other cases than the worst case the users will benefit from ATT. > This is especially doubtful, > since it's speculated that the topology of a social graph has power- > law > distribution [1] and thus only a few people will benefit from the > "trust transfer". What exactly do mean by that? > 2) The problem of manual verification is still unresolved, because > for > online persons (i.e. without meeting them offline) you have to use > an > already trusted channel to perform verification, so chicken and egg > problem. The goal of ATT is not to simplify the manual authentication instead it reduces the number of manual authentications for multiple devices (of two communication partners) each having a different key. > 3) Isn't it better to work on the problem together, i.e. in the > context > of my EAX proposals? If you don't trust the CA or want to have > additional guarantees you can resort to manual or ATT verification. > I > don't see any contradictions here. Both approaches are kinda > complementary and can be working together, unless you're reluctant > and > hate CAs. Using Certificate Authorities (CA) for key authentication would be better than not authenticating keys at all. It could be used additionally to the authentication of keys via ATT when you have no other trusted channel to a contact. ATT is completely independent of CAs. One advantage is that a user do not have to decide which CA is trustworthy and which not. If one CA trusts a contact's key and another not, the question "which CA should the user trust?" comes up. Besides some other advantages that is a problem ATT solves for the case when there is an already trusted channel like a meeting in person. In the case of own devices the user normally has such a trusted channel to manually authenticate the keys of those devices (e.g., by scanning their QR codes containing the fingerprint of the device's key). Thus, a CA will never be necessary. ATT does not exclude other ways of authentication. A combination of more ways than that would be great to simplify the usage of end-to- encrypted communication with authenticated keys. Thanks. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
Hello Dave, thank you for your comments. > * It always worries me when people suggest security protocols and use > odd > naming conventions. There is, surely, no such thing as "trust > transfer", > whether automatic or not. Trust can be transitive, of course, but not > transferable. I would suggest to rather focus on the topic instead on the name. > * The messages are simply defined as being URIs. One assumes these > are > transferred over XMPP, but it's not described how. Presumably these > would > need to be authenticated messages somehow - are these intended to be > encrypted themselves using OMEMO? What format is used? In the current version the URIs are inserted into the body of the XMPP message using OMEMO. Since the content of the trust message is exclusively used for automatic processing, it would be better to use OMEMO encrypted XML elements. Therefore, I will change the format of the trust message's content from URI to XML and take it out of the body. > * §4.1 is virtually impossible to follow because there's no > indication of > who owns what devices. In that section it is irrelevant who owns those devices. It should only explain the basic procedure and give a rough understanding of it. > * In §6, we see that Bob's trust of the keys A2 and A3 is predicated > on a > continuing trust of the key A1, but the trust is described as > absolute > rather than as a chain. If A1's key is later revoked, it is unclear > whether > one expects B1 to continue to trust A2 and A3. Only for clarification: In the examples A1, A2 etc. are devices not keys. The primary goal of the XEP was to minimize the number of manual authentications. But for revocation your proposed chain of trust could be used additionally. I will try to work on that in the next version. > * It is not explained how A1 trusts A2 and A3, or vice-versa. I do not understand your comment. Could you please rephrase that? > * §8.1 describes mandated behaviour, but does not explain what the > attack > is nor how this behaviour mitigates the attack. End-to-end encryption is based on the assumption that the devices are not compromised. Section 8.1 is used for having an additional protection when a device is stolen. If the recipient of the trust message would like to check the correctness of the received information via another channel, it may be done. In the first case the user is simply informed about the automatic authentication. In the second case the user is asked for confirmation before any authentication happens. The authentication which would normally be automatic is then semi-automatic. That means that the trust message is sent automatically but the authentication is not done completely automatically. I will move the first two sentences of section 8.1 to another section so that the intention of the rest of that section is clear. > * §8.2 describes a general attack briefly, and then mandates > behaviour. > Neither of which to my eyes has little or nothing to do with ATT > itself, > but relates to OMEMO (or even XMPP) in general. ATT automates authentications which formerly had to be done manually. If you do not revoke the trust in blindly trusted keys after an authentication, there is no chance to protect the user against active attacks made with those keys even if you authenticated all of the good keys. When using ATT, many steps are automated. So, the goal of trusting only authenticated keys is easier to achieve. That is the reason for recommending the described security policy. > Overall, my view is that this specification is very unclear and > impossible > to implement as written. Please have a look at https://github.com/olomono/att. There is an implementation and an algorithm (pseudocode). I followed the current version of the XEP. Thus, it is possible to implement the XEP by following it. > This alone is absolutely not a blocker to adoption > in my view. However it is not clear whether the community has the > ability > and expertise to adequately review and develop such a specification. There were many discussions until now with many of the current OMEMO developers and also non-OMEMO client and server developers. I improved the XEP with their help. So, I would say that the community is able to review it. You reviewed it as well (as a member of the community) and I will use your comments for improving the XEP. Thanks. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
Hello, I am the author of Automatic Trust Transfer (ATT). You can find further information and links in the ATT repository: https://github.com/olomono/att ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
