This is another suggestion for the Development Incentive Program

Historical Wallet View

Currently the wallet page only displays your recent transactions, and while it's fine for human readability in terms of inspecting the particular transactions, it's not very conducive to higher-level analysis and the information isn't easily communicated to any other tools. In the past when I've wanted to analyze my finances around tax time I've worked on some scripts that would scan through my transaction history and spit out the corresponding data in a .CSV file that could be imported by crypto tax software. I think it would be nice if this was a feature that the regular wallet provided, and a more full-featured implementation could let you dynamically view an account's financial history. For example, it would be cool if it could show you a stacked line chart that would show you how much of your Steem Power came from author rewards, how much from curation rewards, how much from powering up liquid steem, and how much from interest on your SPs. Or it would be nice to be able to easily visualize an account's net transfers out to exchanges relative to their rewards, for curators who want to check if an account is conforming to one of the "club" guidelines.

Getting the information from the chain

Getting a listing of all of an account's transactions isn't difficult, there is already an API call for it. The thing that is much trickier is that internally SteemPower is represented as VESTs, and at any given time there's effectively an exchange rate between STEEM and VESTs (this is related to the mechanism by which SP earns interest). But because it is completely internal to the blockchain, services like CoinGecko or CoinMarketCap don't record historical information about the relationship between STEEM and VESTs. For short time periods it doesn't really matter, you can just use the relationship as of the current block and it's close enough, but for longer time periods you should really be able to get that information in terms of SP and interest, since that's how the blockchain says the external world should think about it.

Since you can't get that information from an existing service, the script I've been using approximates it by scanning the blockchain for instances of the 'fill_vesting_withdraw' virtual transaction -- this is the transaction that implements a powerdown, and it tells you how many vests got converted to an amount of liquid steem, which can tell you what the "exchange rate" was during that block. Since most people aren't actively powering down you wouldn't see many of these in your own transaction history, but it's a big blockchain and odds are that somebody is powering down at any given time, so there are usually several of these processed per day, which is a good enough approximation for historical purposes. The problem is that it's not especially easy to get this information, my script basically looks at blocks one by one until it finds one, which is slow, resource-intensive, and awkward (which is why my script is a do-it-once-a-year hack rather than something I'd be comfortable sharing with others). But if we could add some calls to the API to provide this information it would be a lot easier (assuming the performance and load on the API servers were acceptable).

What development would be needed

1. Add API support for finding historical instances of virtual transactions
2. Code to scan an account's transaction history and relate the transactions to financial categories
3. Code to support dumping that information out in an easy-to-use file like a .CSV
4. UI code to allow dynamic visual analysis of the information
5. Integrate it into the wallet view

Since it breaks apart into chunks like that you don't necessarily need to do all of it at once. For example, it could probably be prototyped as a standalone app without needing to be integrated into the wallet. Or the visual UI element of the proposal could be optional, or left until the future, even if the other parts are implemented.

Pitching

I haven't worked as a freelance software developer, so I'm not confident about time estimates or how much things should cost, but if there's interest in this feature I would make a pitch to develop some or all of this. This seems like it would be a natural evolution of what I was doing with my private script.

---

Another proposal: Javascript infrastructure

Something else I wanted to mention to make sure it gets included in the DIP discussion is support for the Javascript infrastructure. For example, when I install dsteem in a Node.js project I get several warnings, and it would be nice if it was maintained by someone still active on the chain. Also, it would be nice if the Javascript documentation were better and more complete (for example, as far as I can tell there is currently no tutorial that uses the commentWithOptions method, even though that's the normal way to add a post now, and documentation showing how to set beneficiaries would be quite useful). I wouldn't want to support or maintain a library myself, but I'd be willing to help with documentation.

(Header image composited from Pixabay images and an icon image)