So, lest this discussion just die. Here is a proposal:
*
Client-A generates message-ID based on HASH(connection_counter,
server_salt). The connection_counter needs to be maintained only for
one connection. The server salt is server generated, anew for each
connection and is sent to.
*
Server-A checks that this is correct and uses it for MAM. This
should make life easier for clients because they only need to deal
with one ID.
* Two problems need to be considered here:
o The client needs to maintain a counter. I don't know if there
are cases where the client cannot persist this counter but keeps
a connection. In this case a sufficiently fine grained timestamp
to make it strictly monotonically increasing is suffcient. Even
though I called it a counter, it does not need to be contiguous.
It just needs to be increasing that the server can easily check
that for a given salt value it is unique.
o The server needs to check the validity of the counter. If the
server is actually replicated and consists of multiple machines
this is not strictly possible. However, assuming normal
operations the IDs generated by the client will be fine and if
the servers have any mechanism for eventual consistency a
misbehaving client will be detected. I think this fits the XMPP
model of "robust cooperation".
*
Server-B gets the message via s2s. It changes the message-ID to a
new one and stores the original as "origin-ID".
*
Client-B gets a message with only TWO IDs. message-ID is for
referencing locally for MAM, origin-ID is for referencing when
talking to the sender i.e. read receipts.
*
If a server generates follow-up messages it makes up a new
sender-ID. It should maybe set a “triggered-by-ID” so the client can
determine that it triggered this message. Maybe this is unnecessary.
The server definitely must send the message it inserted back to the
client to ensure a common view of history.
*
If a server changes a message it can keep the sender-ID but it MUST
notify the client who sent the message to make sure that clients
have the same view of the history.
In this proposal stanza-IDs are not required. The message-ID is
authoritative and when rewriting the original message-ID is kept as
origin-ID.
From my original mail this solves C1, C2, C3, C4 and C5. Mostly just by
defining them. This does not give us a global message-ID (C6) or
unforgeable message-IDs (C7).
Note, that I would prefer to have a globally unique ID. This is possible
under the assumption that everybody tries to generate unique IDs and
that non-unique IDs and misbehaving parties can be removed from the
system. Essentially, it would look just like this except that the
message-ID would have to include an ID for the originating server. That
would allow recipients to check that connection_counter is increasing
and the server_salt is unique for this server. The latter check might be
hard to perform, though. It can still be solved using timestamps. This
proposal seems much simpler, and it solves most of the problems.
Also note, to make this a simpler change the clients could set both
origin-ID and message-ID. The stanza-ID for MAM would turn out to be the
same. This would be very similar to what is probably currently the most
widespread behavior. Except that the origin-ID should be used for
read-receipts, etc.
Opinions?
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
