Original Spec for Lotus Notes (1984) [pdf]
Oh boy, Notes. I worked at IBM last year. I had, in turns, a frustration, a revulsion, and finally a great admiration for Lotus Notes. Not for any practical reasons—the implementation leaves much to be desired. But in the abstract? It&#x27;s kind of cool.<p>See, Lotus Notes is essentially (the modern conception of a) web browser: an MDI navigation chrome, plus rendering engine, plus VM runtime. Each time you open a Notes &quot;document&quot; (like an HTML file), the code embedded in it is run through the VM to create a DOM, which is rendered by the rendering engine and displayed in the window&#x2F;tab representing the document. One of the common DOM element types is a text link, and Notes documents frequently link to other .nsf files, which then are downloaded and which then open in Notes in new windows&#x2F;tabs.<p>The one crucial thing that Notes has over web-browsers, though, that made all the difference in how the two ended up evolving, is that in Notes, each Notes document has a <i>remote</i> database associated with it, that <i>the document</i> can read from and write to.<p>It&#x27;s a bit like a site or mobile app that uses Parse or Firebase: there&#x27;s no need to write backend logic; you just write your client, and then point it at a <i>generic</i> app backing-store server. In this case, the backing-store server is called Lotus Domino.<p>Like Parse or Firebase, Domino handles authenticating clients. For each Domino server a Notes client is signed into, they have an &quot;identity file&quot; (PGP keypair) the server recognizes as &quot;them&quot;, and which their Notes client uses to sign any documents it authors (where an update sent by a document to a Domino server is sent as a small signed document.)<p>This is in a lot of ways similar to how browsers use TLS client certificates, but lighter-weight, in a similar way to how e.g. an Apt repository&#x27;s pre-signed packages are lighter-weight than HTTPS. In TLS, a piece of data will lose its origin once it passes out the other end of a TLS tunnel, and so the server must make a metadata record of who it was talking to, and vouch for the data <i>itself</i> (with another TLS tunnel) when someone else requests it. With pre-signed documents, the server can be a dumb store-and-forward server, and the documents will always just &quot;stay&quot; signed by whoever first created them, without needing un-wrapping and re-wrapping on every transmission.<p>And <i>that</i> means that, unlike Parse or Firebase where linearization is done on the server, a Notes document can just download all the store-and-fowarded update message-documents representing its database, and then linearize them itself, using the Notes client&#x27;s own configured trust settings to decide what operations in the event stream were authorized changes, and then the document&#x27;s own merge policies to decide how to linearize the data (i.e. what fields are CRDTs, what fields are last-write-wins, etc.)<p>Then, finally, you can understand what is going on when Lotus Notes opens up and shows you what looks to be an email client: it&#x27;s a Notes document (like a web-app) syncing down a Domino database full of signed update-messages from other Notes clients (one of which can be an SMTP gateway server, allowing messages to get pushed in from outside the Notes system.) The email client document <i>chooses</i> to represent its (considered-authorized) update-messages as individual email messages in a list—but some of them are also other things, like e.g. edits to previously-sent messages.<p>Each signed update-message might just contain a plaintext message, or it might effectively be a publish-event pointing the Notes client at a Notes document. The email-client document is responsible for deciding how to render the plaintext messages when you focus those; but if you focus a message representing a reference to a Notes document, it just downloads&#x2F;syncs that Notes document into your local database and then the preview pane displays it in the Notes equivalent of an &lt;iframe&gt;, allowing it to run all its own code.<p>So, you could picture the default Lotus Notes email client as being less like Gmail, and more like Slack: it syncs a history of update-messages, some of which are modification-events for real &quot;messages&quot;. Like Slack, you can upload files &quot;to the service&quot; and then just send references to them to other users in your team. And some of these files could be small, self-contained HTML5 apps, talking to a service like Firebase.<p>The key differences, then, are that 1. you actually interact with such documents <i>within</i> the client (so, picture if you could post HTML documents into Slack that would be displayed <i>as an &lt;iframe&gt;</i>); and 2. the messaging service itself is hosting the Firebase-alike functionality, such that every &quot;app&quot; built with the Firebase-alike functionality gets an implicit User model mapped to the user of the messaging app.<p>When described like that, it actually sounds a bit <i>less</i> braindead than Google Wave, doesn&#x27;t it?