rozzie

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.

That was the now-deprecated implementation at

https://github.com/blues/jsonata-go

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.

https://github.com/jsonata-go/jsonata

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.

https://news.ycombinator.com/item?id=21670035

https://en.wikipedia.org/wiki/The_Hackers_Conference

https://en.wikipedia.org/wiki/Cypherpunk

https://en.wikipedia.org/wiki/Hackers:_Heroes_of_the_Compute...

https://www.stevenlevy.com/crypto

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.

Recently, my head spun around a bit when I saw an experiment done by my team at blues, and I realized it was time for me to dig a bit deeper. https://www.tjvantoll.com/2025/03/17/vibecoding/

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.

https://www.bis.doc.gov/index.php/encryption-and-export-admi...

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.

https://safecast.org/devices/ https://safecast.org/history-of-safecast/ https://safecast.org/about/

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.

Not unrelated, this is quite an amazing device - even before you consider its $9.95 price at Sparkfun.

https://usefulsensors.com/person-sensor/ https://usefulsensors.com/about/

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.

https://apnews.com/article/f10ba58472bcc0e1ababb5fc8ad8d321

LTE feels as though it is going to be an exception to that rule. This is the dawn of eMTC lifecycle

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.

30mm x 35mm, plugging into a standard M.2 Key E socket

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.)

Just so there's no confusion, you linked to the "NOTE-WBEX" which is europe-only. If you're interested in countries covered, it's best to look at "NOTE-NBGL": https://dev.blues.io/hardware/notecard-datasheet/note-nbgl-5...

Truth in advertising: As stated in another response above, if you want to do a real computation you need to factor-in "session setup" overhead. If you config for TCP/IP (unencrypted) your session overhead is about 1kb. If you config for TLS, your session overhead is just under 4KB. Once the session starts, data transfer is super efficient - probably about 250-500 bytes for a half dozen or dozen notes of typical size. Session duration is typically 1-2 seconds.

The other secret of most IoT platforms is that their negotiated rates round sessions to 1KB boundaries. That's insane for IoT. For ours there is no rounding, and the 'practical' rounding is the 40-byte TCP/IP header.

I was using Whispernet as an example of a great user experience; that's all.

There are no tricks and our prepaid/embedded pricing is real, and we will never sell anything for a loss. We're selling commercial IoT and our business must be sustainable. (Free tier of Notehub is an acquisition cost and that cost is extremely low.)

Happy to comment. We've been working on this for several years now and we're super proud of what we see people building and deploying.

The question is a bit general, so let me just give you some related facts.

- Because more than half our customers use this in a battery-powered way (such as a tracker), the normal operating mode (json-configured) is "normally quiescent" (~8uA draw) with the modem powered off completely. You program the sync period and can also kick off syncs manually, for example if you sense an urgent condition.

- In this "periodic mode", syncs are usually take about 15 seconds to register, 1 or 2 seconds to sync, and then hanguup. If you configure for TLS it sends about 4KB for the TLS session setup, and if you don't care about on-wire encryption you can use straight TCP at about 1KB. A half dozen reasonably-sized JSON notes compresses to about 250-500 bytes on the wire.

- Many customers don't use it battery-powered - such as embedding it inside an air handler or generator, etc. When in this mode, you can configure (JSON) it to be connected in a "continuous" mode. Not much downside - just a 1 packet (40 byte TCP header + 1 byte) for a ping every 20m for robustness.

When in continuous mode you get "instant sync" upstream, and get a bonus feature: If you use an HTTPS (JSON) API to send an inbound message to the device, it syncs instantly to the device.

- Our packets are so tiny that nobody ever thinks about actual modem bandwidth. However, you'll notice it when you're using it for firmware update. (We support DFU of modem, of our firmware, and of your own host MCU's firmware.)

We have 2 primary SKUs for the product: our "Narrowband" SKUs based on BG95 which support three RATS: LTE Cat-M1 (~375Kbps), LTE Cat-NB1 (~64Kbps), and GSM (~100Kbps).

For $10 more you can buy our "Wideband" SKUs based on EG91 which supports LTE Cat-1 4G/LTE, 3G, and GSM. These go up to 10Mbps.

Hope you find this interesting.

Yep, your scenario works and it's completely possible and plausible.

Messages are extremely small and efficient OTA (highly optimized and compressed).

The API is JSON and messages are your own unconstrained JSON object, but they're transmitted as compressed binary. (You can also have a binary payload 'attachment' to a JSON message if you so choose.)

Although everything works fine if the messages are individually in the KB's, that's not the design center because of how we manage memory on our (STM32L4R5) MCU.

Things work most efficiently when the app uses lots of small messages. We buffer them in flash, and power-on the modem at user-settable intervals (or conditions) for upload.

Honestly, our thanks to Google's WebSerial folks who helped us to deliver the experience. It's quite wonderful.

http://dev.blues.io

You may be interested to know that the Notecard + Notecarrier-AA, without any host MCU, and with just a couple lines of JSON to configure it, act as a tracker. It has on-board GNSS plus antenna, plus an accelerometer so that it doesn't consume energy when not in motion. (It draws about 8uA when idle.)

Also, if you want to pair it with a $2 ESP32 configured with ESP-AT firmware, the built-in firmware will also do WiFi triangulation.

Yes, we have customers using it as a simple tracker. However, to be clear, this is not a complete "to the glass" tracking solution. All it does is to send tracking data to your service via HTTP JSON. If you have a system that "just wants the data", this is a perfect solution.

I believe the greatest unrealized potential is for product manufacturers to embed cloud connectivity without the end-user needing to do anything to get it working.

The Kindle Whispernet model is my ideal, where you make an up-front decision to buy a cell-enabled product and it just works.

The classic model of monthly charging, activation, deactivation, etc used by the likes of the Apple Watch are not good for IoT because then someone needs to - ensure that your device is certified on a carrier, or get it ptcrb certified - sign up for a carrier contract - acquire/activate the sim - pay a monthly fee per-device (and sometimes also per-fleet) - figure out how to not needlessly pay when devices are broken or end-of-life - and so on.

Of course, if you want to just use the Notecard with your own SIM, you can. The Notecard and all the standard Notecarriers have an external SIM slot (usually used when someone wants to use it in a non-covered country such as China).

The Notecard auto-activates on first use. Without a recharge, it will "just work" until the earlier of a) 10 years b) 500MB of data used

If you need more years or more data we can help, but in the vast, vast majority of narrowband use cases we've found this to be quite sufficient.

It's PTCRB-certified as an "End Product", so it doesn't require the customer's product to be further PTCRB-certified.

It operates in 135+ countries.

It's an embeddable component that is to be installed in product manufacturers' end products. It is not just a reference design.

You can think of the "notecarriers", though, as OSS reference designs or accelerators. They're intended to make it quick to prototype and deploy pilots, before designing the m.2 connector into your own design.

There are no tricks to the Notecard's pricing. The 500MB/10-years of data is embedded within the hardware pricing, which is $49 for North America and $59 for 135+ countries.

What's more, it's "permanent roaming" and you don't need to identify the end-user of the device. It can be used anonymously.