.io are indeed "expensive", but to add one datapoint to your question: there's a concept/genre called "io games", mostly involving browser-based multiplayer games like this one (e.g. Agar.io, Krunker.io, and many others. a quick search leads to several lists of those; some of them don't use an .io domain, but lots of them do).
That's probably another reason why, besides the "cool factor"?
I've been looking for a good open-source self-hosted alternative to RoundCube and the likes - even thought about coding my own in Go as well - and this seems both functional and lean (single statically compiled binary vs. PHP "stack").
I'm only concerned that by being hosted on sr.ht it will lose potential contributors due to poor "visibility".
Regarding the 1011Mbps figure: the graph _suggests_ the measurements are compared to powers of two (the axis is in powers of two and the line right next to the bar _suggests_ the maximum would be 1024), so I would be more inclined to believe there may have been a mix-up between mebibits/sec and megabits/sec, or something IEC/SI units related somewhere in the measurements?
IMHO I don't think that the author would have any reason to fake the benchmarks (because it actually is an amazing piece of software), but I admit I like to err on the side of "assume good intentions".
Well, if you're in the EU then GDPR [1] will be enforceable from 25 May 2018, so it is my noob understanding that the vendor you're dealing with will, sooner or later, be the subject of regular periodic data protection audits and will be forced to have a Data Protection Officer. Not sure if necessary, but you may contact ENISA [2] to be advised on how to proceed.
We actually use Keybase as well, and that was one of our inspirations for the exact same reasons! Since one of our main use-cases was to receive secure data from non-tech-savvy people we wanted to remove as much friction as possible, and that included sending the encrypted blob. We're actually thinking of ways of integrating Hawkpost with Keybase.io, namely fetching/verifying keys (as we already do with keyservers).
Most people would advise you to, calmly, break the task at hand into small tasks/steps. Personally, my problem is that the tasks are too high level (maybe an epic), which makes them overwhelming. By breaking them into easy-to-do-steps that forces you to plan your solution (1st point) and understand the problem (2nd point). You should break them into SMART goals (you've probably heart about this concept already). By having a list of really really small items you get a feeling of progress every time you tick an item off the list; that progress should keep you going! Starting is the hardest part, there's some inertia to it; so make the item so small you'll have no excuse not to do it. Remember: if you still feel confused about an item/urged to procrastinate you probably didn't break it down enough.
The sensation of ticking off items is what should get you going; that's what gives you the sensation of progress and that enables the feedback loop. Physically ticking off the item (pen and paper) is even better. So actually write your list (on paper or digitally using Trello, Todoist, etc.), don't just "think it"; that's key.
Meditation is also good to sharpen your focus.
P.S.: I'm also a procrastinator; there are good days and there are bad days; there's no cure. This is the kind of thing that is managed.
Everyone I know with minimal HTML skills that has ever struggled with LaTeX has eventually thought about it.
A HTML-like templating language, provided with an ACM-style CSS stylesheet and math/graphic/wtv Javascript libraries does seem appealing but simple problems arise from this.
Different browsers render different results, and that's not even remotely acceptable for a to-be-published paper; this lack of consistency is, to me, the greatest obstacle to that reality.
Even considering _very_ similar results on every browser, PDF export would still be incoherent, resulting in mis-pagination (empty pages), "read-while-selected" text and the usual PDF-export-from-format-X bugs.
Using Javascript libraries to provide extensability is a clever design, but the same problems apply. I often find textual bugs (hidden text, text above/bellow flow) on websites that rely too much on web fonts, and that shouldn't happen by now (as some are reporting, even on the author's website).
Too many factors come to play for this to go wrong, but it all comes down to different browser implementations of every single technology in this HTML/CSS/JS stack (and that's a lot to go wrong).
So while it does seem appealing (give the form and I'll sign it!), I don't think HTML+CSS+JS is even near of getting that experience consistency that typesetting-heavy documents need.