EVE Information Portal

First.
This should be interesting. The 3 developers named are all people I have interacted with in the past and can confirm are easy to worth with and talk to. Their work using XML API and CREST has been nothing short of amazing. I'm looking forward to seeing what they can cook up.

Nice, finally something that should work :)
But, will we be able to grant access to our data (player data) to some external app, the same way we are with keys (xml api)?
Im refering to services like Evething, that is scraping data for lot of different users in batches and storing them for later use, instead of directly displaying data for only logged in users...

Welp time to start adjusting code from the WarpToMe Waitlist

Will there be wallet transactions via the new API?

I can't see in the API where I can get a list of character id's for the current login? Otherwise it looks like a healthy beginning. I can't help but wonder if you will add more features to entice devs to start using it though.

The most important thing about the SSO is:
- Players need to have the ability to revoque access whenever they want!

Today once someone have your access you can't do anything to stop then from gathering your data.

This is a HUGE issue that REALLY needs to be fixed!

Interesting stuff! Did you use plain Kubernetes and built a custom build pipeline for the Docker images or did you use something like Openshift? Would be interesting to know how you account for stack/os updates if you built your own solution.

That and wallet journal entries for both characters and corporations are extremely high on our priority list. I have some partial work done for the character wallet journals, there's some pain involved in presenting all the different types of journal entries (there's more than 200 of them ), but I'll figure something out. Once that's done corp wallet journals and transactions should follow quickly.



Similarly high on our hit list and similarly work is already under way on it.



This already exists but is not well presented. It's actually linked from the community page and can also be accessed with this URL: https://community.eveonline.com/sso. I'm hoping to get something more accessible into the launcher, but I won't expand too much on that now, or I'll be promising another teams engineering time and that's just impolite



Structures in general are first class entities in ESI and we're expending a lot of brain power to make sure that authorized characters can access them without leaking information to unauthorized characters. When the market endpoints are released, there will be a solution in place for structures as well.

The same is true for industry endpoints, although they are not currently at the top of our priority list. If you'd like to make a case for them being higher priority you should totally join the #esi channel on the tweetfleet slack, we are coordinating with the community to prioritize these things, and most of that happens in tweetfleet

While I'd like to see quite a bit of structure functionality, the most important thing in my mind is FUEL. Right now, the only tools we have to monitor fuel levels is a notification when the structure runs out of fuel. This is less than ideal, considering the requirement to burn three days worth of fuel use immediately when bringing a service module back online. You can't even reliably monitor fuel levels with the Assets endpoint, as you can't determine the flags of an item in a structure. Minimum Viable Product here is a list of the contents of the fuel hangar; as a bonus, having the currently online service modules included in the information would help too, but we could live without it in the short term.

On a less pressing note, a blind lookup for structure names would be nice. Unsolicited implementation suggestion follows. Perhaps generate a hexadecimal string or UUID corresponding to the structure from various identifying information of the citadel (and seeded, of course,) then pass that along as the ID in anything relevant (wallet journal entries, contracts, etc.) Then, have an endpoint similar to https://esi.tech.ccp.is/latest/#!/Universe/post_universe_names for resolving those uniquely identifying strings. This is (roughly) the tactic that's currently used for killmails in CREST, and it appears to be serving just fine.

I meant making transactions via the API.