Show HN: Tritium – The Legal IDE in Rust
Hi HN! I'd like to submit for your consideration Tritium (https://tritium.legal). Tritium aims to bring the power of the integrated development environment (IDE) to corporate lawyers.
My name is Drew Miller, and I'm lawyer admitted to the New York bar. I have spent the last 13 years in and out of corporate transactional practice, while building side projects in various languages using vanilla Vim. One day at work, I was asked to implement a legal technology product at my firm. Of course the only product available for editing and running programs in a locked-down environment was VS Code and its friends like Puppeteer from Microsoft.
I was really blown away at all of the capabilities of go-to definition and out-of-the box syntax highlighting as well as the debugger integration. I made the switch to a full IDE for my side projects immediately. And it hit me: why don't we have this exact same tool in corporate law?
Corporate lawyers spent hours upon hours fumbling between various applications and instances of Word and Adobe. There are sub-par differencing products that make `patch` look like the future. They do this while charging you ridiculous rates.
I left my practice a few months later to build Tritium. Tritium aims to be the lawyer's VS Code: an all-in-one drafting cockpit that treats a deal's entire document suite as a single, searchable, AI-enhanced workspace while remaining fast, local, and secure.
Tritium is implemented in pure Rust. It is cross-platform and I'm excited for the prospect of lawyers running Linux as their daily driver. It leverages a modified version of the super fast egui.rs immediate-mode GUI library. The windows build includes a Rust COM implementation which was probably one of the more technical challenges other than laying out and rendering the text.
Download a copy at https://tritium.legal/download or try out a web-only WASM preview here: https://tritium.legal/preview
Let me know your thoughts! Your criticisms are the most important. Thank you for the time.
But it’s a general principle: the more you are implementing from scratch, the more of a mess you’re likely to be in. As one example, at IME is completely broken, completely preventing a lot of non-English usage. Even my Compose key is broken: the key sequence `Compose - >` should produce →, but instead produces “Compose->”. This is the first time I’ve seen the Compose key turn into the word “Compose”!
For serious desktop-style applications, I honestly recommend that you not use plain-Rust GUI just yet. It is definitely steadily getting there, and I’m very optimistic that there will be at least two reasonable choices available within three years, but it’s still not where I’d want it to be for an app like this yet. Web browsers are, unfortunately, typically the pragmatic choice, even for desktop-only apps.
There are issues solved by the DOM for sure, but it requires shipping an entire web browser, and this product is a dedicated word processor. I’d rather face those issues head-on than defer to someone else’s implementation of such a core aspect. I know IME is broken, and Tritium’s really only able to address the needs of the happy path at the moment, but if can do that well, then there’s a business model to fund solving the edge cases to bring a real Word competitor to the desktop for lawyers.
Yes, if you want to run in the web browser, use the APIs the browser gives you. If you want to go wild, run directly on desktop OSes.
Web browsers just straight up don't have some of the APIs you will need for a working app. Accessibility is a major example. If you want to stay compliant with legislation (probably something to care about when selling to lawyers), you'll end up poorly re-implementing an inferrior version of your GUI framework as a DOM tree for accessibility.
Sometimes your use case is just so uncommon and esoteric that's genuinely what you need to do (see Google Docs), but keep in mind that it requires Google-like levels of engineering investments to do it at least somewhat well.
https://makepad.nl
https://github.com/makepad/makepad
That being said, if this is truly a desktop application, why waste time making it run in a browser? If the point is to have a preview, put the time into making some good short videos that can go into a preview page.
That’s a moot point and completely irrelevant for 99.99% people.
In any event, VS code is only required to render text in a single font, with very few layout concerns, styling, run-level formatting, etc. that require re-flowing across multiple of pages, etc. And each of those is text files measuring in the bytes. Tritium, by contrast, has to hold and operate on PDFs and Word documents each with very complicated layout and rendering logic and measuring in the kbs.
I can't speak to the future, but let's say I hope so!
> Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:
> [...]
> This is a huge amount of work, and authors are most strongly encouraged to avoid doing any of it by instead using the input element, the textarea element, or the contenteditable attribute.
[1] https://html.spec.whatwg.org/multipage/canvas.html#best-prac...
The approach they've taken can create frustration, but it can also be seamless for users and create joy. For instance, I got to try out their app without any setup on my part, and then I can download it and it works exactly the same on my Windows and my Mac machines, because it's the same codebase for all three platforms. That kind of story was the holy grail of UI tooling for many years, and I think we should keep going down that path to improve it, despite frustrations along the way.
The Linebender community is a very promising venue for such collaboration, and there are at least four organisations investing quite a bit into this and related endeavours.
I won’t name any specific two libraries. It also depends a little on whether you’re targeting web tech only, or web and desktop, or desktop. (Or mobile.)
Good luck!
I've gone back and forth on the UX idea, and while I do agree, it's important that Tritium selects for users that are going to be able to quickly adopt the newer concepts. Just simply presenting a "better Word" isn't really going to move the needle. It's really a shift in expectations. That said, I have recently backed off defaulting to dark mode to make it feel slightly more familiar.
Think about programming languages- ones that introduce radical new concepts may still employ familiar syntax/naming to smooth the transition for newcomers. Rust mimicked C++, TypeScript extended JS, etc. These languages were made to introduce powerful new ways of thinking about code, but by appearing as similar as possible to what devs already knew, they freed up more brain cycles for people trying to adopt them. They didn't muddy their concept-space for the sake of familiarity, but they didn't introduce any more unfamiliarity than they actually needed to for the benefits they wanted to give
Dig the idea of this product, will give it a whirl tonight.
Source: attorney, former dev
How much less adoption would Rust have gotten if it looked like OCaml instead of C++?
Its adopters are not stupid, they could have figured out alien syntax if they were already convinced of the benefit. But selling someone on an entirely new substrate for their professional work is a huge ask. You need to make it as immediately-palatable as possible, or they'll just keep on sailing without giving it a chance.
if anything, it didn't mimick /enough/
But I would push back a bit against the UX and it being a "better Word". It is not immediately clear from looking at the website whether you support tracking changes. If you support editing Word documents, why aren't basic editing features, like font selection, size and weight, exposed in the UI. (I am viewing it on mobile Chrome and I might have missed it because your page doesn't support pinch to Zoom.)
You don't have to make it look like Word but it must be designed to facilitate common interaction patterns needed for working with Word documents.
(If you are building it on top of VSCode you could use its multiplayer features, which could be a good sell. )
I think there's a lot of money to be made in this arena, especially given that LLMs are much easier to integrate with plain text files than with Word documents.
[1]: https://hiandrewquinn.github.io/til-site/posts/things-word-h...
I’m not a lawyer but I draft insurance contracts and work with reviewing lawyers closely. As a former software developer I miss version control, partial includes, conditional logic, etc. I am shocked at how poorly supported the business world is by the ubiquity of MS Word.
I’ve been experimenting with Typst now for some time and it has a lot of what I want in creating and versioning documents but I believe may be too technical to become integrated with existing workflows and the non-technical users engaged in the development process. Basically my experience is normal users tune out once you get outside of even basic MS Word.
I really want a great tool to exist but I’m afraid I’m an outlier and unique in my technical ability in this space. Nice to see others interested in such a tool.
Our document editor is powered by Zoho Writer, offering all the capabilities of a word processor along with versioning, document assembly, and automation features. On top of this, we’ve built structured version control, clause-level change tracking, and workflow-integrated collaboration. This enables legal and business teams to work together seamlessly without relying on external editors or juggling redlined Word files over email.
Just sharing in case anyone else here is tackling similar problems or interested in the space.
I think we technical folk need to build technical tools for us to use while we explore the space and iterate on something that the normies will accept.
If you find anyone willing to invest money so a team can spend time on this, please let me know! :-)
this is the actual iceberg. forget ai clause generators and buzzwords, 99 percent of the pain is version chaos. localfirst editor is cool and imagine pairing that with proper gitstyle branching across teams. redlines you can merge without manually eyeball.
There's a reason it's still the standard in the legal industry.
The funny thing is that Word has tons of functionality that techies aren't aware of because they don't actually use it so they keep building products around features Word has had for years. And then they wonder why their startup failed to get any traction.
Redline doesn't appear to be working in Firefox in the web demo you have available. As that is supposed to be your killer feature I would say that your product isn't yet in MVP state. Also, the UI is quite bad and not the slightest bit intuitive; it's the kind of UI that only makes sense once you already have been using it for a while. As you pointed out, most firm lawyers already know and use Litera, so you need to not just be better at your one chosen feature but you also need to be easier and more intuitive to use and you're not.
It's okay for you to be offended by this criticism; this is your baby. But I'm being realistic here. You can choose to ignore critiques and die stillborn, or address these complaints (which other comments have also pointed out) and actually make something that a small but sustainable niche of lawyers will happily use.
I guess all of that is TBD though I suspect based on the tech choices will be way harder than it sounds.
Try the download!
Egui is great!
For a completely unrelated use case, I've started using it as my docx viewer on Linux, and so far it's been great (and solves one of my pain points moving from MacOS).
1: https://www.law.cornell.edu/cfr/text/10/30.19
> Except for persons who manufacture, process, produce, or initially transfer for sale or distribution self-luminous products containing tritium, krypton-85, or promethium-147, and except as provided in paragraph (c) of this section, any person is exempt from the requirements for a license set forth in section 81 of the Act and from the regulations in parts 20 and 30 through 36 and 39 of this chapter to the extent that such person receives, possesses, uses, transfers, owns, or acquires tritium, krypton-85, or promethium-147 in self-luminous products manufactured, processed, produced, or initially transferred in accordance with a specific license issued pursuant to § 32.22 of this chapter, which license authorizes the initial transfer of the product for use under this section.
... and also because it is ambiguous / error-prone / subject to interpretation, especially when figuring out antecedents of pronouns, referents, and textual boundaries.
I tried four times to read the above by paragraph without reformatting it with some parentheses etc, but failed.
I've seen a bulleted list being used for both conjunctions and disjunctions within the same document and in both cases it was not obvious from context (it was related to conditions for receiving funding)
I have a gun with a tritium-based night sight (so the sight dots glow with no light), and it came with documentation about the provenance of each of the three tritium vials.
I also believe it is a crime to break open a sealed tritium vial.
Shame is that monetization around them is even more exploitative than normal textbooks. You don't own them, so you can't keep or resell them once you're done, and you typically lose access to it about a week after the class ends. Many courses also issue assignments and grades through the e-textbook, so you're forced to buy it at a price they decide. Fortunately work reimbursed mine.
I'm curious what was your experience like building this in Rust? Also, how did you find working with egui, what made you choose egui over other UI frameworks?
It's my first Rust project, and I've found Rust to be amazing once you cross over the learning hurdle. The biggest issue was of course the borrow checker, but for a project like this where you aren't really iterating much on the design (as opposed to say a game dev), it lets you fly. It saves you from all the big mistakes and allows you to comfortably use threads and things. No idea how I would have made it without rust_analyzer, though.
Egui was simple to get going, while it has some downsides being an immediate mode UI, those are mostly overcome by the caching necessary for rendering documents, etc.
I bet this is a WASM limitation, I work with WASM and with Rust every day (though sadly not related lol), so I know the pain to some extent. Just please but a banner at the top saying "This preview has limited performance and responsiveness. The native app doesn't have these limitations and can be downloaded here: <link>", or similar (assuming you are aware of serious performance limitations in the browser. If not, and if your native app performs the same, please use profilers to figure out whats wrong).
I'd love to coordinate a demo for you personally if you can spare the time. I'm at drew@tritium.legal or you could drop your info here: https://tritium.legal/demo. I'm familiar with working with and onboarding to regulated IT departments.
[NOTE: some of the speed issues are coming from the pipes clogging up due to the traffic. There's no CDN here unfortunately.]
Transactional practices like RE, funds, capital markets, finance, derivatives, M&A are the target audience.
The roadmap includes a shared history but iManage integration is also in the works. So the experience will target google-docs like collab with something more familiar in terms of version control. That's on the roadmap though.
Can we chat offline? drew@tritium.legal
Speaking of, could we start using version control for keeping track of laws and updating old laws? It seems to me like a much better system than randomly burying in a new law that it strikes out some text from an old law.
IANAL: idk if lawyers dont do pdfs but tried some research papers and PDF rendering could use some love (MacOS)
it's really more blurry than any pdf on chrome https://imgur.com/a/AElOuaA
seems you're doing work on all files when loading, you should be more like lazy-loading?
This beautiful software that looks a bit like VS Code, what did you use to make it? I'm guessing Tauri but curious if you used something else.
e.g. to understand Terms of Use, finance and purchase agreements, that sort of thing?
My pottery teacher runs a law firm though, I’ll show it to her. Do you know if there are many differences in workflow or terminology between the US and UK?
Given that many lawfirms bill by the hour, are there incentives to make their work more efficient? I.e. if a firm were to adopt this tool, can they practically charge more per hour than a firm that does not?
I talked a little about this back in September: https://www.legalinnovators.co.uk/post/legal-innovators-uk-t...
I'd love to run a demo for you or your legal team.
I absolutely love https://www.draftable.com/compare - it’s an incredibly intuitive presentation of diffs from arbitrary documents, with fuzzy matching even between file types. It’s great for everything from “what did my cofounder change in this version of the deck” to “how can I quickly scan to understand how these PDF documents have evolved from a much earlier version.” Be careful with data security if uploading sensitive documents, of course. But it’s as effective a general-purpose diffing tool as one can imagine.
The real leap past this would be contextual AI extracted takeaways during the review or editing process, which begs for a specialized IDE. Makes me excited to see that this space is evolving!
No comments yet
That's probably a dead key issue (one reason custom renderers for web applications are so tedious to program) but I find it very funny to have a dedicated "Dead" key. Useful for people dealing with wills a lot, I suppose!
Edit: same is true for Chrome, so it's probably a Tritium issue and not a browser issue...
I'm fairly certain lawyers exist specifically because this is infeasible.
I am interested in developing software in this space, so these are earnest questions and not criticism.
Absolutely. Overbought. They're owned by Microsoft. Go to a legal tech conference and there are thousands of vendors and not a single MSFT representative. All they want to do is push more Azureware on the deep pockets of profitable firms.
> Is the docx format fully supported?
It will be. There are certainly edge case features that don't render correctly yet, but those will come. The 80% that we care about should work. No data will be dropped, as mentioned elsewhere it will just look bad and gracefully degrade behind the scenes to a safe representation that ensures the data isn't lost.
> Can one person use Tritium without affecting others?
Yes, it's totally private and secure. Using Tritium doesn't require any cloud access or anything like that (other than to phone home with the auto-update or your LLM integration). I'm going to link the history to a separate hidden directory in the filesystem a la .git in the future which will allow some basic multi-editor features.
> Other than tabs, what does Tritium offer that two Word panes and a file browser pane tiled on screen can't cover?
Great question! It does the things lawyers care about: help them pick out symbols (defined terms, specifically) and run diffs (redlines) cheap and quick. It also renders PDFs (using pdfium).
> I am interested in developing software in this space, so these are earnest questions and not criticism.
Drop a line to the email in my bio. I'd love to chat offline.
[Person] - hope you're well! I wanted to put Tritium on your radar. It's a word processor jacked on steroids built just for transactional lawyers.
From built-in defined term annotation to multi-document search/replace to redlining and much, much more, it will help your team work faster and more effectively on existing Word documents and PDFs. You'll even pick up errors from outside counsel.
Tritium runs on Windows, MacOS and even Linux for your most tech savvy lawyers.
Please let me know if that might be good for your legal team, and I'd love to demo it for you."
What would you say if you were going to focus on a pain point and a problem that this specifically solved for you, that it can also solve for the other lawyers who are not using this and that is not being met by the other options?
I have no use for this software personally but I feel like it's pretty important for me to point out the fact that in your license agreement you misspelled the name of the company as Tritium Legal Technlogies (Technl instead of Technol).
Cheers on your product. From the small showcase it seems to be extremely fast. Developers actually caring about performance brings me great joy.
This does not benefit your customers in any way.
It does not benefit their clients, either.
And brain activity around it is a distraction from what your business does.
At best.
Good luck.
I'll have to do another write-up about it sometime, but a lot of Tritium's automated tests are written in docx files. So building for Linux as an afterthought allows an employee to develop from their preferred platform (if it's Linux) while still getting the full experience. Also there is something quite informing about discovering differences between platforms that help you to better understand the capabilities of each.
I also do believe one day we'll see, e.g., crypto startups' lawyers using Linux. And they'll be happy Tritium customers :)
I wish developers would think more as users and not “what would I like” more. I’m also pretty sure that I could count on one hand the number of lawyers that use Linux for any legal work.
There have been a few attempts to use diffing to solve redlining, you should look into why they have failed.
The "Fetch Example" button on the web demo doesn't seem to work. It would be nice if the web demo was pre-loaded with some stuff.
Why would a law firm give up Word for this? That's your competition and unlike techies they're not going to waste time on an MVP, they want and need a finished product.
And to achieve this you would have to create a machine readable format for legal documents, and have a library of them already converted to it.
Then you could have a linter that highlighted that you made a logical mistake or did something wrong from the perspective of a legal guy.