Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Automatic Trust Transfer (ATT) > Abstract: > ATT specifies an automatic transfer of trust in public identity keys > used by the end-to-end encryption protocol OMEMO. > > URL: https://xmpp.org/extensions/inbox/automatic-trust-transfer.html Several things about this have me concerned: * 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. * 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? * §4.1 is virtually impossible to follow because there's no indication of who owns what devices. * 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. * It is not explained how A1 trusts A2 and A3, or vice-versa. * §8.1 describes mandated behaviour, but does not explain what the attack is nor how this behaviour mitigates the attack. * §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. Overall, my view is that this specification is very unclear and impossible to implement as written. 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. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]
On 2019/03/27, Sam Whited wrote: > > > On Wed, Mar 27, 2019, at 19:33, Ненахов Андрей wrote: > > How do I turn off markdown processing on your side? I don't even know > > you do have some thing that misformats my message despite having no > > intent to be misformatted that way. This is especially a problem when > > someone is trying to pass parts of computer code or config. > > What I'm saying is that *I* want to decide what messages I receive look > like, why would I want you to be able to arbitrarily turn on or off *my* > formatting? If you send me a message, I should be the one to decide if I > use your plain text fallback (eg. *bold*) or the actual markdown (bolded > text). You shouldn't get to decide what I see and don't see. If you > don't want me to see styling, don't send me something with styling > directives. I agree with this. I agree with this so much that I fail to see how you relate that to 0393. In 0393, there is no "sending client" per se, there is only receiving clients. One cannot distinguish between intended and accidental markup. I, as a receiver, can choose not to display markup, or to display what may or may not be markup. Also with 0393, I as a sender cannot ensure the semantic meaning will go through. I generally use "*foo*" to indicate an action. This has nothing to do with bold. My next "*foo*" might actually just be bold, but you can't distinguish between the two. I would like to be able to tell you that, so you(r client) make(s) the correct decision when displaying it. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
On 2019/03/27, Sam Whited wrote: > On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote: > > 0393 is not bad, IMHO. It might need two or three additions, esp. > > hyperlinks, but most typical use cases are covered. > > What is the use case for hyper links and who does it benefit? I > keep hearing people say they want them, but I don't really > understand why they're necessary over just auto linking things that > look like URLs. Thanks. At work we use Mattermost (Slack-like alternative). Mattermost allows one of the many markdown variants to be used[0]. Out of about 100 people, I see hyperlinks being used every single day. Of course autolinking is also used (when it doesn't fail), but people also seem to be using them to shorten the displayed sentences[1], or provide a bit of context to a link. For example: "I'm working on [implementing that teleport machine](https://linktoourtracker.company.com/T12345) we talked about. See also [that related ticket](https://linktoourtracker.company.com/T12346)." [0]: https://docs.mattermost.com/help/getting-started/messaging-basics.html [1]: Yes, Mattermost doesn't allow me to disable this formatted display. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
On Thu, Mar 28, 2019 at 12:41 PM, Philipp Hörist wrote: I saw no arguments against 0394 and its approach, as i see it perfectly fits Andrews usecases. I dont see that there is a need to enclose each markup element into reference elements just for the sake of consistency. This would lead to some horrible inefficient syntax. I think developers can deal with the syntax that is described in 0394, they will not give up because they dont find a reference element. I'm not a client developer, but technically I tend to think that XEP-0394 is way superior because you get ready to use AST attached to the text, so you don't even need to parse anything. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
Am Do., 28. März 2019 um 09:48 Uhr schrieb Dave Cridland : > > 3) I don't think Andrew's assertion that our current (partial?) solutions > for his requirements are an overlapping mess ought to be discarded out of > hand. Cleaning these things up might make a lot of sense. > > I dont see an overlapping mess. We have an old deferred standard IM-XHTML -> We have a potential new approach XEP-0394 We have an old insufficient way to send media OOB -> We have a potential new sufficient approach SIMS (There will always be one more missing attr that could potentially be useful in a media transfer so i ignore the fact that Andrew wants to transfer seconds of a audio file, this is easily added) There is a "lets document the client praxis" kind of XEP-0393 which states some easy markdown syntax that may be encountered when using XMPP. I see this as a sort of document where developers can look up some easy markup stuff that some clients use. I dont see this as a serious approach to solve all markup needs of XMPP and i dont think it should be further extended. Yet people will probably use it because they know the syntax from other IM-Apps. But i dont see this XEP in opposition to any other XEP. I saw no arguments against 0394 and its approach, as i see it perfectly fits Andrews usecases. I dont see that there is a need to enclose each markup element into reference elements just for the sake of consistency. This would lead to some horrible inefficient syntax. I think developers can deal with the syntax that is described in 0394, they will not give up because they dont find a reference element. Whats missing from SIMS except some useful attrs? Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
Evgeny, While I'm certain that Carlo is thick-skinned enough to ignore this remark, I don't think it's helpful either to this thread or the community as a whole. I appreciate it's hard not to react, I've done so myself many times in the past, but I've learnt painfully that it is more useful to keep things polite, technical and focused. Hopefully I manage to do this most of the time. Feel free to call me out when I err, I do appreciate it - at least in the long term. :-) Please, everyone, ensure your messages are like an efficient light bulb - optimise for light, not heat. Thanks, Dave. On Wed, 27 Mar 2019 at 21:25, Evgeny wrote: > On Wed, Mar 27, 2019 at 11:17 PM, carlo von lynX > wrote: > > XMPP will be nearly completely dead in coming years > > as it has always refused to change the fundament of its > > inflexibility > > Hey, dude, how is your psyced going? Oh, it's dead. Okay. > > ___ > 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 ___
Re: [Standards] One true final way to mark up messages
On Wed, 27 Mar 2019 at 18:25, Sam Whited wrote: > On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote: > > 0393 is not bad, IMHO. It might need two or three additions, esp. > > hyperlinks, but most typical use cases are covered. > > What is the use case for hyper links and who does it benefit? I > keep hearing people say they want them, but I don't really > understand why they're necessary over just auto linking things that > look like URLs. Thanks. URLs are often frustratingly long, and they're also surprisingly difficult to pick out of text unless the longhand formal syntax is used. Real users often do not send those, instead sending a bare domain - or just a typo missing a space after the period.which often gets highlighted as a URL... Many consumer systems I've been playing with recently instead have a formal "link" construct that's sent alongside the message, much like Andrew's suggesting here. An exception, as you point out elsewhere, is Slack - but Slack is fascinating in its demographics. It's the darling of tech and finance departments everywhere, but our sales department hates it - it is not the model you want to follow for consumer-grade social IM. In any case, we're neither trying to replicate any particular existing system, nor taking Andrew's suggestions and immediately pushing them through to Draft. I said before (but foolishly replied and thus quoted his monster message in entirety), I think there's a few things we can very usefully draw from the message: 1) It makes an excellent list of requirements for a modern consumer-grade social IM. 2) Some of the details are things missing from our current stack. I'm thinking that "legacy" trick, for example. 3) I don't think Andrew's assertion that our current (partial?) solutions for his requirements are an overlapping mess ought to be discarded out of hand. Cleaning these things up might make a lot of sense. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
