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