[Standards] XEP-0390 improvement proposal: Cashing disco#info for services of user's server
Problem: On each client start it necessary to send to disco info to each service to determine where is upload, muc, socks5 and other useful stuff. This slowdowns the startup and adds some load to the network and server. Depending on implementation and service type this is not obligatory should happen on start but anyway the info is not cached. XEP-0390 describes caching of disco#info for server/stream itself and for caps from presences which usually come from contacts. There is nothing about caps of specific services. Proposal: There are many ways to add caps hashes for services but it's hard to say which one is the most appropriate. I see next ways 1. Add element to each item of disco#items. At least the XEP-0030 doesn't forbid it. 2. During computation of caps included in consider also caps of services and maybe just xor them. 3. Add caps of services to as a separate elements with "jid" attribute This will also allow to avoid disco#items in some cases. 4. Invent special disco#caps request similar to disco#items I personally prefer 1 since together with similar updates to XEP-0230 it will also provide caps update notifications. Thanks, Sergey ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Minutes 2019-01-02
http://logs.xmpp.org/council/2019-01-02/#16:03:50 Happy New Year to all and sundry. 1) Roll call Present: Kev, Link, Georg Distrait: Jonas, Dave 2) Agenda bashing Georg suggests voting on deprecation of the XEPs from the previous meeting; Link reminds that current process doesn't allow for obsoletion (or deprecation) without going through a Last Call. Kev proposes punting everything to next week, when people are hopefully more lucid and Dave might even prepare an agenda in advance. 3) Date of next 2019-01-09 1600 UTC 4) AOB Nada. 5) Close Link suggests everyone has a nap - Kev thinks that sounds good; Georg is already snoring. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Histroy tranfer idea
On Wed, 2 Jan 2019 at 17:07, Evgeny wrote: > On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland wrote: > > Out of curiosity, do we know if the cryptographic properties involved > > in sending a known set of plaintext about like that stack up? > > I wonder how everyone is fixated on crypto part while the hardest > part is messages replication itself: in the described scenario we > introduce several replicas of messages - client devices (which can > be many) and a server. This quickly rises several questions related > to a replication in distributed systems: > 1) how to perform deduplication > also, if MAM is disabled on the server: > 2) how to maintain message casuality (among client devices) > 3) how to maintain replica merges after partitions (between client > devices) > > While I like the idea of messages replication between user devices, > I think the implementation will be too complex for a regular XMPP > client developer > even if we write down all this in a XEP. > Yes, I think I agree with these points, too. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Histroy tranfer idea
On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland wrote: Out of curiosity, do we know if the cryptographic properties involved in sending a known set of plaintext about like that stack up? I wonder how everyone is fixated on crypto part while the hardest part is messages replication itself: in the described scenario we introduce several replicas of messages - client devices (which can be many) and a server. This quickly rises several questions related to a replication in distributed systems: 1) how to perform deduplication also, if MAM is disabled on the server: 2) how to maintain message casuality (among client devices) 3) how to maintain replica merges after partitions (between client devices) While I like the idea of messages replication between user devices, I think the implementation will be too complex for a regular XMPP client developer even if we write down all this in a XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Histroy tranfer idea
You'd be most welcome to write this down and submit it as a XEP - it's really not as hard as it sounds, and you don't need to worry about too much detail at this stage. Out of curiosity, do we know if the cryptographic properties involved in sending a known set of plaintext about like that stack up? On Wed, 2 Jan 2019 at 15:47, j.r wrote: > Hello list, > > today I had an idea for a way to transfer history from old clients to > newly added ones: > > If a new client is added to an account it request to the other clients > if they could send the history over. If the other client somehow trust > the new client (e.g. with a accept dialogue) it encrypts all messages > for the OMEMO Key of the new Client and sends them to it. The new client > will decrypt it and save it to his database. > > It would be an easy way for not very technical users to switch devices > or so. > > Now I have two questions: what do you think about this in general? And > if you like the idea is there someone that could help me to write it > down as an XEP? (Because I've never written an XEP before and that idea > is somehow complex) > > Thanks for you attention > j.r > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Histroy tranfer idea
Hello list, today I had an idea for a way to transfer history from old clients to newly added ones: If a new client is added to an account it request to the other clients if they could send the history over. If the other client somehow trust the new client (e.g. with a accept dialogue) it encrypts all messages for the OMEMO Key of the new Client and sends them to it. The new client will decrypt it and save it to his database. It would be an easy way for not very technical users to switch devices or so. Now I have two questions: what do you think about this in general? And if you like the idea is there someone that could help me to write it down as an XEP? (Because I've never written an XEP before and that idea is somehow complex) Thanks for you attention j.r ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Should we split XEP-0300 (Use of Cryptographic Hash Functions in XMPP) up?
On 16 Dec 2018, at 09:37, Jonas Schäfer wrote: > > This may sound ridiculous at first, given that the text easily fits on less > than 10 pages in font size, but bear with me. > > I was proposing an LC for it to Kevin, because the protocol IMO is rather > mature, but then I realized that we have a slight issue here: > > - The protocol could probably even be put in Final right now, it seems very > "done" to me. > - We can never put the required support of hash functions to Final. > > So I suggest to split XEP-0300 into two parts: > > 1. A Standards Track part which includes only the protocol. > 2. An Informational part which includes only the hash function > recommendations, as well as the related XEPs section. > > What do you folks think? Whatever the track of the MTI hashes, I think we do need it split if we’re to advance the protocol part. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
