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'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 "document" (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/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/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's a bit like a site or mobile app that uses Parse or Firebase: there'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 "identity file" (PGP keypair) the server recognizes as "them", 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'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 "stay" 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's own configured trust settings to decide what operations in the event stream were authorized changes, and then the document'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'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/syncs that Notes document into your local database and then the preview pane displays it in the Notes equivalent of an <iframe>, 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 "messages". Like Slack, you can upload files "to the service" 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 <iframe></i>); and 2. the messaging service itself is hosting the Firebase-alike functionality, such that every "app" 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't it?