Starling
14th January 2026
It's been two years since I started this blog, and two years since I started writing my ground up replacement for Domino, Tinn. Progress has been very slow, and more recently my real job has demanded my attention, so progress has actually stopped while I worked on a different project called Starling.
For 2026 I've set myself the goal of blogging at least once a month. This month I'm taking the easy option to give an update on both projects.
Tinn status
I've successfully built a HTTP server and in the process refamiliarised myself with the C programming language. This is what is hosting this blog. It's fairly stable, but not completely so as it crashes about once every two months. I'll have to look deeper into that at some point.
I’ve started to add HTTPS support. This is where I got lost in a sea of maths and protocols. I’ve got working implementations of AES and RSA. AES led me to learn about finite fields, which took a while but was quite satisfying when it all clicked. Implementing RSA required developing code to support arbitrary precision integers, numbers thousands of digits in length, this was in fact the hardest part of implementing RSA. The good news is (if I understand correctly) I can use the same big integers to also implement Diffie-Hellman. I looked at ecliptic curves, they seem to be big integers over finite fields, I'll come back to those later.
The next actual task is to implement the required hashing algorithms starting with SHA-2. I also need to write code to manage certificates. Finally tie all this together under the TLS protocol and integrate it with the HTTP server. There is still a way to go.
Goodbye Domino
Meanwhile, for my real job, I've started work on migrating Domino applications to a new platform. This has required my programming focus for the past six months, bringing progress on Tinn to a halt.
While I would have loved to replace Domino with Tinn, there are two obvious issues with that idea: first, Tinn is not ready; and second, Tinn is a toy and not appropriate for enterprise use.
Let's back up, why are we replacing Domino? Quite simply the licence cost. I explained this in detail in a previous post but to summarise, a change in licensing means Domino is no longer cost effective. We currently licence Domino on a per server licence, HCL have discontinued that option forcing us to switch to a per user licence. If I do nothing, the licence cost will increase by over 2,000%. That's not a typo. The new license is over 20 times more expensive. I can't justify that. I didn't really ask for permission, I just informed my managers we were migrating.
This effort started about a year ago by reviewing each application and suggesting to the application owners one of four options:
Retire the application. We have been using Domino for nearly 3 decades and some applications are no longer being used but we've never retired them as they cost nothing extra in licensing or maintenance and having them around just in case is the easy option. Retirement means reducing everyone's access to reader while we have a server licence then removing access entirely when the licence expires.
Replace the application. For some applications there are off the shelf products that can do the same job, in some cases we are already paying for that software. A typical example are document repositories. Domino pre-dates SharePoint and Teams, so there are still a few Domino applications that could be replaced by a SharePoint site which is already licensed and arguably does a better job for this use case.
Pay for licences. For some applications that are used daily by a small number of people, the new licence costs are actually reasonable. I was quoted 100 USD per user per year. For an application used by a small team, and used every day, it's easy to justify 50 cents per user per day. In these cases we will stick with Domino but only licence the users we strictly need to.
Redevelop the application. When the application is still in use, there is no suitable replacement, and it has a large user base, the remaining option is to redevelop the application on a new platform. Consider for example an application used to record production defects. It is still in use so it can't be retired. The workflow is highly bespoke so off the shelf software is not an option. It needs to be accessible to most of our staff and some business partners, thousands of people, so it would cost hundreds of thousands a year. In theory anyone could be involved in the process so all need a licence, in practice most people will only use the app for a few minutes every few years. Domino is no longer a practical platform for this kind of use case and so we need to redevelop on a different platform.
A handful of applications fell into the “pay for licences” bucket. The rest were evenly distributed between retire, replace and redevelop. My focus, especially since August, has been on the redevelopment efforts.
Project Starling
Thankfully all the applications that need to be redeveloped have a web front end, and all the applications have been developed with our own library. This means we should be able to reuse most of the client side code without modification.
The back end is a problem, we need to recode all server side logic (aka agents) and replace the Domino database with something equivalent. No other database has complete feature parity, no other database implements record level security with readers and authors fields.
To align with other projects I was directed towards using AWS. I decided to go all in and embrace serverless, based on my research and our usage numbers, this should be the most cost effective.
The plan is to use DynamoDB as the database and Lambda to emulate Domino features like readers fields. This will all be exposed as a web service that looks to the client like a Domino server. I.e. calls to the server to read documents from a view will be translated by Lambda to calls to DynamoDB, filtering and formatting the results so they look like they came from Domino.
Writing this compatibility layer is a tricky task. There are a lot of Domino features that need to be emulated beyond basic database operations, for example ACLs, attachments, emails, etc. In theory once complete it should make migrating individual applications much quicker, as *all* that is needed is to recode server side agent as lambda functions.
I started work on this in earnest in August, I've got till the end of March. It's going ok, I'm not as far along as I would like to be so the next two months are going to require some crunch.
I will say this, as cool as the tools and services provided by AWS are, there is still a lot of faff that Domino did for you. So my belief there is a gap in the market for a Domino like application development platform has not waned. I should do something about that :)
TC