Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for forwarded messages #16

Open
Kaffeine opened this issue Feb 13, 2017 · 2 comments
Open

Add support for forwarded messages #16

Kaffeine opened this issue Feb 13, 2017 · 2 comments

Comments

@Kaffeine
Copy link
Member

Kaffeine commented Feb 13, 2017

Add a new message header keys:

  • forward-from (u - Contact_Handle) The contact who sent the original message. If 0 or omitted, the contact who sent the message could not be determined.
  • forward-from-id (s) The identifier of the contact who sent the original message, i.e. the result of calling InspectHandles on forward-from. If omitted, clients MUST fall back to looking at forward-from.
  • forward-sent-timestamp (x - Unix_Timestamp64) The time the original message was sent.
  • forward-received-timestamp (x - Unix_Timestamp64) The time the original message was received.

Maybe some protocols provide information about the original channel. E.g.: Message "Hello" is forwarded from Juliet in the public chat "Montecchi's veranda", but IMO it is OK to miss such capability for now. :)

Extra keys:

  • forward-message-token (s) An opaque identifier of the original message, as used by the underlying protocol.
@Kaffeine Kaffeine changed the title Implement support for forwarded messages Add support for forwarded messages Feb 13, 2017
@Kaffeine Kaffeine changed the title Add support for forwarded messages Add a spec for forwarded messages Feb 13, 2017
@Kaffeine Kaffeine changed the title Add a spec for forwarded messages Add support for forwarded messages Feb 13, 2017
@Kaffeine
Copy link
Member Author

Kaffeine commented May 8, 2018

The second option — introduce a new channel iface ofdT.Channel.Interface.Forwarding and use a new message part similar to the header part.

{ # Header
  'message-token': '3ea270cb834c',
  'message-sender': 42,
  'message-sent': 1210067943,
  'message-received': 1210067947,
  'message-type': 0,  # = Channel_Text_Message_Type_Normal
},
{ # Forward header
  'interface': 'ofdT.Channel.Interface.Forwarding'
  'message-token': 'asd234lzxc91s',
  'message-sender': 68, # The contact who sent the original message
  'message-source-id': muc12345, # The original conversation
  'message-source-type': Tp::HandleTypeRoom,
  'message-sent': 1210067243,
  'message-received': 1210067910,
  'message-sender-alias': 'Juliet'
},
{ # Body/other parts
  ...
}

The presence of the interface on a channel will also indicate the 'Message Forwarding' support.

In order to forward a message, a client should specify three values: message-token, message-source/message-source-id and message-source-type. The Connection Manager is expected to take care on all other keys (that should be presented in the MessageSent signal)

@gkiagia
Copy link
Member

gkiagia commented Jun 25, 2018

I prefer the interface approach, it looks more clean and it's also detectable if support for this exists. The headers that you propose seem reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants