[Standards] Re: Council (and what it does, and what it should do)

Quoting Goffi : For the record, we'll have a meeting in Berlin next month (thanks to Debacle), to work exactly on that: interoperability issue with OMEMO (and A/V). I like to add: It is an open sprint, so everybody is invited to work on whatever they like :-) Please, everyone, register

[Standards] Re: XEP-0440 and tls-server-end-point

` when it's the only method offered. As Holger and Andrzej pointed out there might be cases where the better methods are not available and using a weaker one is still better than no channel binding at all. Best regards, Martin signature.asc Description: PGP signature

[Standards] Signing PubSub items (Proposed XMPP Extension: OpenPGP for XMPP Pubsub)

> Title: OpenPGP for XMPP Pubsub [...] > Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use > case. > > URL: https://xmpp.org/extensions/inbox/pubsub-encryption.html I hoped that the XEP would provide a way to sign blog posts or other data, but it does not, at least not

Re: [Standards] Clarify meaning of pubsub#item_expire: creation or modification?

On 2021-09-17 13:22, goffi wrote: > there is no notion of "modification" in XEP-0060: an item with an > existing ID is overwritten by a new item with same ID, not > modified. The notion of modification has been introduced in XEP-0413 > (Order-By) that I've authored, because it's useful, but it's

[Standards] Clarify meaning of pubsub#item_expire: creation or modification?

ublisher should remove the node when time comes. In any case, the standard should clear about what is intended. Patch attached. Cheers, Martin diff --git a/xep-0060.xml b/xep-0060.xml index 09638a6b..d5ea9ce7 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -3569,7 +3569,7 @@ And by opposing end them

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

Quoting Kim Alvefur : We were always at war with STARTTLS? The world is at war with both ports < 443 and ports > 443. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] XEP Modernization Roundtable Results

On 2021-06-22 16:51, Sam Whited wrote: > * XEP-0138: Stream Compression, XEP-0229: Stream Compression with LZW > * MattJ: everyone is streaming video on mobile devices so XML > is not a big > resource hog that we need to worry about anymore XML compression is probably not

Re: [Standards] Announcing Slummit 2021

-Streaming and a MUC. Best regards, Martin signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] LAST CALL: XEP-0381 (Internet of Things Special Interest Group (IoT SIG))

On 2020-12-01 18:37, Jonas Schäfer wrote: > 1) Do you think that the SIG is a good addition to the XMPP Community? If so, > why? If not, why not? As a user of XMPP in IoT, I'm happy about a SIG working on the relevant XEPs. And I'm thankful to flow and MattJ for managing

Re: [Standards] LAST CALL: XEP-0443 (XMPP Compliance Suites 2021)

Dear all, I would like to also have XEP-0425: Message Moderation [1] added to the XMPP Compliance Suites 2021 as spam messages to MUCs are happening more often. Would you consider adding it to advanced client and advanced server? Best regards, Martin [1] https://xmpp.org/extensions/xep

Re: [Standards] XEP-0060: max #max_items

Quoting Tedd Sterr : Alternatively, I presume 31 bits would be a safe* maximum positive integer value (max='2147483647'). * Limits are 'bad,' but I don't see anyone realistically needing 2 billion entries, nor a server storing them. Maybe in IoT use cases (sensor data) this limit can be

Re: [Standards] Call for Experience: XEP-0198: Stream Management

On 2020-02-21 09:23, Daniel Gultsch wrote: > Only someone who hasn't been on a German high speed train can say with > confidence that desktop and web clients don't need stream management. Yes, mobile ≠ Android/iOS! Many notebook computers are connected to Wifi or "mobile internet" and used in

Re: [Standards] Proposed XMPP Extension: Simple JSON Messaging

On 2020-02-19 00:33, Dave Cridland wrote: > It is normal, outside this group. That train has left the station, and > there is little point in closing the stable door after the ship has sailed. Correction: "The train has left the bike shed". (Back to work, where we start to use XEP-0335: JSON

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

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.

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

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

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

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

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

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/mailm

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

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

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

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

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

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

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

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

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

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

Re: [Standards] Adding logo to MUC and PubSub node

Quoting Jonas Wielicki <jo...@wielicki.name>: 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

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

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

[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.

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

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.

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

Re: [Standards] Easy XMPP

legal, too, which is probably not a goal. And: What is XEP-PARS? TIA! Quoting "W. Martin Borgert" <deba...@debian.org>: Hi, eine private Bemerkung und eine Frage: Quoting Georg Lukas <ge...@op-co.de>: 2. Use of phone numbers: unfortunately this is an unsolved problem

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

Re: [Standards] XEP-0115 Entity Capabilities - clarifications

Alban Crequy wrote: Le Sun, 15 Aug 2010 23:05:49 +0100, Martin Morrison martin.morri...@gmail.com a écrit : I've recently been implementing XEP-0115 Entity Capabilities, both the latest and the legacy versions, and have a few issues that I feel should be clarified in the latest version

[Standards] XEP-0115 Entity Capabilities - clarifications

' attribute completely and just return his current capabilities (which will be accepted, since he will already have pushed an updated hash via Presence)? Either way, I think it would help if the spec specified what was expected. Cheers, Martin