Hi standards,
With edhelas we've been looking at changing XEP-0413: Order-By a bit,
for it to be allowed in disco#items requests.
Order-By is currently mostly used with PubSub (if it is implemented at
all). That is, a PubSub service would advertize it in disco#info, thus
meaning that it's possibl
> On 1 Aug 2019, at 19:42, Ненахов Андрей
> wrote:
>
> I imagine that a proper solution to this problem might be something
> like... reactions? If we do reactions with some kind of attached
> message, errors might be a special kind of attachments. Thinking
> further, I like it even more: react
Our reliable message delivery protocol that we use to replace stream
management makes half of message errors mostly unnecessary: we
consider that message is delivered to server only when we receive
confirmation with server ID and timestamp assigned to this message. If
you don't have server ID, you
On Samstag, 27. Juli 2019 17:44:37 CEST Emmanuel Gil Peyrot wrote:
> Hello,
>
> During the last sprint in Lyon[1] we worked on finishing the DOAP
> proposal I sent to this list two years ago[2].
I think what this email could use to be more easy to understand and reason
about is a short summary w
On Donnerstag, 1. August 2019 13:08:49 CEST Georg Lukas wrote:
> Obviously, this should only happen for direct messages and PMs, not for
> type=groupchat ones.
Should this have been directly below point 4? Otherwise I’m not sure how to
interpret type=groupchat in the context of error messages.
I
Hi,
I think there's an extra `sid` attribute in example 9 of XEP-0260
"Responder activates the bytestream at proxy",
https://xmpp.org/extensions/xep-0260.html#example-9:
ro...@montague.lit/orchard
I think it can simply be removed.
In the description of the elemen
Hi,
error type stanzas are currently ephemeral, and not taken seriously by
many (client) developers. As one step in increasing the (perceived)
reliability of XMPP messaging, I'd like to make message errors
persistent, so that users can better gauge which of their messages
actually arrived at the r