In Bug #26785 I wrote, in reply to Cosimo: > > From this point of view, TP should create its own unique token or give the > > possibility to clients to obtain a trustable and unique token, even if its > > uniqueness is only local to TP (ie not passed by the protocol). > > What you ideally want for a database is a token that maps 1:1 to an abstract > message (the "message-token" header in telepathy-spec), but unfortunately > that's not possible in most protocols. The best we can do is a token such that > each token uniquely identifies one abstract message, but each abstract message > might have more than one such token. I can't think of a good name for that > right now; can you? > > Ways the CM could achieve that "next best thing" include: > > * put a token with those semantics on each message (i.e. generate a large > number of UUIDs) > > * put a different UUID on each Channel instance, so that the tuple (channel > UUID, pending message ID) is unique over time
I have two alternative proposals to solve this. ConversationID ============== Stamp each channel with a UUID, like this: http://people.freedesktop.org/~smcv/telepathy-spec-conversation_token/spec/Channel_Future.html#org.freedesktop.Telepathy.Channel.FUTURE.ConversationID http://people.freedesktop.org/~smcv/telepathy-spec-conversation_token/spec/Channel_Type_Text.html#Message_ID local-token =========== Stamp each message with a UUID, like this: http://people.freedesktop.org/~smcv/telepathy-spec-local_token/spec/Channel_Interface_Messages.html#Local_Message_Token
We already have at least 3 different message identifiers, depending on how you count: • PendingMessageID; • message-token; • protocol-token (which has literally never been implemented anywhere at all); • stored-message-token (on StoredMessages); • I'm sure I thought of a fifth one last time I enumerated them. Please can we not add yet another one? As far as I can tell, local-token doesn't actually give us any more useful information. The logger still has to use a heuristic to de-duplicate MUC scrollback, because Gabble can't give those messages the same UUID. The logger doesn't have to de-duplicate rescued messages, because it can just ignore those. The only thing that seems worth doing is providing whatever token the protocol *does* use so that the logger can use it as input for its heuristic. So I propose: • Delete protocol-token from the spec; • Respecify message-token to be whatever the protocol uses as an identifier, if any, which may or may not be globally unique; • Revert Gabble to what it did before, using the id='' attribute for message-token; • Put big flashing warnings on message-token to say there are no guarantees of uniqueness, it's literally for information only, it MAY be different if the message is different but it also MAY NOT, but if the token *is* different then the message *is* different (which is better than nothing); • Tell people who try to implement stateless deduplication algorithms that it's impossible — because, FACT, it is impossible to globally identify messages on IM statelessly — and to use their logger (or preferably just use tpl and implement deduplication once there). We can fix up StoredMessages to only use this token. And then we're down to two identifiers for a message, and the difference between them is reasonably easy to describe, and we don't claim to be providing something we can't provide.
Here is my counter-proposal: http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=commitdiff;h=refs/heads/tokens Here it is in HTML form: http://people.freedesktop.org/~wjt/telepathy-spec-tokens/spec/Channel_Interface_Messages.html#Message_Header_Key Here is the Gabble branch reverting it to its former behaviour: http://git.collabora.co.uk/?p=user/wjt/telepathy-gabble-wjt.git;a=commitdiff;h=refs/heads/message-token
(In reply to comment #2) > • Delete protocol-token from the spec; > • Respecify message-token to be whatever the protocol uses as an identifier, if > any, which may or may not be globally unique; This breaks any client that assumes message-token has its (impossible) specified semantics, which if I remember correctly includes Maemo 5's rtcom-eventlogger; the ability to backport CMs onto Maemo has been rather popular, so this seems a bad idea. I'd be in favour of getting rid of message-token from the list entirely, though, replacing it with something like this at the end of the list of keys: The key "message-token" is reserved and should not be used.
(In reply to comment #2) > Please can we not add yet another one? As far as I can tell, local-token > doesn't actually give us any more useful information. The logger still has to > use a heuristic to de-duplicate MUC scrollback, because Gabble can't give those > messages the same UUID. The logger doesn't have to de-duplicate rescued > messages, because it can just ignore those. Agreed, I don't really see the point to add it as it seems to not buy us anything.
(In reply to comment #4) > (In reply to comment #2) > > • Delete protocol-token from the spec; > > • Respecify message-token to be whatever the protocol uses as an identifier, if > > any, which may or may not be globally unique; > > This breaks any client that assumes message-token has its (impossible) > specified semantics, which if I remember correctly includes Maemo 5's > rtcom-eventlogger; the ability to backport CMs onto Maemo has been rather > popular, so this seems a bad idea. I'd be in favour of getting rid of > message-token from the list entirely, though, replacing it with something like > this at the end of the list of keys: > > The key "message-token" is reserved and should not be used. So the options are: • rename message-token, and run around changing every CM and every UI, and have clutter in the spec; • don't rename it, hacking CMs that are backported to Maemo 5 very slightly.
(In reply to comment #4) > This breaks any client that assumes message-token has its (impossible) > specified semantics, which if I remember correctly includes Maemo 5's > rtcom-eventlogger; the ability to backport CMs onto Maemo has been rather > popular, so this seems a bad idea. Now that more time has passed and most CMs have requirements that are unsatisfiable in Maemo 5 anyway, I retract this objection, and have cherry-picked your patch to my messages branch.
Sorry, forgot to mention: I'm going to try to round up low-handing Messages changes there, so more patches will follow; if you review this, please say "reviewed up to and including 12345abcde" or similar.
Repurposing this bug for general Messages cleanup.
*** Bug 31170 has been marked as a duplicate of this bug. ***
*** Bug 29376 has been marked as a duplicate of this bug. ***
*** Bug 29560 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 31170 has been marked as a duplicate of this bug. *** OK with regards to the documentation on the "content-type" body key.
message-sender-id: I like the idea but doesn't "if omitted, the contact who sent the message could not be determined" break backward compatibility ?
Sorry, I should have linked to the full branch for review: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/messages HTML for the affected interfaces: http://people.freedesktop.org/~smcv/telepathy-spec-messages/spec/Channel_Type_Text.html http://people.freedesktop.org/~smcv/telepathy-spec-messages/spec/Channel_Interface_Messages.html (In reply to comment #14) > message-sender-id: I like the idea but doesn't "if omitted, the contact who > sent the message could not be determined" break backward compatibility ? Oops, yes; fixed in 3a723af.
*** Bug 29474 has been marked as a duplicate of this bug. ***
++
Fixed in git for 0.21.5
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.