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

[feature request] Have a 'message sent' timestamp #428

Open
yurivict opened this issue Jan 13, 2017 · 7 comments
Open

[feature request] Have a 'message sent' timestamp #428

yurivict opened this issue Jan 13, 2017 · 7 comments
Labels
enhancement New feature for the user, not a new feature for build script P2 Medium priority
Milestone

Comments

@yurivict
Copy link
Member

yurivict commented Jan 13, 2017

Currently offline messages are displayed with the timestamp of arrival.
It is important for both sender and receiver to know both when the message was created and sent.

Please add the timestamp for 'send' event (when the user hits the 'send' button), and communicate it to the recipient, so that the recipient can see both times.

References:

@iphydf iphydf added the P2 Medium priority label Jan 13, 2017
@iphydf
Copy link
Member

iphydf commented Jan 13, 2017

Yes, I suggested this 2 years ago. Thanks for the issue. We'll implement it in the new protocol. Right now, it would break the application level protocol, so we'll hold off on it. This feature will be part of the new application level protocol design.

@aaannndddyyy
Copy link

+1

@isotoxin
Copy link

isotoxin commented Mar 9, 2017

Isotoxin has long able to send message create timestamp.
Due to inflexible architecture of tox protocol it is impossible to implement it without break compatibility. Isotoxin sends timestamp only to another isotoxin. Oh! There is another big problem - protocol doesn't allow to determine client name to enable/disable features depend on client. Isotoxin do some tricks to detect client of contact.

@SkyzohKey
Copy link

There is another big problem - protocol doesn't allow to determine client name to enable/disable features depend on client.

I asked for such «client capacity detection» about 30 times, I plan to do it as a standardized custom packet in Konv.im as it'll never gets implemented.

@yurivict
Copy link
Member Author

They have a plan to redesign the protocol. This must be one of the items.

@isotoxin
Copy link

I asked for such «client capacity detection» about 30 times, I plan to do it as a standardized custom packet in Konv.im as it'll never gets implemented.

Standardized custom packet is not enough. How long client should wait such packet from other client? No. Client should know capabilities of other client just in PACKET_ID_ONLINE - first packet from other client. Isotoxin already does it by using modified core. Maybe it makes sense to add this functionality to the core officially?

@SkyzohKey
Copy link

SkyzohKey commented Mar 13, 2017

Maybe it makes sense to add this functionality to the core officially?

It makes sense, but wont happens i guess, as "c-toxcore" focus on tests, not features (yet).
[edit] Please continue this discussion on the newly created issue to avoid spam in this one.

@SkyzohKey SkyzohKey added the enhancement New feature for the user, not a new feature for build script label Mar 13, 2017
@SkyzohKey SkyzohKey added this to the v0.2.0 milestone Mar 13, 2017
@iphydf iphydf modified the milestones: v0.2.0, v0.3.0 Jun 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature for the user, not a new feature for build script P2 Medium priority
Development

No branches or pull requests

5 participants