I've been trying to work on Ephemeral Messages (XEP-0466) again, and I
still can't figure out remaining TODOs.

These are my changes on top of the current state of the spec, but
they're here just for information, they don't contain anything related
to this question.
https://github.com/Ppjet6/xeps/commits/0466-todo
https://bouah.net/specs/ephemeral.html (commit 08c9b46)


So, opt-in/opt-out with messages. This issue has been bugging me for a
while. I think this is a pretty generic problem to solve has isn't
proper to this protocol.

I'd like that we don't get hanged up on the specifics of the protocol
here, which is generally what has been happening and never really been
helpful (often derogatory), unless of course it becomes necessary
because of specific constraints that it imposes.

I'm sorry this isn't very clear to me how to formulate all this, and it
shows in the mail.

I think I'm having conceptual issues with implementing clients possibly
missing messages (MAM expiry too short, etc.), but also non-implementing
clients.

Also the fact that I can't know if a client implements the protocol as a
sending client some of the time, because of being in MUC of missing a
directed presence.


The protocol is currently defined to only use messages. It's also not
possible in the protocol to have asymmetrical behavior. (I'm not dead
set on this, but this is a different question I think)


Opt-in seems to be easy, include the tag when sending messages, and
receiving clients will start picking it up as soon as they see it (live,
or MAM).

I currently mandate that receiving clients reply including this element
if they wish to opt-in themselves.

Some time passes, all clients included in the chat are sending the
element, now I want to opt-out. Do I need to start including an
<opt-out/> element indefinitely until all clients pick it up?

And when we think we're finally done (that all clients have seen it),
one client starts being used again after weeks and sends the element
again, goto 1.

This (<opt-out/>) is obviously not a solution?

Maybe the issue is that I don't specify anything if receiving clients
don't include the element. The issue here is that I can't mandate that
when a receiving client doesn't include the tag, the sending client
stops including it, because of non-implementing clients (and because I
can't know if it's a non-implementing client or not in some context).


Thoughts? Will this just "not work"? Are they any other similar
protocols? Should I give up using only messages and combine this with
something else?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to