[eveitguy]

I work on the IT/infrastructure of one of the larger coalitions. We have a team of roughly 10 people who support alliance services which have been maintained for just under 10 years now. There's also a spattering of third party developers who develop against our alliance API endpoints.

Feel free to ask questions, there's a ton of interesting technical problems I've been meaning to write about, but I wasn't sure if people would find them interesting

[incidentnormal]

Please do - what kind of services are we talking about and how much data is involved? Bear in mind I have no experience with the game itself.

[eveitguy]

The spot where most alliance service providers have to start is IAM - controlling how your members are able to access mission critical services such as voice chat and text chat. This is usually done using the EVE SSO, which exposes an oauth2 provider that we can authenticate users against. Authenticating users is just the tip of the iceberg though, you also need to authorize the users to verify they're in your corporation/alliance/coalition, and reject their access if they leave the group ingame. We use the EVE API to query authorization data like that, but it's really the tip of the iceberg of what can be done.

The workflow for a new user joining a major alliance generally looks like this: 1. New user creates account on your central services site 2. New user uses EVE SSO to link their EVE characters to your central services site. This also gives us access to advanced EVE API queries that we can use to monitor everything from who the user trades with, what they own, where they're located in the game universe, and all of their EVEMail. This data is used by corporation HR representatives to check for spies (a whole other topic entirely) 3. If the new user is accepted into your corporation, the central services site needs to figure out that the users character's are now in your corporation and grant them services. 4. When the user navigates to an alliance service, they're presented with a _separate_ oauth2 authorization that uses our central services as a provider. This is how we can quickly integrate new services since oauth2 support is so prevalent.

That's all great for IAM, but it's a small part of the equation. Data federation is another big-deal problem. Many times people who aren't on our IT team need access to their corporation's data - we don't want to expose the EVE API keys of each user because of the high security risk, so instead we expose a plug-and-play proxy. All the user has to do is plug in the URL of our central services proxy instead of the EVE API endpoint, and they can obtain access to their users data without requiring each and every user to go through the oauth2 authorization process twice.

Another interesting mechanism we support is our tax calculator. Many EVE alliances implement an alliance-wide "npc farming" tax that has no ingame mechanism for enforcement. In EVE, corporations can easily levy a 10% tax on its members, but there's no ingame mechanism for an alliance to levy taxes against its member corporations. What we do instead is query the EVE API to find out how much each corporation is taking in in tax, then calculate how much that corporation needs to pay the alliance. We can even track payments using the journal API endpoint. The technicals behind this are fascinating - a months worth of raw, unprocessed tax/journal data represents 5-10 million data entries, and requires about 5000 queries to the EVE API. When you have to run all of that including alliance services on a tiny Hetzner box, things get interesting pretty quick.

If you wanna see what the EVE API looks like, there's a swagger documentation page here: https://esi.evetech.net/