17 Oct
2024
17 Oct
'24
1:02 a.m.
This message constitutes notice of a Last Call for comments on
XEP-0490.
Title: Message Displayed Synchronization
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
URL: https://xmpp.org/extensions/xep-0490.html
This Last Call begins today and shall end at the close of business on
2024-10-31.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
30 Oct
30 Oct
2:24 a.m.
Hello standards@,
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes, definitely. As a user of multiple
devices, I very much appreciate
the feature. As an XMPP evangelist, I have had feedback from new users
about "read state not working in public channels". As a developer of
gateways, I am happy that XMPP clients can be on par with a feature that
most other chat apps provide.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes, I have developed a draft for this feature in gajim. Because of the
way read state works in gajim, it is suboptimal and hasn't been merged
in the master branch. I do, however, use it anyway.
I also have developed the feature in slidge gateways. Because it is
pubsub-based, it requires the gateway to be a XEP-0356 privileged
entity, specifically requiring "IQ privilege" for the pubsub node.
4. Do you have any security concerns related to this
specification?
No, but security definitely isn't my area of expertise.
5. Is the specification accurate and clearly written?
Yes. It is always a bit confusing to know what "message ID" one has to
use, but this is not specific to this specification. It all makes sense
once you are used to it, but the complexity of knowing what message
identifier one has to use can be discouraging for new XMPP devs.
Long live MDS! MDS everywhere!
--
nicoco
8:33 a.m.
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes, I have done so in the Snikket SDK.
4. Do you have any security concerns related to this
specification?
No.
5. Is the specification accurate and clearly written?
Yes
1:04 p.m.
Hello,
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes.
4. Do you have any security concerns related to this specification?
No.
5. Is the specification accurate and clearly written?
Yes
Regards
Philipp
18
days inactive
31
days old
3 comments
4 participants
participants (4)
-
Daniel Gultsch -
Nicolas Cedilnik -
Philipp Hörist -
Stephen Paul Weber