search

ircv3 / ircv3-specifications

IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
http://ircv3.net/
778 stars 79 forks source link

server-time with clock on wrong time #182

Closed Mikaela closed 8 years ago

Mikaela commented 8 years ago

The spec doesn't say anything about what should be done when client has clock that isn't on correct time (if anything).

This issue was rised at ZNC (https://github.com/znc/znc/issues/1144) which git version attaches server-time to all messages and while there was discussion on #ircv3 (https://github.com/znc/znc/issues/1144#issuecomment-152802270) nothing was ever done to the spec.

Several solutions have been suggested:

If this issue is left alone, it will be encountered again as others (mainly IRCds) start supporting server-time too and it's better to resolve sooner than later (or too late).

attilamolnar commented 8 years ago

The user's wrong clock is the problem here, ZNC has no issue (your second and third points).

Mikaela commented 8 years ago

I believe the spec should still mention this case and move the responsibility to the user.

attilamolnar commented 8 years ago

It's up to the client to interpret the messages, if it sees a timestamp in the future it could warn the user or start ignoring timestamps from the server or maybe turn off the cap.

Mikaela commented 8 years ago

The spec doesn't tell that either even as a suggestion.

SadieCat commented 8 years ago

I believe the spec should still mention this case and move the responsibility to the user.

Users don't read specifications. This is outside of the scope of IRCv3.

Mikaela commented 8 years ago

s/user/client/ if you prefer, but what I am after is clear statement that the server, whether it's bouncer or IRCd, is doing nothing wrong when it sends server-time and the client is on system with clock on wrong time.

I believe that the spec should at least mention @attilamolnar's second comment (https://github.com/ircv3/ircv3-specifications/issues/182#issuecomment-158758607).

grawity commented 8 years ago

Nothing new; mammon also sends time tags with every message (and @kaniini's testnet is still off by several minutes).

There was once a proposal for playbacks to be marked by a batch. I suggest that clients default to only accepting time tags within a playback batch, although it seems useful to optionally accept them always.

Zarthus commented 8 years ago

I can't get my clock functioning properly on Windows. Whenever it syncs it naturally lags behind a second or two. How would you suggest I "fix my clock"?

That said, isn't the idea of server-time that I start using server timestamps instead? How could it be that there is an offset in some timestamps and none in others? And if it is, why is my local clock involved with this at all - it's the server clock that is being used? Is my client using local timestamps for some messages? I'm not sure if I get this part.

grawity commented 8 years ago

I can't get my clock functioning properly on Windows. Whenever it syncs it naturally lags behind a second or two. How would you suggest I "fix my clock"?

Try a more reliable timeserver (e.g. pool.ntp.org) & reduce the sync interval (default is one week).

How could it be that there is an offset in some timestamps and none in others?

Your own messages aren't echoed by the server¹; they're timestamped locally & by your own client.

¹ There might be a cap for that...

Zarthus commented 8 years ago

Your own messages aren't echoed by the server¹; they're timestamped locally & by your own client.

I get that much, but it makes no sense to me when this happens (on ZNC+mIRC) with server side events like kicks.

Case in point (identifiable information stripped):

(16:05:59) * nick (~ident@host) was kicked from #channel by @ChannelOp (kick reason)
(16:05:58) * nick (~ident@host) has joined #channel

In this case, the user probably had kick-rejoin enabled - causing them to immediately rejoin. However, my client's timestamp indicates that he joined a second before the kick happened. The kick was not issued by me - how could this still happen?

Edit: This might be due to a custom script on my side. It seems to be using mIRC's native timestamp parsing, but it could be that internally mIRC does not account for server time for this. i'll have to confirm this with the mIRC forums.

attilamolnar commented 8 years ago

Case in point (identifiable information stripped): (16:05:59) * nick (~ident@host) was kicked from #channel by @ChannelOp (kick reason) (16:05:58) * nick (~ident@host) has joined #channel

If the server sends timestamps in all messages then this example suggests broken behavior from the client as a KICK only happens when the server sends the KICK, not when the client sends the KICK to the server.

kaniini commented 8 years ago

Nothing new; mammon also sends time tags with every message (and @kaniini's testnet is still off by several minutes).

Blame VMware... the damned thing won't keep in sync even with openntpd running.

There was once a proposal for playbacks to be marked by a batch. I suggest that clients default to only accepting time tags within a playback batch, although it seems useful to optionally accept them always.

I disagree; the point of sending server-time with all messages is to make logs more easily authenticated. With a master clock, it makes verification of IRC logs feasible -- if two trusted parties have the same logs, with the same clock time, then it is another data point that can assist with the authentication of the logs.

Instead, the echo-message capability should be recommended to resolve this issue as then the message will be sent back with a master clock timestamp; mammon does this already today.

(this ignores clock skew on the network itself, but that's out of the scope of this conversation, and there are many solutions to that problem already.)

attilamolnar commented 8 years ago

Is there anything to be done to the specs? If not I'd like to close this.

Mikaela commented 8 years ago

Yes, the specs should make echo-message requirement or document this case or make echo-message as base extension.

attilamolnar commented 8 years ago

I don't think the spec needs to be updated to elaborate on wrong system clocks, clients have plenty of ways to shoot themselves in the foot.

Zarthus commented 8 years ago

Not ircv3's concern as far as I'd say.

Mikaela commented 8 years ago

And what if clients decide to not implement server-time or believe that issues like https://github.com/znc/znc/issues/1144 are right and remove server-time?

kaniini commented 8 years ago

I don't think there is any evidence of that really.

Mikaela commented 8 years ago

How about https://github.com/znc/znc/issues/1144 where ZNC developer never replied until the last comment and closing it?

kaniini commented 8 years ago

That means the ZNC developer did not remove the feature, thusly who cares?

jwheare commented 8 years ago

Closing in favour of #199