Re: [Standards] Proposed XMPP Extension: Message Reactions
Quoting Dave Cridland : On Fri, 19 Jul 2019 at 15:52, Georg Lukas wrote: 4. Limitation to Emoji ... Loose agreement here, but also, I suspect people will rapidly want to react in custom ways not expressible in Unicode, so we might want URls or inline media to be possible too. We already see, the emojis get less important here and there and are replaced by "stickers". Which is already supported in XMPP by XEP-0231 (bits of binary, BoB). This allows even more childish and silly reactions! XMPP reactions should support that. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Voting Summary 2019-03-31
Quoting Dave Cridland : * But this is creating our own cryptography, and the XSF should not be doing that. If I understand ATT correctly, it's not cryptography in itself, but automation of key "trust state" copying. More a kind of convenience function. Please CMIIW. ___ 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
Quoting Sam Whited : IM isn't the web, I agree. IM messages are - in general - short. Named URLs allow shorter messages, that are better readable esp. by non-technical people. In the context of 0393, I suggest something like: [http://shakespeare.mit.edu/macbeth/ The Tragedy of Macbeth] and [xmpp:x...@chat.yax.im?join Off-topic MUC] ___ 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
Quoting Sam Whited : 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 sometimes readable to me, sometimes not. For most non-geek people URLs are never readable. Therefore, HTML has an anchor element with content and not just auto linking. Mainly an aesthetical question. ___ 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
Quoting Ненахов Андрей : XHTML is deprecated, This, unfortunately, is the case. I'm not completely convinced of the arguements against 0071. and all other proposals are not in usable shape. 0393 is not bad, IMHO. It might need two or three additions, esp. hyperlinks, but most typical use cases are covered. For anything more complex there is 0071. It only needs to be resurrected. Like Lazarus. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)
On 2019-02-04 19:17, Jonas Schäfer wrote: > 5. Is the specification accurate and clearly written? Minor clarification would be nice: It was not immediately clear to me, that the json element must contain exactly one JSON object. And that for multiple JSON objects one must either use multiple json elements in a row or construct a JSON object containing others. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP
On 2018-05-25 09:13, Winfried Tilanus wrote: > Beside that informative XEP, I (or a group of people willing to do so) > publish an own document discussing XMPP & the GDPR in detail. Having XEPs explaining best practices for - retrieving all data belonging to one user - removing all data of a particular user - agreeing to terms of service and withdrawing again - etc. is certainly needed by many people in an outside the EU. It is not necessary to even mention GDPR in those XEPs. Informal documents (even blogs) could then link the XEPs to GDPR or other, similar laws. Just my 2€¢. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-13 13:05, W. Martin Borgert wrote: > I would prefer > > > ... > > > Everybody can just us the attribute or ignore it. ^e ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-13 12:38, Jonas Wielicki wrote: > On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote: > > > > > > This is an ephemeral message > > > > > > This is awful. It will require the message to carry a non-empty to > deal with the MAM/Carbons mess (and also to help users of clients which do > not > support this feature). I would prefer ... Everybody can just us the attribute or ignore it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
Quoting Alexander Krotov : Disappearing messages without end-to-end encryption and forward secrecy are useless at best. They give the user false sense of security. That is why Telegram implements timers for "secret" chats only I believe, as I said in the first message. I respectfully disagree. Timers (or "ephemeral messages") are not a security feature, but only a means of data hygiene. Therefore it is orthogonal to any encryption and it does also not matter, whether your peer or one of your peers devices or resources does implement the feature or not. No need to check. As sender, just use the timers and let the problem of deleting messages to the recipient. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-10 14:31, VanitasVitae wrote: > I'd also rather not tie it to OMEMO. The same principle of disappearing > messages could also be applied with other crypto in mind, or even no crypto > at all. Remember, this functionality is not designed to give you any > (serious) security improvements. Its rather a function which teenagers find > neat and which was implemented in Signal for some reason. D'accord with not coupling ephemeral messages to encryption. I would find it especially practical for unimportant messages with friends. We just don't want all the nonsense cluttering our archives. No need to check other sides client for that feature, of course. It's their problem if they really like to store the noise. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
Quoting Matthew Wild : The whole point of the autojoin logic was to keep clients synchronised. Either we want clients in sync or we don't. And I think we do. Sometimes yes, sometimes no. I would like to have some rooms autojoined when I'm at home, but not when at work. And vice versa. (I'm using different accounts for work and private stuff, but maybe not everyone uses multiple accounts.) Still, between the options "always synced" and "never synced", I prefer the former. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0394: too weak to replace XEP-0071
Quoting Jonas Wielicki : If you are doing graphics/text design/publishing with your IM client, you’re doing it wrong, in my opinion. But XMPP is not only IM. What about blogging or social networks like Movim or Salut à Toi or before Jappix, which present a rich web interface? No need for specific fonts or colours, I agree, but people want probably a little bit more output control then in the IM world. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
Quoting Kozlov Konstantin : The problem of XEP-0393 is that markup mixed with plain text and it's hard to purge it from it. That's why I prefer Markdown (or RST, it's almost the same): It is more or less readable as plain text to most of us. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
On 2018-03-15 10:22, Kozlov Konstantin wrote: > I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM > sounds bad. Flaws if it is obvious, so it's needless to mention them again. I disagree. Yes it is ugly, but having a widely used LML, such as Markdown (in contrast to some strange homebrew) in XMPP would be a pragmatic approach, IMVHO. Many people know Markdown syntax nowadays, there are parsers for it in many different programming languages, and we already know how ugly and illogical it is. Just needs a new XEP :~) > According to my UX, XEP-0071 functionality mostly used for: I agree with all your points. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [OT] Meetup in Berlin on Friday
On 2018-03-12 23:08, Holger Weiß wrote: > If you'd like to talk to us, you can join our MUC room: > > berlin-mee...@conference.conversations.im And we even have a pubsub node you can subscribe to: https://de.movim.eu/?node/pubsub.movim.eu/berlin-xmpp-meetup ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0283 Moved - Security and Usability
Quoting Georg Lukas : b) have a tool that will perform "account migration", i.e. you enter the credentials to your old account and to your new account and the tool will automatically move all your contacts from A to B. Only contacts or as much of personal data as possible? What about bookmarks? Or anything that is in PEP? That would be very useful. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities
Quoting Peter Saint-Andre : Well, it worked OK at small conferences when universal connectivity wasn't so common in the pre-smartphone days (folks had a lot of fun using it in Adium and iChat back then), but I haven't seen it used since 2010 or so. It went to Draft and Final quickly (perhaps we were more efficient about moving things forward back then), but it doesn't seem relevant anymore. I didn't use this feature for some years, but I can imagine, that it might be a relevant niche. Having a protocol that can survive certain desasters like "no mobile internet available" still sounds interesting and worthwhile to me. Might even be interesting in the field of humanitarian aid or when privacy is more relevant. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Jonas Wielicki : On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node We need to get this terminology straight. When you say "PubSub node", do you in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub service with JID X) or a PubSub service with JID X? I hope to get the terminology right this time: A PubSub node could have a "magic" item. A PubSub service could have a "magic" node. Does this make sense? For e.g. Movim both a logo for service and for a node seems to be useful. I think specifying avatars for each PubSub *node* could be tricky. For services (which I assume you meant) see below. If there were a "magic" item on a node, it never must be removed automatically, but only on user request, right? The "magic id" (again, only for PubSub services, not for individual nodes) is obvious, I’d simply use the same the XEP-0084 uses. That could even work magically with client code. Nice! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Daniel Gultsch : polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node, i.e. with the magic id "pubsub_logo". This node contains the logo, it can be upgraded and notification to users would be immediate. But a "magic id"? Like "favicon.ico"? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Timothée Jaussoin : In the end I don't think that it's a big issue to have those info requested manually, having a cache of a few hours on the clients is an OK solution for me at the moment. Maybe a refresh or poll rate of e.g. 12..24 hours can "officially" be suggested? Not really nice, but better than not having logos or invent something complicated that will never be implemented... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Adding logo to MUC and PubSub node
Hi, this is an idea mainly for the "social network" aspect of XMPP: A logo for a MUC or for a PubSub node, similar to a user avatar. Such a logo, emblem, or symbol can be a good indicator for users to find the right MUC or PubSub node in a social network application or graphical XMPP client. How about introducing two configuration variables, one in https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig: var='muc#muc_logo' And the second one in https://xmpp.org/extensions/xep-0060.html#owner-configure: var='pubsub#node_logo' The value should be a element from https://xmpp.org/extensions/xep-0221.html. IMHO, the value should be restricted to 1. images, or would a sound make sense? Maybe... 2. inline data, so that a link to a web resource cannot be abused for snitching IP addresses What do you think? TIA & Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
Quoting Goffi : Instead of blocking unconditionally unknown users (which is not an option for me), would not it make sense to use some kind of challenge (e.g. captcha or computational challenge) ? This would not block everything, but probably a good amount of SPAM/SPIM. For email, there is greylisting. IIRC, the receiving server says "try again later" on the first contact. This will be done by any legitimate server, but for spammers holding the message for e.g. one hour is too expensive. Any further messages will be delivered immediately. Neither sender nor receiver notice anything, only a one hour delay of the first message. In my experience, this method doesn't prevent all email spam, but a large part of it. Would this SMTP error 450/451 be applicable to XMPP? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 33C3 talk on Signal and current XMPP issue in providing a similar UX
On 2016-12-29 23:32, Tobias Markmann wrote:
> After
> registration, they need to easily/secure/privacy-enforcing fill up their
> roster with contacts based on known contact information like phone number
> or e-mail address.
I suggest to popularise the idea of identical email and XMPP
address. While this is, of course, optional, it makes contact
matching even more easy than with phone numbers.
As long as 98.7% of the planets email population happen to use
the same provider and this very provider dropped XMPP support,
it is, unfortunately, difficult to achieve.
Btw: You can reach me as {mailto,xmpp}:deba...@debian.org :~)
Btw': Thanks for your notes, Tobias!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] "Self-destruct" message timeout deletion hints
Quoting Dave Cridland : That's not the case in an open ecosystem - someone's client could just ignore the request, and might even have a setting to do so. It is very probable that many clients will offer this setting, so users will be rapidly aware of it - and that their peer has it, too! The question is: Should this be a "convenience" feature or a "security" feature. I see it as the former, and that way it is fine. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Easy XMPP
Pardon, this was meant to sent privately :~) Usability issue in Horde, I assume, or lack-of-brain problem between keyboard and chair. Here in English: Germany and probably other countries like to make anonymous SIMs illegal. Relying on phone numbers would make anonymous "Easy XMPP" illegal, too, which is probably not a goal. And: What is XEP-PARS? TIA! Quoting "W. Martin Borgert" : Hi, eine private Bemerkung und eine Frage: Quoting Georg Lukas : 2. Use of phone numbers: unfortunately this is an unsolved problem yet. Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch anderen Staaten) outlawed werden - egal wie erfolgversprechend man das einschätzt - wäre mit Telephonnummern als Id auch anonymes "Easy-XMPP" illegal. Das kann das Ziel nicht sein. - XEP-PARS: creation and full handling of links with preauth element Was ist das für ein XEP? Hast Du einen Link für mich? Danke! Cheers ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Easy XMPP
Hi, eine private Bemerkung und eine Frage: Quoting Georg Lukas : 2. Use of phone numbers: unfortunately this is an unsolved problem yet. Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch anderen Staaten) outlawed werden - egal wie erfolgversprechend man das einschätzt - wäre mit Telephonnummern als Id auch anonymes "Easy-XMPP" illegal. Das kann das Ziel nicht sein. - XEP-PARS: creation and full handling of links with preauth element Was ist das für ein XEP? Hast Du einen Link für mich? Danke! Cheers ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
