Version 0.1.0 of XEP-0490 (Message Displayed Synchronization) has been
released.
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
Changelog:
* Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-04
I very much think we should stop the trend of adding other comments in
the title. This is better than a funny joke, but it's still something
that's going to show up in citations. Let's just stick "note that this
was previously known as Chat Markers" in the introduction somewhere and
call it goo
We use Chat Markers extensively. For what it's worth, I think that it was a
bad idea to remove to not replicate XEP-0184, because reading
one spec is better for developers than reading two, and I'd rather revert
changes back to 0.4 and deprecated 0184 instead.
Also, Displayed Markers (was: Chat M
Hi Sam and Andrew,
I agree on the name. I felt like it was important that for the first
major update after 7 years and for the last call notification people
know what XEP we are talking about. However I will change the name
either on the move to stable or on the next update (which ever happens
fir
I entirely missed this, and have no understanding of the rationale, but:
1) I'm somewhat ambivalent about removing , but it's certainly
well implemented by my anecdotological studies.
2) Removing seems OK, but I've considered various use-cases
for which an explicit, user-driven, acknowledgement i
As I said earlier, some day down the road can actually be
useful:
> But I could see this feature useful for something like voice/video
messages to indicate that it has been played by the recipient. At least,
Telegram does have such feature (not in group chats though, there it makes
no sense and w
On Tue, Mar 26, 2024 at 1:11 PM Dave Cridland wrote:
> 3) It's really not. Some clients and intermediaries need to know whether they
> should expect a marker or not. No need to check this prior to sending a
> , true, but useful to track missing markers afterward.
>
> Where was the discussion of
Well, on the other hand, since the only scenario I can imagine using
in the wild has significantly different semantics from
readdisplayed
markers, I think that this is not really necessary in this XEP.
On Tue, 26 Mar 2024 at 17:34, Daniel Gultsch wrote:
> On Tue, Mar 26, 2024 at 1:11 PM Dave Cr
On Tue, Mar 26, 2024 at 1:40 PM Andrew Nenakhov
wrote:
>
> Well, on the other hand, since the only scenario I can imagine using
> in the wild has significantly different semantics from
> readdisplayed markers, I think that this is not really necessary in this XEP.
The part I was considering br
XEP-0392 (Consistent Color Generation) has just been moved to stable
by Council. The Editor will act on that later today.
However council strongly believes that the feedback provided by
Stephen Paul Weber should be addressed with the following two action
items:
- make HSLuv a SHOULD, explain that
Version 0.2 of XEP-0360 (Nonzas (are not Stanzas)) has been released.
Abstract:
This specification defines the term "Nonza", describing every top
level stream element that is not a Stanza.
Changelog:
Defer due to lack of activity. (XEP Editor (jwi))
URL: https://xmpp.org/extensions/xep-0360.html
Version 1.0.0 of XEP-0392 (Consistent Color Generation) has been
released.
Abstract:
This specification provides a set of algorithms to consistently
generate colors given a string. The string can be a nickname, a JID or
any other piece of information. All entities adhering to this
specification ge
12 matches
Mail list logo
