4 ms·

I don't live in the US and as such have never interacted with the IRS, but you're equating actions with a very different scope. Looking at it from a game devel

I don't live in the US and as such have never interacted with the IRS, but you're equating actions with a very different scope. Looking at it from a game development Perspektive: The tax filer(intuit in this example) is the client running on untrusted devices, The tax office is the server which has to do a sanity check for each action to assure they're not cheating. Essentially the "client" has a lot of branching actions it could generate and the server only has to validate one of these. From my perspective this client should be provided by the government with public apis for alternative implementations, as they're the one's providing the server.

dguest 4y ago
It depends on the extent to which "validation" is recomputing exactly the same information. If you have a game that runs every single computation server-side it's not a sanity check, it's just a game running on a server. What we have set up is more akin to a game that runs both server side and on the client, with some added latency on both sides because every update has to be cross checked between the two. You don't see a lot of games like this, because it would be absurd. To be fair this is a slight oversimplification. I've lived in the US and dealt with the IRS, and while most of the information must be completed server-side there are some things (like deductions) that would indeed need an API. I think your suggestion, allowing multiple clients to use that API, is a good one. But there's no reason to force the client to recompute everything the server already has.