As I’m now employed by the community, I figured I’d follow @Yeastplume’s example and start writing regular updates. However, as you’ll see my days are more filled with uninteresting and repetitive tasks like reviewing PRs, handling questions, release management and all the small tasks that go into making sure the project runs smoothly. So to avoid making them too boring, I’ll try to make those updates bi-monthly, with one update mid-month and another at the end of the month. Also, I’m a lazy writer 
On a daily basis here is what I tend to do (can vary depending on respective volume of work and daily schedules):
- Check my email for any emergency and start filtering out important github discussions (from email notifications).
- Do the same with Gitter and Keybase, see if I’m flagged anywhere.
- Address potential higher priority tasks that emerged from above. Usually it’s someone needing something or with a pressing question. Can also go from a new security audit update to “someone shitposted something wrong on the Internet and people are believing it”.
- Touch base and chat with people who may have blockers for their work, personal concerns or general worries.
- Review Github PRs that are ready for it. I can’t emphasis enough how much time this takes. A single non-trivial PR can exceed an hour.
- Try to push the PRs that are stalling (author is busy with other things, discussion doesn’t seem to converge).
- Also do some triage for coming releases, checking what’s missing and progression of critical tasks for said release.
- Do the work that I was supposed to do (right now trying to progress on I2P, create an Ethereum donation wallet, see if I can have an account on some exchange without KYC).
- If I’ve got time to spare, check grin-forum and chime in somewhere if needed.
- If I’ve got more time to spare, check Reddit.
It’s not uncommon that I don’t get to the work I was supposed to do by the end of the day. But I usually get there on week-ends, when things tend to be quieter.
As far as what I’m working on now, the smaller task is getting us setup for Ethereum donations. You can learn more about that in the meeting notes. The larger task is integrating Grin with I2P, as described in issue #2712.
For a bit of background, I2P is an anonymization layer on top of internet, it masks your traffic and you IP address. If you’re familiar with Tor, it’s a very similar type of technology. The main difference being that Tor is better adapted to anonymize the existing web while I2P is really a network on top of the Internet network. Said differently, you can’t easily browse the web with I2P, but it works well for peer-to-peer networks.
As far as Grin is concerned, beside the obvious anonymity gains, I expect quite a bit of improvement in user experience and network connectivity. The main advantages are that you can connect to I2P even if you don’t have a public IP (like most people at home or work) and you get a network address for free out of it (something like cuss2sgthm5wfipnnztrjdvtaczb22hnmr2ohnaqqqz3jf6ubf3a.b32.i2p but you can go vanity as well). So you become reachable from any other node, and that should include your wallet. So if all goes well, Grin could have addresses. Not addresses on the blockchain, but addresses to receive coins in a secure and private way.
Regarding the work itself, I’ve lost more time than I expected navigating my way through the cryptography, the addressing mechanisms and the various APIs to interact with an I2P daemon (BOB and SAMv3). While the daemon implementations seem well maintained (i2pd and i2p-java), client APIs aren’t and it wasn’t obvious to see what would work better. I ended up settling on the SAMv3 protocol and forking the abandoned i2p-rs and dusting it off in a big way.
Current status is that my i2p-rs fork now has most of the functionalities needed for Grin I think, and is ready to get integrated. So that’s what’s next. I’m starting with our peer-to-peer layer, using I2P to create both a server socket and client connection. This will also involve extending our p2p protocol to understand i2p addresses. Once all of that is working and we can have peers using both I2P and straight TCP, I’ll move to the wallet listener and sender. Hopefully everything works out.
Wish me luck! Next update in mid-April.