In its day (1997-2005) Groove was quite a sophisticated architecture and implementation of encrypted collaborative workspaces, using a decentralized P2P architecture augmented by optional store-and-forward relays that enabled fully offline use.
For endpoint authentication it supported direct peer key signing, or org-signed certs, or any combination.
Arbitrary collab apps could be built on a blockchain-like signed/encrypted transaction log with decentralized global ordering and automatic rollback, transaction insertion, and play forward. The most used apps were file folders, discussions, chat (with PTT), calendars, sketchpad, collaborative browsing, and more.
Interestingly, for several years, it was a "killer app" for those who needed confidentiality: USAID and numerous NGO's, US DoD, joint and coalition forces operating in Iraq, all the three letter agencies trying to collaborate across silos immediately post-9/11.
Quite a testament that decentralized architectures truly work when security is paramount. And also, concrete proof that even after immense investment, there is little appetite for decentralized solutions in enterprise and consumer domains.
Some background on one of the other two golang implementations mentioned in the comments.
Years ago I hired an Upwork contractor to port v1.5.3 to golang as best he could. He did a great job and it served us well, however it was far, far from perfect and it couldn't pass most of the JS test suite. The worst was that it had several recursion bugs that could segfault with bad expressions.
Early in 2025 I used Claude Code and Codex to do a proper, compliant port that passes the full set of tests and is safe. It was most certainly not a trivial task for AI, as many nuances of JSONata syntax derive from its JS roots.
Regardless, it was a great experience and here's the 2.0.6 AI port, along with a golang exerciser that lets you flip back and forth between the implementations. We did a seamless migration and it's been running beautifully in prod in Blues' Notehub for quite a while - as a core transformation capability used by customers in our JSON message pipeline.
FidoNet was a simply wonderful innovation, and it was a reflection of the creativity of its author - Tom Jennings - and his views of community and identity.
https://grokipedia.com/page/tom_jennings
Tom was working on FidoNet in 1984, the same time my Iris co-founders and I had begun work on what became Lotus Notes. Architecturally, those of us who were working on collaborative systems in that era were shaped by the decentralized architecture of USEnet - inspired and motivated by the observation that a community could be brought together by something technologically as simple as uucp.
Both dial-up focused, Tom took this in the direction of a decentralized BBS, while I took it in the direction of masterless replicated nosql databases we called 'notefiles'. Identity being at the core, Tom was focused more on public community while we focused on private collaboration.
It was such an exciting time for emergent decentralization, shaped by a strong dose of 60's idealism.
I've been annoyed lately by posts (elsewhere) by vibe-coding startup CEOs who think they can build companies without developers. These are not serious people.
And so, over the past few weeks I've done an interesting CEO vibe-coding experiment of my own, trying to test the limits and to see how close I could come to building something that could be regarded as 'ship quality'.
Did I succeed? You be the judge.
I didn't write a single line of code in this repo, but, as HN would expect, my instructions were voluminous and needed to be quite detailed. An interesting experience, nonetheless.
I began recruiting for what became Azure in Jan 2006. I was chief software architect / cto at the company. Amitabh Srivastava and the legendary Dave Cutler were the leads, with Dave focused on the hypervisor. (I'd met Dave in the 80's when he was at DEC and I was at DG.)
The project was in my team (CSA labs) but was cross-funded behind the scenes by Kevin Johnson, the president of Server & Tools. KJ & I did this because there was passive-aggressive resistance to a 'cloud first' design/architecture philosophy from within his org, where there was a deeply-rooted belief that enterprise servers and ops management tools would adequately scale-up.
KJ bought in and was all-in, as was the 'tools' part of his org (Soma & ScottGu). SteveB initially didn't quite know what to make of my desire and myriad efforts to fundamentally transform the company from packaged products toward services, and he had to cope with some of the wake I was leaving. It wasn't all smooth. But he believed in me and helped me to recruit internally, which was essential.
My explicit cross-funding agreement with KJ, my peer, was that when I decided it was the 'right time', I'd hand off my Azure org and it would be re-merged into S&T in more-or-less a 'reverse merger', with cloud leadership taking over server.
I launched Azure at PDC 2008 with what today we'd call lambda's (functions-as-a-service based on .net) & blobs & cloud database as the core services. Why no linux or windows VMs? They were absolutely part of day 1 plans, but a major political ploy from within KJ's team ('this will kill the server business') resulted in an active decision (mine) to defer until post-launch. It wasn't a technology issue, nor was it an OSS issue; the team believed in OSS & Linux. But shipping was top priority, and we shipped.
When I ultimately left the company in 2011, it was time to do the reverse merger that KJ and I had planned. A proven, super-talented manager from Bing that everyone loved, Satya, was chosen to lead the org as it was moved into S&T upon my departure. James Hamilton, the architect of Azure's relational DB, left for AWS.
Ultimately, under Satya, ScottGU & co ended up re-plumbing much of the original code with a by-then-ready Windows hypervisor, VMs & Linux, and all that you see today. By then the org finally was aligned and 'believed', and SteveB was genuinely 'all in'.
Getting products from 0 to 1 is sometimes a challenging process involving incredible people and stamina from believers at every level. In this case I'd say it was worth the effort.
Tangentially-related, it remains surprising that many U.S.-based developers I've spoken with fail to realize that they need to obtain an Export Control Classification (ECCN) from the US Dept of Commerce's Bureau of Industry and Security (BIS) before publishing their apps in the app store or otherwise making them available on the net. And then devs need to submit annual updates for their products.
Most will get a mass market exemption under 5D992, but a surprising number of modern applications making 'interesting' uses of crypto will need export licenses.
Thx for clearing the rights and for releasing, Scott. And of course thanks to Microsoft and IBM.
It would be fun at some point down the road to get some of the older code building and running again - particularly '84/'85-vintage Windows & Notes builds. Quite a lot of work, though, not just because of hardware but also likely because of toolchain gaps.
At Software Arts I wrote or worked on the IL interpreter for the TRS 80 Model III, the DEC Rainbow, the Vector Graphic, the beginnings of the Apple Lisa port, as well as the IBM PC port. To put you into the state of mind at the time,
- in the pre-PC era, the microcomputer ecosystem was extremely fragmented in terms of architectures, CPUs, and OS's. 6502, z80, 68K, z8000, 8088. DOS, CPM, CPM/86, etc. Our publisher (Personal Software) wanted as much breadth of coverage, as you might imagine
- one strong positive benefit of porting from 6502 assembly to IL and using an interpreter was that it enabled the core code to remain the same while leaving the complex work of paging and/or memory mapping to the interpreter, enabling access to 'extended memory' without touching or needing to re-test the core VisiCalc code. Same goes for display architectures, printer support, file system I/O, etc.
- another strong benefit was the fact that, as the author alludes to, the company was trying to transition to being more than a one hit wonder by creating a symbolic equation solver app - TK!Solver - that shared the interpreter.
Of course, the unavoidable result is that the interpreter - without modern affordances such as JIT compilation - was far less snappy than native code. We optimized the hell out of it and it wasn't unusable, but it did feel laggy.
Fast forward to when I left SoftArts and went across the street to work for my friend Jon Sachs who had just co-founded Lotus with Mitch Kapor. Mitch & Jon bet 100% that the PC would reset the ecosystem, and that the diversity of microcomputers would vanish.
Jon single-handedly wrote 1-2-3 in hand-tuned assembly language. Yes, 1-2-3 was all about creating a killer app out of 1.spreadsheet+2.graphics+3.database. That was all Mitch.
But, equally, a killer aspect of 1-2-3 was SPEED. It was mind-blowing. And this was all Jon. Jon's philosophy was that there is no 'killer feature' that was more important than speed.
When things are moving fast and the industry is taking shape, you make the best decisions you can given hunches about the opportunities you spot, and the lay of the technical and market landscape at that moment. You need to make many key technical and business decisions in almost an instant, and in many ways that determines your fate.
Even in retrospect, I think the IL port was the right decision by Dan & Bob given the microcomputing ecosystem at the time. But obviously Mitch & Jon also made the right decision for their own time - just a matter of months later. All of them changed the world.
It’s quite a wonderful set of globally-distributed volunteers brought together by varying passions - from hardware hacking to citizen science.
Whether from fixed or mobile sensors, whether from radiation or air quality sensors, all data is CC0-licensed at birth and is freely available for download.
Beyond being 60-bits, programming the 6400/6500/6600/6700 was interesting and memorable in other ways.
- Ones' complement (rather than two's complement) binary representation of integers, and thus the need to cope with "-0" in your code. Modern programmers are surprised that there was a day when "-1" had a different binary representation than today.
- The CPU/CPUs were not actually 'in charge' of the machine. There were ten 12-bit processors called PPU's (peripheral processing units) which did all I/O, and which had the unique capability of doing an "Exchange Jump" instruction to do a CPU task switch. In a sense, the CPUs were 'compute peripherals' to the PPUs.
- The architecture was fascinating in terms of memory hierarchy. The "centeral memory" used by the CPUs was augmented by a much larger "extended memory" (ECS - Extended Core Storage) with block transfer primitives. One could implement high-scale systems (such as the one I worked on - PLATO) that smoothly staged data between CM, ECS, and disk.
In those days, there was a necessarily-direct relationship between the machine language (the bit encoding of instructions for operations & registers) and the assembly language (COMPASS). As a developer it was incredibly enjoyable because, in Ellen Ullman's words, you felt very 'close to the machine'.
"Now, no one bats an eye if you ship the most secure crypto you want."
The most surprising thing to me is that, in speaking in the past several years with younger entrepreneurs, they're not even aware of the obligation to file for an export license for any/all software containing crypto (such as that submitted to the App Store).
I've not yet seen a case in which a mass market exemption isn't quickly granted, but devs still need to file - and re-file annually.
I use my HP-16C several times every week while debugging Notecard firmware. Yes, math is integrated into IAR EWARM and there's always Hex Calc on my iPhone. But there is something comforting about grabbing this same little artifact that has been on my desk since the days when I was debugging Lotus Notes using symdeb.
Tangentially related: if you're fascinated about how all of this vintage equipment used to work, and if you find yourself near downtown Seattle on a sunday with an hour or two to spare, I strongly encourage a visit to: https://www.telcomhistory.org/connections-museum-seattle/
It's an incredibly rare opportunity to see geek geezer volunteers keep this central office telephone switching equipment up and running, and they'll proudly show you how it all works. A combination of aging techs and students constantly maintain equipment ranging from crossbar switches to an ESS.
It's a labor of love, and you'll want to leave something in the tip jar just to say thanks.
YMMV but our experience with Cat-M has been very good with regard to speed and general coverage. (Probably because it was just a tower software for LTE eNodes.) 300Kbps+ seems to be the norm.
All of USB, I2C, low power UART (9600 fixed), and high speed USART.
They all equivalently are JSON request/response ports. I2c uses a simple serial-over-I2C protocol.
Most customers use the I2C or low power UART interfaces because the device only uses ~8uA when listening on those ports. (Our internal MCU can listen on those ports while in STOP2 mode.)
For endpoint authentication it supported direct peer key signing, or org-signed certs, or any combination.
Arbitrary collab apps could be built on a blockchain-like signed/encrypted transaction log with decentralized global ordering and automatic rollback, transaction insertion, and play forward. The most used apps were file folders, discussions, chat (with PTT), calendars, sketchpad, collaborative browsing, and more.
Interestingly, for several years, it was a "killer app" for those who needed confidentiality: USAID and numerous NGO's, US DoD, joint and coalition forces operating in Iraq, all the three letter agencies trying to collaborate across silos immediately post-9/11.
Quite a testament that decentralized architectures truly work when security is paramount. And also, concrete proof that even after immense investment, there is little appetite for decentralized solutions in enterprise and consumer domains.