To be fair, the serifed "I" is included as an alternate[0], along with a stylistic set for other disambiguations[1] including 0/O. This requires OpenType support and some user intervention, but if you're typesetting something it's not impossible.
If the VSCode Neovim extension is anything to go by, this does result in a considerably improved UX versus the usual Vim-key approximation. In addition to your Vim config, it plays surprisingly nicely with all other VSCode editor features, so you can basically work both ways at once.
Did you consider Tiptap/Hocuspocus (also built atop ProseMirror/Y.js)? If yes, what were they lacking that lead you to roll your own? In any case, thanks for the writeup, it's timely to see someone work through this as I tinker with a collaborative editing project of my own.
This Show HN post from 2017[0] for the Monica personal CRM has quite a bit of good discussion on personal CRMs in general. For some reason this anecdote[1] in particular has stuck with me.
I'm not sure I follow. Whether or not the typeface is eligible for copyright, the pricing model and terms of use are at the discretion of the font creator.
Users agree to a EULA which stipulates how they can and can't use the font. This contract provides the legal basis on which a foundry would pursue someone for suspected misuse. Here's Monotype's EULA for Helvetica Now[0], Section 9 specifically addresses copies and derivative works. From there, it becomes a legal matter.
In the US, "typefaces", ie. the shapes of the letters, generally are not. "Fonts", ie. the programs that draw the letters, are copyrighted as software, as something of a workaround. For more reading on the history here Typographica has a succinct overview[0].
The implication that this is a practice being used to skirt copyright is wrong. In almost all cases the font foundry is commissioned by a company to produce a distinct (or not so distinct as the case may be) variant of a typeface/family, licensed to them for their use - as an alternative to having the foundry create an entirely new typeface from scratch.
For an insightful look at creating modern commercial type this talk[0] from Typographics 2017 features Kris Sowersby of Klim Type detailing the process of taking his "Untitled" fonts from inception all the way through to marketing. You can find some other videos where he discusses adapting historical typefaces which may also be of interest.
In general Typographics[1], The Type Directors Club[2], and Type@Cooper[3] all have good talks depending on what you're looking for.
I'm mostly looking to share what I'm planning to read/am reading/have read with a small circle, and for that it's pretty much ideal. There's some basic collection functionality, but no complex library management, no discussions, no recommendation engine, and not very much metadata. It's probably not for everyone, but the minimal approach is refreshingly low-friction. Kudos to the creator(s) for the overall experience.
My only gripes so far have been that search is hit-or-miss (especially for non-fiction), all searches sometimes yield results in an unpredictable order (where an exact title match might be buried amongst partial or seemingly unrelated matches), and the cover they pick is sometimes less-common or downright obscure.
One possible answer to both of your questions is "with legislation", and I feel like to some extent a tightening of the rules here is what Solid anticipates. Perhaps not to the point that we could expect the big players of today to adopt a platform like Solid, but perhaps where the companies of tomorrow looking to avoid the headaches of compliance see offloading data storage to a dedicated entity managed by the user as an appealing option.
Philosophically, and in the long-term, Solid is compelling to me for all of the reasons that the project purports to exist. But we have a classic chicken-and-egg problem with the absence of both reputable pod providers and the development of an application ecosystem.
Practically, and immediately, it is compelling to me as a developer of small-ish applications (plugins, etc.) in which I want to give users the ability to store some data (preferences, etc.) in the cloud without my having to manage that data, or the associated services/infrastructure - including having to deal with absorbing or recouping the cost.
Dropbox once offered the Datastore API[0], which was a handy little bring-your-own-database service allowing apps read/write access to a key/value store in a user's account (Dropbox accounts being quite common then), but it was deprecated[1] due to lack of traction at the time.
[0] https://github.com/rsms/inter/issues/89
[1] https://github.com/rsms/inter/issues/1