Tue, 03 Feb 2026 07:25:59 -0600jmail

Yesterday I was reaching-out to an old friend who I've lost contact with over the last few years.  Our primary method of contact was Facebook, and I've since been locked-out, so that was that.  Then I was listening to some of his music and realized I might be able to contact him via Bandcamp, and sent him a message.

I didn't hear back, and I have no way of knowing if it's because his contact info at Bandcamp is out-of-date, or maybe he doesn't want to write me back, or maybe he sent me an email and it was eaten by the beast...

This got me thinking about how much I wish Internet email still worked.  I've complained about this a million times so I won't go deep into it again, but tl;dr Google destroyed it with Gmail.

There are of course other ways to communicate electronically but they are all so fractured and incompatible and faction-developing and hardware-intensive that there's still nothing like Internet email used to be: universal, usable from anywhere, on virtually any computer or device, across the shittiest of networks, etc.

I could propose creating something new to take its place, but how would that be any different from all the other things I just complained about in the previous paragraph?  I guess I could make a list and check it off...

* Works on virtually anything

* Works over even the shittiest network

* Universal (should probably define this more)

* Compatible despite factions

Let's start at the top

Whatever this is, it needs to have low enough hardware requirements that it can work on anything.  What does that mean?  Right off the top of my head the best fit I can think of for that is Micropython, since it has both incredibly low hardware requirements and enough features to write a network application.  That's still a higher than ideal bar (not likely to work on 8-bit micros... I don't think at least) but it's pretty low, and should work on most of the things that people connect to the Internet these days.

To me this means compact messages (in terms of data size), possibly "chunkable" (so the whole thing doesn't need to be delivered at once) and probably a store-and-forward network so messages can "hopscotch" their way across the network even when connectivity is intermittent.  This is how Internet email originally worked (and maybe does to some extent still, but I don't think so).  It's also how Meshtastic works (although I'm not sure it uses any sort of "chunking").  Meshtastic might seem like exactly what I'm looking for but it fails a number of the other criteria because it always requires some specialized hardware even if you use it with a "commodity" device*.  

What I have in mind would be designed for TCP/IP networks, at least initially, but it would be smart to keep alternatives in mind so that it's easy to add support for other networks, or at least easily create "bridges" that could allow messages to traverse other types of networks or transports**.

What I mean by this is the ability to send messages to other people regardless of choices like computer and phone brands, operating systems or even "client applications".  For example Signal is great, but you can't send messages to people using Signal from anything but Signal, which means you can only use devices Signal supports.  This limits the use of Signal to a prescribed set of devices, and leaves you at the mercy of Signal's developers to keep things up-to-date, to implement Signal in a way that's reasonable for you, etc.  Consider Internet email on the other hand: there's a million different email clients and they could all sent messages to one-another (back when most people used Internet email).  Part of this is designing a "protocol" that can be implemented by anyone, and part of it is including a universal addressing scheme to direct messages in a way that isn't tied to a specific piece of client, server or networking.

This is somewhat addressed by using a public, shared protocol as described above, but it might need to go further than that.  The purpose of this requirement is to design the system in a way so that it can't be co-opted by one person or one company the way that Google co-opted Internet email.  This might be the hardest requirement because it can't simply be designed to defend against a known threat but must anticipate potential future threats to sovereignty of the system.  

I don't have a perfect answer to this off the top of my head, but making it easy to make clients and other software that are compatible with the protocol might go a long way to "outrun" anyone trying to capture the system, and actively avoiding "profit centers" (ways to make money off controlling the system) might help as well.  Keeping the resource requirements low might help as well, because if it's easy to use the system yourself then you're less likely to want to delegate that to some third party.  Other conveniences like keeping spam and other abuses at bay might help as well.

One possible system could be built on JSFS federation.  Messages are composed however you like and POSTed to a local JSFS instance at the JSFS address of the recipient:

POST http://localhost:7301/.com.jasongullickson/inbox/

The local instance attempts to push the jnode change and message data as jblocks to its' known peers.  If this fails due to the network being down or the peers being unreachable, it retries***.

JSFS authentication, federation (especially propagation) has been discussed in detail elsewhere, so I won't go into much more detail than this here.

On the recipient side, the client polls the "inbox" at whatever frequency the person running the client feels is appropriate.  Since it's polling against another local JSFS instance, polling frequency has no impact on the network.

GET http://localhost:7301/.com.jasongullickson/inbox

Is it really that simple?  Let's work the list

A Micropython implementation of JSFS with federation is in the works, which as discussed earlier would run on almost any piece of hardware with network capabilities.  A client capable of sending and receiving messages in the way described above using such a JSFS instance is easily within the capabilities of being realized in Micropython as well.

JSFS federation natively provides store-and-forward functionality which should be suitable for any type of network connectivity no matter how intermittent, and the block-orientation of JSFS storage (as well as deduplication) should function well even over high-latency and low-bandwidth networks as well as fast, always-on connections.

JSFS addresses do not depend on any external infrastructure for resolution.  They bear a resemblance to DNS names (and are compatible with them), but by no means are they dependent on DNS.  JSFS federation automatically circulates the jnode structures which are used by JSFS to resolve addresses to data in the form of jblocks, and anything capable of running a JSFS instance can participate in the network.

Certainly the proposed implementation traverses factorization in the form of device or operating system fractures, but I'm not sure exactly how it repels other types of attack on the network.  I think by running locally via Micropython the technical and administrative overhead is low enough to avoid the trap of delegating this to a corporation, and given the meager resources needed to run a functional communications system (even large message size and volume would be fairly reasonable by contemporary hardware and networks) things like "free hosting" traditionally used to capture systems like this have less appeal.

The big hole I see is any active form of defending against abuse.  It seems like I've solved this to some degree before with JSFS but I don't recall the details off-hand.  This would need to be addressed if this solution is going to be resistant to companies or other entities which would use providing these features as a way to compel people to delegate hosting, etc. to a third party.

I think I've made a reasonable case for using JSFS to build a new communications system to provide a means of communication akin to that we once enjoyed via Internet email.  I still don't think it's quite as good (if nothing else it won't solve the problem for existing devices that only support Internet email) but it addresses all of the things that I personally find limiting about other electronic forms of communication.

Given this I think it's worth experimenting with.  First I will need to complete the implementation of JSFS with federation for Micropython, but after that a simple proof-of-concept should be fairly straightforward to construct.

* I could certainly be ignorant to things about Meshtastic that invalidate this claim.

** Technically, a store-and-forward system would allow for lots of physical transports since a node could store a message in one physical location and then travel physically to a different location to connect to a separate network and forward the message, essentially a physical transport or "automatic sneakernet".

*** How long it retries could be client-selected, or a network default or both, I haven't thought it through enough yet to say for sure what's best.