I've raised this topic for discussion in the API Development forum. It seems to have some broad approval, and it was suggested that it be raised here to get some more eyes.
At the moment, API keys are tied to users. This is fine if all you're doing is working with user data, but when it comes to factions, this gets tricky.
I would like to suggest that a new API key be made available, one that is tied to factions and not users. We currently have two primary problems:
When a user leaves a faction, any API keys in use by that user to retrieve faction data either stops working if the user is clever enough to drop the API key, or what usually happens, the API key will start erroring or returning data for a different faction the user has joined. Usually happens when the user goes guesting etc.
When a user is absent for a long time, the keys associated with that user are disabled when the user goes dormant.
By using faction keys we gain the following:
Users do not require API permissions to access faction data.
Faction keys should be tunable in the same way that user keys are currently tunable to only allow specific fields as required.
If a user leaves or goes dormant, this has no effect on any API integrations.
I'm going to drop this here as a point of discussion...
Could we look into creating faction level keys. Keys that aren't linked to a specific user, but instead a faction.
I'm currently managing keys for multiple users to poll data from multiple monarch family faction members for retals. The problem here, is that people keep moving around...
I mean one-fix would be to not move people around, but then that doesn't fix the other issue which is when members go long-term unavailable and as such their API keys are disabled.
I think API keys generated and linked to factions instead of users would be of significant benefit here.
The API currently has a number of endpoints that return values in the incorrect types for JSON exchange.
If it's a float, please return a float; I'm looking at /user/?selections=skills where floats are being returned as strings - Why?!!!
If it's an int, please return an int; example here - /user/?selections=attacks where empty string returned if there's no value - Why?!!!
if you have a null value, please, just return null.
I don't care about datetimes, because I normalise to UTC anyway, however, standardisation on, perhaps epoch timestamp with TZ Info of UTC, would be nice. Example here: /user/?selections=profile where signup is a ISO date string... whereas all the other fields where time is relevant (status.until, states.hospital_timestamp, last_action.timestamp) are all UNIX timestamps.
Pretty please, can we have some standardisation? I'll buy donuts or cake IRL.
The userscript wall-battlestats has been updated, but the developers have broken the greasyfork rules and minified/obfuscated the original code. It's now called TORN War Helper, too.
The new code has a massive base64-encoded blob in the middle of it and I cannot be arsed to review it.
This script now breaks the GreasyFork site rules that state that the code must be readable by users.
In its current form, the code shouldn't be trusted and should not be used until it's updated and people can review it. (and the developers explain why there's a massive base64 encoded blob in the middle of the script?)
The script used to be readable. People could review it and judge whether to trust it. The latest update replaced that with deliberate obfuscation. That is not cosmetic, it breaks the trust chain.
You claimed obfuscation is needed to stop copying, but the code was open for months. Either copying was never a concern, or you chose to hide it only after people started trusting it. Either way, that weakens your argument.
Security is not about proving malice. When previously transparent code becomes opaque, you treat it as untrusted. Not malicious, just untrusted. The burden is not on users to prove it is safe. It is on you to make it auditable.
Userscripts run with access to the DOM, API tokens, storage, cookies, and external calls. The only safety control we have is the ability to read the code. Remove that, and the trust is gone.
Minified code can still be reviewed. Obfuscated code is designed to block review. When you remove auditability, you lose the right to complain that people do not trust it.
About sourcemaps, they do not restore trust. They are optional, can be changed at any time, and are not bound to the deployed script. You are asking us to trust that the sourcemap is genuine, current, and complete. That takes us right back to blind trust.
If you choose to keep your code closed or obfuscated, that is your call. But that also means it sits outside the trust model of user scripts. People will avoid installing it. That is not hostility. That is caution.