Proposal: Delaying Killmails

[cvweiss]

Feature Request

The ubiquity of delayed killmail discussions has risen greatly in the last few months, and I'd like to official make the proposal for delaying killmails.

Killmail details should be inaccessible via ESI until they are of a certain age, e.g., 1 hour.

Use case

Third party tools use ESI killmail details as near instantaneous intel, allowing the tool users to avoid PVP or setup the perfect counter balance to any form of PVP. Delaying of killmails will make require more in game resources to be utilized (e.g. more players).

Authentication

Public route, no auth is required.

Example return

If a killmail is less than an hour old, the https://esi.evetech.net/latest/killmails///

endpoint should return a HTTP status code of 204, possible including a cache expires header as to when the request will be an hour old.

If a killmail is one hour or older, then the endpoint indicated above should behave as it does today and return the details of the given killmail.

I offer this solution as it is simple and does not affect character or corporation killmail endpoints that require authentication. This proposal puts the age check in one location, thus reducing the amount of back end code that will need to be modified if this proposal is accepted.

Checklist

Check all boxes that apply to this issue:

• [X] Feature request description is provided
• [X] Use case exists
• [ ] Feature requires a new route
• [X] Feature adds data to existing route
• [ ] Feature requires new auth scope
• [X] Feature can reuse existing scope
• [X] Feature does not require auth
• [ ] Meta feature, applies to all routes

[CarbonAlabel]

Duplicate of https://github.com/esi/esi-issues/issues/948. However, some recent changes might have changed people's opinions on the topic, so feel free to continue discussing this further in here.

[ddouglas]

At the request of @cvweiss I am posting this here. I have no objection to the delaying killmails, I am in full support of it, however; I believe that the delay should be placed on the character and corporation killmail endpoints, not on the killmail detail endpoint. Allow me to explain.

By placing it on the killmail detail endpoint, you are preventing everybody out there from reviewing the details of the kill externally, for example via zKillboard. If I die, or kill somebody and I want to see whatever statistics can be derived from that killmail, I should be able to use the external link provided in the killmail window to view these details. This is a very manual process that I believe should remain untouched.

By placing it on the killmail feed endpoints, you are denying access to the instant intel that those who did not participate in the fight which is what I support. If I am currently mining in Pure Blind and there is a hunter who is currently roaming a region over and killing other industrialist, I should not be able to determine what he is flying based solely on a killmail feed provided by a third party application. I need to use the ingame mechanics provided to me, (i.e. somebody linking a killmail, intel channel where somebody links name, corp, etc.....)

I hope I did a good job at detailing my thought process

[Inomares]

I agree with rather putting it on char/corp feed endpoints on the basis that many (most?) organizations handle SRP using the direct killmail endpoint, and this usecase would be negatively affected. While not a huge deal at 1 hour, we may want to tweak/increase this delay in the future, and putting the delay on the feed endpoints would make sure we don't lock ourselves into a specific delay just because we fear adversely be affecting a bunch of other services as collateral damage.

Hash scraping doesn't strike me as a very realistic problem since it requires much of the very same intel that the delay aims to counter, but this should also be pretty easy for CCP to detect.

[ghost]

I'm not worried about hash scraping, the error rate limiter will make that impractical.

I mildly favor the original 204 notion because the fact that you get back a 204 on the hash tells you the mail you were given was real if you already have the contents, but if you only have the hash it's relatively useless to you until the duration is up.

The downside of that is it will roll back the clock to the good old days of people having to write killmail xml parsers which feels like a step back, so I do see the merit of allowing the hashes to be passed around and only delaying the feed endpoints. I feel like more is achieved if we pull it all the way back to "if you don't already have the contents, you can't get the contents" though.

On a technical level we could do either, I don't see big technical issues either way.

[jtgill]

No one seems to have mentioned it, but killmail ids/hashes are also provided under the character notifications feed. Unless you apply the same delay to certain types of notifications alongside the delay on the character/corporation killmail endpoints, you've gone through a lot of effort for an additional 5 minute delay to killmail availability for anyone sufficiently interested in up to date automated information. So CCP ends up having to choose between incentivizing data-oversharing, breaking the general assumption that the notification feed is chronological, or omitting certain notification data entirely.

If you take the other approach and delay the killmail details endpoint itself, you're effectively replacing the endpoint with a different endpoint that happens to have the same name. It's not a rolling window like the character/corporation killmail endpoints, so as cvweiss mentioned a new response code would need to be added to indicate that the killmail you requested is valid but is not available for another X minutes. It's probably safe to assume that any program not in active development would end up either breaking or over-polling the endpoint trying to wait out the unknown 'error'. Don't forget that all endpoint versions would need to be changed for this to be effective, and that endpoint versioning exists specifically to avoid breaking existing programs.

There's also the hours of ESI development that could be put to better use elsewhere, the overall question of technical viability on CCP's side, the fact that the community in general is divided on the issue, and the undeniable fact that this is not terribly difficult to work around from a technical standpoint nowadays. The end result would be an arms-race for who can put together the most disinformation-resistant slack/discord bot that can parse killmail copy-pastes from in-game. Someone would eventually post it to github, use it as a backend to something like zkill, players would standardize on a small group of websites, and we'd largely be back to the status-quo, but with more chat bots to maintain and perhaps a more federated style of killmail management.

TLDR: The cat is out of the bag on killmails. There's no viable technical solution to enforce this in any meaningful way that does more than cause a temporary headache for the folks that actually want this information.

[CarbonAlabel]

@jtgill really well put. While after that I probably don't need to, I'm still going to quote my comment from last year's discussion, and elaborate a bit.

I strongly oppose the introduction of any artificial limitations which inhibit the players' ability to use their data, such as the one proposed in this issue.

My position from last year remains unchanged. As long as killmails remain the current immediate availability, one-party consent system, the only thing delays such as those proposed here will do is take choice away from players. If they want to immediately publish their killmails, they will find a way to do so, whether that means manually posting them, and/or reaching for solutions other than the official API.

[ghost]

@jtgill You're not wrong about the fact that people will just start manually uploading killmails if they can't have it automatic, but that does at least open the door to people poisoning the data (although that means we would have to not confirm killmails for the duration). There's a big difference between getting voluntary uploads by humans vs an automatic stream that you can be certain contains no lies.

Back when evemon was using cache scraping to upload trade data, the data was only about 90% reliable. I seem to recall that there was much data manipulation going on to hide good trade opportunities and manipulate the market. It might be interesting to do an analysis of market efficiency before and after correct market data became accessible via API.

It's a good catch about leaking data though other endpoints though. There are solutions to that, ranging from blunt (blackhole killmail notifications, ~20mins work) to elegant (make a shared module that selectively delays or redacts that data according to the same timeframe), but it does mean that going forward it's important not to open new leaks.

[guiguilechat]

Modify KM in the monoliths. KM are not processed/accessible until one hour after the kill. Insurance, bounty will be paid at this moment in the game.

Then no ESI path needs to be changed.

[NathenSample]

Surprised I never caught this at the point of original creation, but figured I'd weigh in with my two cents, since me having an opinion is utterly unheard of.

I'd be strongly opposed to a limitation being applied to the killmail endpoint - A portion of the playerbase seems to have this inclination that killmails, and how readily available they are, has lead to stagnation of the game as people use them to avoid fights; my personal usecase, and I imagine the usecase of atleast one other player out there is the opposite, the use of killmails to find fights.

Killmails don't drive a gameplay style, the person who is actively avoiding a fight, is still going to be actively avoiding a fight, the person who is trying to engage in a fight, is still going to be looking for a fight with or without killmails. In my personal experience the type of "fight" that gets avoided by the use of services such as zkillboard are, "I won't warp my travelceptor through this system because it has smartbombers" and "I won't take my freighter through that gate it has campers", there's certainly more nuance to that, but, in my heavily biased opinion, the facilitation of "PvPer vs PvPer" fights that the killmail system allows, outweighs the loss of those type of kills.

It's also worth noting that during the period zkillboard had a delay (Due to chaos era, if memory serves) reddit was going berserk (Which, just like me having an opinion, is entirely unheard of). I'd be interested to know stats around web traffic to zkill during that period if you felt like sharing @cvweiss

I think to approach this in a logical manner then an event akin to chaos era would be the most viable method, rather than just slapping a delay on the endpoint, link it with some "ongoing event" within the eve universe, add a temporary delay to the endpoint that allows CCP to gather metrics around how a modification to the endpoint effects the game world (Without other ongoing effects such as no local), without going for a more heavy handed change, which is then harder to roll back.

I think if we truly wanted to address the effect the killmail system has on the game, then it'd be the entire removal of the system, lossmails have much more of an effect on gameplay in my opinion than any percieved use for them as an intel channel, but that is neither here nor there.