Skip to content

New ProtoXEP: No-reply JIDs #1469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
iNPUTmice merged 1 commit into from
Oct 14, 2025
Merged

New ProtoXEP: No-reply JIDs #1469

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 108 additions & 0 deletions inbox/no-reply-jids.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep><header>
<title>No-reply JIDs</title>
<abstract>This specification defines a way for JIDs to advertise that they don’t accept incoming chat messages.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>no-reply</shortname>
<author>
<firstname>Matthew</firstname>
<surname>Wild</surname>
<email>mwild1@gmail.com</email>
</author>
<revision>
<version>0.0.1</version>
<date>2025-10-08</date>
<initials>mw</initials>
<remark>
<p>Initial submission.</p>
</remark>
</revision>
</header>
<section1 topic="Introduction" anchor="intro">

<p>This protocol defines a way for a JID to advertise that it does not accept incoming chat messages. For example, automated services which broadcast messages.</p>

<p>Such an indication allows clients to adapt their user interface accordingly (for example, hiding message input controls), instead of allowing the user to send a message and receive errors. This can improve the user experience and avoid confusion.</p>

</section1><section1 topic="Requirements" anchor="reqs">

<ul>
<li>The protocol should not require clients to perform additional queries.</li>
</ul>

</section1><section1 topic="Use Cases" anchor="usecases">

<p>One example use case for this protocol, would be a server which sends welcome messages or other announcements (maintenance, etc.) to its users from its own JID (e.g. 'example.com').</p>

<p>To show that users should not reply to messages sent from this JID, the server advertises <tt>urn:xmpp:noreply:0</tt> in the &xep0030; features of that JID (i.e. 'example.com') to indicate this to the clients.</p>

<p>In most cases it is expected that the recipient will learn of the feature using &xep0115; rather than performing service discovery just to learn of the no-reply feature. In the case of a server’s JID, the entity capabilities are typically communicated to the client in the initial stream features.</p>

</section1><section1 topic="Business Rules" anchor="business-rules">

<p>Any entity which does not accept chat messages should advertise the service discovery feature:</p>

<ul>
<li><tt>urn:xmpp:noreply:0</tt></li>
</ul>

<p>In the case that a full JID advertises the no-reply feature, and there are other resources of the same JID which do not advertise the feature, a client SHOULD NOT prevent the user from sending messages (e.g. to other resources or to the bare JID).</p>

<p>Advertising the no-reply feature indicates that a JID does not accept messages. If a JID does accept messages, even if it sometimes sends automated messages, it MUST NOT advertise this feature.</p>

<p>If a JID advertises the feature and receives an incoming message anyway (e.g. from a sender that does not support this XEP) then it SHOULD respond with an error, per the usual processing rules of &rfc6120;.</p>

<p>The no-reply feature pertains only to chat messages, such as those typically originated from humans. A JID which advertises this feature MAY accept other kinds of messages (for example, a news bot which advertises this feature would still be expected to receive pubsub notifications even though they are conveyed as messages).</p>

</section1><section1 topic="Accessibility Considerations" anchor="access">

<p>There are no known special accessibility considerations for this protocol.</p>

<p>It is expected that it may improve accessibility by simplifying interfaces where possible.</p>

</section1><section1 topic="Security Considerations" anchor="security">

<p>There are no known security considerations for this protocol, beyond those existing in normal service discovery flows.</p>

</section1><section1 topic="Privacy Considerations" anchor="privacy">

<p>There are no known privacy considerations for this protocol.</p>

</section1><section1 topic="IANA Considerations" anchor="iana">

<p>This protocol does not require any interaction with IANA.</p>

</section1><section1 topic="XMPP Registrar Considerations" anchor="registrar">

<p>This document registers the following service discovery feature:</p>

<ul>
<li><tt>urn:xmpp:noreply:0</tt></li>
</ul>

</section1><section1 topic="Design Considerations" anchor="design">

<p>It was debated whether to include the no-reply indication on a per JID, presence or message basis. As most chat clients show an interface featuring an input control per remote JID, and due to the potential optimization afforded by XEP-0115, it was decided to use service discovery.</p>

</section1><section1 topic="XML Schema" anchor="schema">

<p>This document defines no new XML elements or attributes.</p>
</section1>
</xep>