- Standards

Study/Paper about Community Moderation under XMPP

by email＠msavoritias.me

Hey o/ I am currently writing a paper around Community Moderation/Safety in XMPP and what we can do to improve the situation. paper is here -> https://git.sr.ht/~msavoritias/Guile_XMPP/tree/main/item/Documentation/Pape… Its written because I am developing an XMPP library in the same repo and I want to implement good Community Moderation at some point. (Community Moderation in the sense of both server level and group chat level.) The situation currently is less than adequate in xmpp both on protocol and client level. We are lagging behind other communities like activitypub in many ways. And more importantly we are falling short of what should be done beyond what activitypub is doing. The aim is to have some actionable points in the end to move the situation forward. Either with XEPs or suggestions for clients implementations like modernxmpp does. Most likely its going to be both. Would the XSF be willing to fund me to write this paper or help me find funding? MSavoritias

2 months, 2 weeks

1
0
0 0

Accepted XEP-xxxx MUC Avatars into historical track

by Daniel Gultsch

Dear Editor, please note that council has accepted the proposed XEP 'MUC Avatars' into the historical track. (A previous submission into standards track has been rejected by the council at that time) https://xmpp.org/extensions/inbox/muc-avatars.html cheers Daniel

2 months, 2 weeks

1
0
0 0

Feedback requested: SVCB for XMPP

by Dave Cridland

Hi all, Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP. Assuming attachments work on this list! Feedback welcome, I intend to submit this one shortly to the IETF. Dave.

2 months, 3 weeks

4
7
0 0

Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by kevin.smith＠isode.com

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Host Meta 2 - One Method To Rule Them All Abstract: This document defines an XMPP Extension Protocol for extending XEP-0156 by modifying the JSON Web Host Metadata Link format to support discovering all possible XMPP connection methods, for c2s and s2s URL: https://xmpp.org/extensions/inbox/host-meta-2.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 months, 3 weeks

4
5
0 0

Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by Travis Burtrum

Hi Fannys! On 12/16/23 04:06, Fannys wrote: > As I said in the @xsf room the problem with this XEP is that the author > is convinced that this is the one answer to everything and assumes a > *lot* of stuff to get there. And besides the title obviously that is > obvious in a few other places. To try to quickly summarize, we need a lot of info to connect to XMPP servers, and need to get it in very specific (secure) ways. I've thought about this a lot over the years, and (very much thanks to your and other's feedback) tried to explain the reason for every decision. I am absolutely not married to one solution, but alternatives need to accomplish the same goals. "I don't like this" isn't helpful without an alternative proposal that can actually be considered. > Specifically: > > > - It calls SRV records as legacy which is a pretty big departure from > the status quo. > > > For the foreseeable future you will need to maintain legacy SRV > records in addition to this file Yes, because this document explicitly deprecates SRV records (while saying they need to be supported for the forseeable future). > - It effectively makes HTTP a hard requirement for all clients and > servers on the network raising complexity significantly. HTTPS already is a hard requirement, with POSH, with HTTP Upload which is currently the only way to share files in MUCs and with multiple clients / offline clients, and, for most servers, the way they get certificates from letsencrypt. HTTPS is also a well established, fully open protocol with many independent implementations exactly like XMPP, I see no reason to avoid it. XMPP relies on many other standards, just as good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc. > - Recommends that everything runs through port 443 which is in itself > questionable for this. Because it's most likely to work through real-world firewalls in real-world networks, what's questionable about this? > - Also it introduces a hard requirement for a JSON parser in all clients > and servers which is another point that raises complexity. Again, a JSON parser is already a hard requirement due to POSH. I addressed further reasons I thought this was the best choice in the Rationale https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , but, this is not an absolute hill for me to die on. If the consensus is that XML is better here, I'm not opposed, but then it should be the XMPP-subset of XML so that we can actually use the same parser, and don't introduce the real security risk of requiring an XML parser that can parse not-XMPP-XML (just one real world example of this vulnerability in the wild is https://prosody.im/security/advisory_20220113/ ). Please note this would introduce the following (imho, downsides): 1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML parser supporting comments etc etc 2. that means an extra https request when trying to fetch host-meta-2 along with legacy methods 3. so it'd require a new document definition, for a quick reference, it would look very similar to HACX https://xmpp.org/extensions/inbox/hacx.html#example-1 > And I think the discussion about these items individually should have > happened before. Especially since from the discussion in @xsf it seems > that some of the alternatives like DNS were rejected on subjective > opinions of the author. I actually discussed this in xsf@ 21 months!!!! (damn I'm slow...) before submitting this ProtoXEP https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9 I hopefully explained my rationale re: DNS well https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but please if you disagree and/or have alternatives do share. > My opinion is that HTTP and JSON shouldn't be requirements and i don't > plan to use this XEP anywhere even if it gets voted in. We already have > problems with ports and everything assuming HTTP and I don't want the > problem to be worse. Plus I don't want the complexity at all. So to summarize my current thoughts: * I think HTTPS is likely to be a hard requirement for this, at least I can't think of an alternative that can accomplish the same goals * JSON is *not* a hard requirement, and could be replaced, but has the downsides I layed out above and in the rationale > Fannys I very much appreciate the detailed feedback, thank you!

2 months, 3 weeks

1
0
0 0

XMPP Council Agenda 2024-02-13

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, February 13 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update 4) Items for voting a) xep-template: Require accessibility and privacy sections https://github.com/xsf/xeps/pull/1322 b) Issue Last Call on XEP-0360: Nonzas (are not Stanzas) https://xmpp.org/extensions/xep-0360.html c) Proto XEP: XEP-xxxx: MUC Avatars https://xmpp.org/extensions/inbox/muc-avatars.html 5) Pending votes - Dan on starting Start Last Call on XEP-0392: Consistent Color Generation See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 months, 3 weeks

1
0
0 0

XEP-0440 and tls-server-end-point

by Simon Josefsson

Hi I was reading XEP-0440 and noticed that since 2022-08 it requires support for tls-server-end-point channel bindings. I believe this is unfortunate because tls-server-end-point channel binding are worse than either of tls-unique or tls-exporter. Mandating support for this weak channel binding will detract from efforts to implement the stronger tls-unique and tls-exporter. When deciding what to prioritize, it may be that someone believes that since XEP-0440 requires tls-server-end-point, it is more important to implement it than spend time getting tls-exporter implemented. That would be a bad outcome. I suggest changing XEP-0440 to require tls-unique when TLS <= 1.2 is used and tls-exporter when TLS >= 1.3 is used. If you have already given up on supporting TLS <= 1.2 I think you should only mandate tls-exporter as this is the best available channel binding available. I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter. /Simon

3 months

8
11
0 0

Proposed XMPP Extension: PubSub Server Information

by kevin.smith＠isode.com

The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Server Information Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 months

2
1
0 0

Escape characters in XEP-0393: Message Styling

by Werner Kroneman

Hello, first of all, this is my first attempted contribution to an Internet standard, so I do apologize if the form is a bit off. That said, I was implementing a parser for "XEP-0393: Message Styling", and I ran into the issue that not much is defined in the way of escape characters. In Gajim, for instance, the sequence *hello* becomes bold, the sequence \*hello* does not, but the sequence \\*hello* also does not. In many applications, preceding a \ with another \ escapes the latter \, making it so that the escape character itself is escaped, and therefore the * that creates the emphasis span would not be. However, the standard does not mention any rule regarding this (and Gajim does not do what I expect), so it is perhaps a good idea to add a note about this before making it final. Kind regards, Werner

3 months, 2 weeks

2
1
0 0

UPDATED: XEP-0483 (HTTP Online Meetings)

by kevin.smith＠isode.com

Version 0.2.0 of XEP-0483 (HTTP Online Meetings) has been released. Abstract: This specification defines a protocol extension to request URLs from an external HTTP entity usable to initiate and invite participants to an online meeting. Changelog: * Use XEP-0482 to send the meeting link to another party (do) URL: https://xmpp.org/extensions/xep-0483.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.

3 months, 2 weeks

1
0
0 0

2024

2023

Standards ----- 2024 ----- May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards