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

Does appservice timestamp massaging also apply to /kick, /ban, etc? #1394

Closed
turt2live opened this issue Jul 10, 2018 · 4 comments
Closed

Does appservice timestamp massaging also apply to /kick, /ban, etc? #1394

turt2live opened this issue Jul 10, 2018 · 4 comments
Labels
application services clarification An area where the spec could do with being more explicit

Comments

@turt2live
Copy link
Member

The spec says "only when sending events", however there's quite a few routes that send events. Should probably explicitly declare which routes this applies to.

@turt2live turt2live added the clarification An area where the spec could do with being more explicit label Jul 10, 2018
@turt2live
Copy link
Member Author

also EDUs: can appservices send presence from the past?

@turt2live
Copy link
Member Author

Looks like this currently only works for the plain /send event path. State events cannot be massaged, which might be a good thing?

@turt2live turt2live self-assigned this Aug 17, 2018
@turt2live turt2live removed their assignment Aug 17, 2018
@Half-Shot
Copy link
Contributor

Currently HEAD says:

This will only apply when sending events.

Which is a little too sneakly. I'd prefer to say explicitly only /send supports this.

Aside from that, I'd like to make it clear that this doesn't insert things into the dag through some magic ts resolving thing so you may not see events appear in the right place just because you timestamped them.

@turt2live
Copy link
Member Author

Closing in favour of #1585

The tldr is that "yes, timestamp massaging should apply to everything".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
application services clarification An area where the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

2 participants