# Asynchronous offline and distributed gemini content, by email.

Prelude

Having recently discovered the Gemini protocol, I am still exploring and discovering new and interesting things. It is an exiting trip that made me realize a few things about the state of the internet, and my relationship with it.

Although I always despised the commercialization of the internet, and was looking for an alternative way, Gemini and Gopher seemed to me, too niche to be relevant.

I was looking for ways to make the web work for me, with privacy add-ons, ad blockers, and hardened browsers.

A couple of months on Gemini, though, have made me realize, that it was actually Fear Of Missing Out that was keeping me back.

There is enough content on Gemini, to keep me interested and occupied. More than I can handle on my limited free time actually.

I have come to love the long form text, and slow pace of interaction that prevails in this part of the internet. It is overall a better way of human interaction.

Not that Gemini does not have shortcomings of its own, or that the web is of no value any more.

But the internet in totality is a bit too much of a distraction as I have come to realize.

It is a wonderful window to the world that I couldn't do without since I have discovered it, and also a great way for information and knowledge to be exchanged.

But one should not stay all day looking out the window, afraid they might miss something interesting. This way nothing interesting will actually happen to them, or they will not actually do anything interesting.

Ploum expressed that thought in his article.

And also, our brains are a bottleneck in the case of the internet. We are simply not intellectually capable of handling information, in such a rapid pace.

I NEED TO SLOW DOWN!

I need to limit my access to so much information, so that I can ingest what I read, ponder on them, and turn them into knowledge.

Knowledge, that will shape my thoughts and opinions on things. Knowledge that will further my seek for wisdom.

My grivances with internet in general

The World Wide Web is not really optimal to serve the role of interconnecting people. It relies on ISPs, and can be brought down, censored and controlled.

The cost and complexity of running your own server makes entry to self hosting your content, almost impossible for most people. At least those that are not into the technicall aspect of computing.

Thus the content of internet is centralized into silos of mega corporations.

Gemini, Finger, Gopher, and probably all the other new protocols like Spartan, Nex, Titan – I think there is also Scroll now – make things easier by reducing the complexity, and the cost.

But the underlying problem is not really addressed In My Honest Opinion.

When I decided to make my own capsule, I was in no way prepared or willing to deal with the hassle of optaining a static IP from my ISP, or having a machine running on my basement 24/7, and dealing with security, and maintenance; just to serve a few stupid ideas, that come through my mind.

I mean—I don't even know if it is worth the electricity consumed here!

It's not that I am some big thinker or anything – I am just an average guy!

So I hosted my capsule on the midnight.pub, and Im really grateful for their services.

Plenty of options for hosting on Gemini and Gopher exist. Like pubnixes, the rawtext club smoll.pub, the tildeverce etc, that make things easy and affordable – and that is probably due to the simplicity, that is a feature on those protocols.

But still as solderpunk put's it:

Protocols like Gemini and Gopher are an effective salve against many of the miseries inflicted by the modern web, but by no means do they solve *all* the web's problems. All three systems share the same big picture architecture, namely that the default pattern of usage is that content lives in exactly one place, a server which is online 24/7, 365 days a year and accessible from anywhere on Earth, and that to consume this content you request a copy of it at the instant of consumption, render it to the screen and then discard it (perhaps after a relatively brief cache lifetime), leaving no persistent copy, with the understanding that if you want to read something again next week or month or year you'll just request a fresh copy and do all this again.

My ideal internet

My ideal internet is a mesh network of computers , of EQUAL nodes that share the load of distribution, and storage of all information, without being able to know anything about any other node, or who is viewing that.

Sure there are a lot of projects out there that attempt to do just that. And if I was a developer, I would be all over those, trying to put my piece of stone in building them.

But looking at the complexity of those things makes my not technical head hurt.

People need to write their content, send it to the internets, and then it should stay there available to everyone else, untill entropy turns every hard drive into loose fundamental particles.

Solderpunk in this article, proposes git as an easy way of making Gemini more distributed, and available offline.

And after reading this, I was wondering, why not Zoidberg? 🦑—I mean why not email?

Why not email?

Ploum in the offmini article states:

But wait, there’s more! By putting encrypted files in a capsule, you could send messages to the owner of that capsule. Oh My Goodness! Being able to communicate without that awful mail stack (IMAP/SMTP/MIME are insane protocols and, as a result, no software handle them correctly).

I guess the email protocol is not universally loved, and really I can't claim to understand the technical aspect of those things, but hear me out.

Email is probably the ONLY decentralised protocol in existance that is widely and universally adopted.

Everybody and their dog, have an email address.

Sure —google has managed to dominate it, but in no way does it have control over it.

Various attempts are under way to create something new and better, but we should make no mistake. In the current state of the world, we are NEVER going to have something decentralized like email — THAT popular!

And this is probably because email developed before the web was even conceived.

Mailing lists existed long before the web, forums, or social media, And still exist to this day.

Implementation

⚠️ Disclaimer. Anything I write here, are just thoughts with limited technical knowledge. I can not claim of having a well thought out blueprint of the thing that I am proposing.

I have possibly made assumptions that are not technically feasible or just plain stupid. Feedback is welcome, and if I wasted your time—Apologies ⚠️

WITH THAT OUT OF THE WAY, HERE GOES:

If Gemini was a mailing list, anyone could just bundle their capsule in a zip file, sign it with pgp, and send it as an attachment to everyone else.

And anybody could send a message to the group requesting the latest version of the capsule.

The url of the capsule whould just be the file name, and the authors email, followed by a unique hash number.

Someone that has the latest version stored, could just serve the request, when they receive the message.

Redundancy

To achive redundancy of the content, every posted document should be downloaded and kept by a minimum number of hosts. Let's say 5*.

Those hosts would assume the responsibility of serving the content, to anyone that requests it by email message.

So, for a user to access the content, they would need to send a request by email to the document's author, with CC to the known hosts. The first one available should serve the request, with a reply, and CC to the other hosts (and author).

To update the docunent, the author, should send an email to the known hosts, with the latest version of the document attached, as well as any subscribers to the document, and also update the index. (more about this later)

• The number of hosts, would depend on the total size of the mailing list.

The index

An index of every known capsule, or document hosted on the mailing list; should be kept, and available to any user on request. The index should be updated every time one of the capsules have been changed,

The index — Format

The index should begin with an introduction, containing the date of last modification, the version number, and the email addresses of the index keepers. (more about them later)

Also brief instructions on how to request or host a document on the mailing list, and the rules of use, should be included.

• The index should be a plain text file ".txt"
• Every entry should be one line only.
• Every entry should begin with the date of last modification, in the format YYYY-MM-DD
• Separator character should be a blank space " ".
• Aftet the date, the document's address should follow, that should consists of:
•     - the document's name (spaces should be represented as "-"),
•     - followed by the 𝘢𝘵 character "@",
•     - followed by the author‘𝘴 email address. Example:

pandion's-lair@pandionkarystios@protonmail.com

• After that, the addresse's hash number, preceded by the "#" character should follow.
• After that, the tag "hosts" should follow, with the email addresses of all the known hosts, seperated by ";" and icluded in quotes. Example:

hosts="host1@mail.com;host2@mai.com;host3@mail.com;host4@mail.com;host5@mail.com"

• Then the tag "PGP" should follow providing the author's PGP key
• After that, the tag "name" should follow, providing the name of the document–capsule* included in quotes.
• Then the tag "URL" should follow providing the document's internet URL if available.
• Then, the tag "desc" should follow, providing a brief description of the document's content, included in quotes.
• After that, tags could follow, put I would suggest the use of the "+" character instead of "#" so as to not be confused with the actual hash number of the document's address.

This text file can be wrapped, by text editors for ease of viewing. Performing searching and shorting commands, should be straightforward.

• From now on, refered to as: document

The index — Keeping the index

The index should be kept and curated by a minimum number of hosts. Let's say 10*

The responsibilities of the index keepers will include:

• Serving the index to every user that requests it by email
• updating the index, everytime some author notifies them that their document has been updated.
• adding new entries to the index, everytime some author notifies them that they wish some new document, to be hosted on the mailing list.
• allocating hosts for every new document.
• allocating documents to be hosted by any new member, as a form of reciprocation (more about this later).
• reallocating hosts to a document𝘴 when some host becomes unavailable, or unwilling.
• moving documents to the archive (more about that later), when their author becomes unavailable
• Adding new hosts, if they request to volunteer in hosting some document.
• Recruiting new index keepers, when they lose contact with anyone of their group, to make sure their number stays always, above the required minimum.

• Again depending on the mailing list's size

Reciprocation

The whole system should be based upon reciprocation.

For someone to have their content hosted, they will need to host a number of document𝘴 themselves.

The number of document𝘴 should be more than the number of hosts of their own document. Let's say 7.

So, how does someone publish a document on the mailing list?

• First they need to have a PGP key
• create an index entry in their email message body, as described above, with the information they have.
• Send their request, and the index entry to the index keepers.
• The first available of the index keepers, will:
•     - Add the entry to the index, filling in the "hosts" area,
•     - Allocate the required hosts and reply to the request, with the email addresses of the future hosts of the document,
•      - Notify the future hosts of the document,
•      - Allocate the available documents for the new user to host, and send their addresses and hash numbers to the new user
•      - Notify the authors of the documents that the new user is going to host, and give them the new user's email address
• The new user should then mail the document to be hosted, to the allocated hosts, in the form of a PGP signed attachment.
• Also soon – the new user, should receive the emails for the document they need to host themselfs.
• Hosting a document means keeping the latest version saved to disk, and sending the document as an attachment, to anyone that requests it.
• To update the document, one has to send the latest version to the hosts, and the date of revision to the index keepers. (and any other thing that might have changed in the entry, like the description, or tags etc)
• The more people hosting a document, the more readily available it will be, at any time. So enybody interested in the availability of any document could volunteer hosting it, by contacting the index keepers.

Hosting a document, does not mean endorsing – so one should not be concerned about the content.

But in the case that someone feels they can not host a particular document for moral, ethical, religious etc reasons, they can request from the index keepers to be reallocated to an other document.

But in no case are they to refuse serving the document before that, or to attempt to hinder the document's circulation in any way.

Reciprocation — Responsibilities

• The index keepers would be relieved of the responsibility to host document𝘴, since the curation of the index is already a full time responsibility: The same applies for the archive keepers, due to the potential disk size of the documents they need to host.
• The hosts would have the responsibility to check their email at least twice per week.
• The index keepers, once every day.
• The archive keepers, every two days

The archive

The archive should be kept by a minimum amount of hosts, the archive keepers. Let's say— 10.

• When a document is abandoned by its author, it is moved to the archive.
• the hosts of the document, should forward it to the archive keepers, and a new document should be allocated to them, by the index keepers.
• the archive keepers assume the responsibility af serving the document.
• The archived documents, are placed at the bottom of the index, and the "hosts" tag is removed.
• The archive keepers email addresses are available in the index for anyone to request the document.
• If someone refuses or is unable to participate in reciprocation any more, their own hosted document will be transfered to the archive.
• An author whose document have been archived due to absence, might ask for the document to be revived by messaging the index keepers, and fulfilling the reciprocation duties.
• The documents in the archive should never be deleted and should be passed on from one "generation" of archive keepers to the next.

Health report.

Every first day of every month, all groups should report to each other, to make sure that contact is maintained, and everyone is available, and willing.

So the index keepers, the archive keepers, and the hosts and author of every document, should email one another to report presence.

If contact is lost by someone, a replacement should be found in due time.

The time of absence for anyone to be replaced, should be set beforehand.

It could be something like:

• 1 month for hosts,
• 1 year for authors,
• 2 weeks for index keepers,
• 2 weeks for archive keepers.

When contact with an author is lost for the time interval specified, the author's document is moved to the archive.

If someone Is going to be unable to carry out their duties for a period longer than the prearranged, they should notify the interested parties of their absence, so they may decide how to best deal with the situation, like looking for a temporary replacement.

Aggregation

The aggregators issue on Gemini has been discussed quite a bit, and there seems to be no clear cut solution.

On the one hand, aggregator sites introduce a form of centralization, that is not in line with the Gemini intentions and philosophy, (In My Honest Opinion), but on the other hand, they do work really well in content discoverability.

And there is also the issue of moderation –with all the power and responsibility that it entails.

In a mailing list, aggregation should not be a real problem though – since this is the primary function of the medium.

A couple of methods for this to be accomplished without the need for a central authority, are:

• The index itself by putting the updated documents on the top of the list.
• By the use of each member’s contacts –as relays.
•    - Every document's author has a number of hosts, and also a number of authors, whose documents they host themselves.
•     - To relay any message to the whole group, one can send it to all their contacts, using a message title, starting with the word "aggregate", and on their turn, they will forward it to all of their contacts, and so on. The message will travell like a ripple, to every last member of the list.
• An updated document should not be aggregated this way. because the hosted content, should be on demand. But the message that a document have been updated, could be.
• Replies to articles, containing links to the mentioned documents, could easily be publisized this way.

Management

Management of the mailing list should be done with no central authoriry. Because aurhority gives power, and power corrupts.

I propose a poll system that would make use of the aggregation method, for decisions about the organization of the mailing list, and general meta discussions.

I have not really come up with a method for the voting to be anonymous though.

If any interest on this whole theoretical idea manifests itself, I will have to come up with something.

Or someone might have a better idea. I would love some feedback!

Moderation

Obviously, there should be some method of moderation, because unfortunately—people suck!

But I am strongly against the existance of some moderator, because moderators are people too; and people suck!

And people with power, suck even more!

So probably, the poll method should decide for every moderation action, case by case.

Links

Relative links on the same capsule, should work fine; same goes for on-line links on the general internet.

But a link to an other document that is stored on the hard drive, should be a bit more challenging.

for example, if I were to make a link to a document named foo-bar.gmi that is on a capsule named example-capsule@author@mail.com, the link should look something like:

=> ../example-capsule@author@mail.com/foo-bar.gmi check out this awesome link!

However I have not managed to make it work in Lagrange because it uses a cache folder as a root for navigation, and not the actual folder, where the document is located on disk.

I don't know if it would work with an offline client like Offpunk.

It works wonderfully with a markdown viewer like Markor though. The link can be something like:

[External link](../example-capsule@author@mail.com/foo-bar.md) 

Epilogue

Epilogue — Advantages

Using a mailing list to host content, has the advantage.

• that it does not require the use of a server. Anyone can publish a document, with zero cost and efford.
• Also it does not require any new technologies, to be developed.
• It piggibacks on existing technologies, and protocols, but it relies mainly on the network of people, interconecting through various decentralized services; like a self hosted email client, or an on-line mail service.
• It can be structured in a way, that no central authority is in control.
• It encourages direct communication among it's members, creating a community culture.
• It provides some feedback on the hosted document's impact, and popularity—though there is a privacy concern. (more about this, later)
• It short of solves the aggregation issue, and also direct commmunication is encouraged; no need for a direct messaging, and comments-mentions system.
• And most importantly, it provides redundancy, and the offline internet experience that Solderpunk and Ploum was talking about.

Epilogue — Drowbacks

• An obvious drowback, is that the content can not be instantly available the first time it is requested.
• Naturaly only static documents can be hosted, because there can be no backend service.
• Links to the hosted content can not function when the content is not already bownloaded, exept maybe for a "mailto:" link to the author and known hosts.
• Large files can be a problem. Documents should remain within a logical size limit, so hosting media, would be problematic. The only solution I can think of, is using some torrenting technology for large files – some dedicated torrent tracker could even be created –, or something like Lufi¹
• There is a privacy issue: the hosts and author, can monitor who is viewing specific documents, and this can be used for profiling and targeted adds.
•     - Email can be quite anonymous though, if someone uses an on-line service dedicated to this use, or even Gurrila mail². So the content can not easily be linked to the actual person viewing it—if precautions are being taken.
• Obviously email is plagued by spam.

I recently realized that Solderpunk's git idea³, has started being implemented.

I hope this goes well, and I was wondering if a mailing list proposal like this, could be complementary to a git based gemini.

I am not familiar with git, but I have the impression, that git could operate over email—or I could be completely wrong!

One thing I would like to point out about git though, that probably most people on Gemini do not realize, is that the average user, does not know how to use it.

It is a tool for programmers. Sure—other people can find uses for it, like note keeping etc, but I feel that it is kind of intimidating for some average person; even if they love technology, like I do.

I have thought about looking it up; but I kind of never thought of a use for it.

I am just mentioning It, because it seems that everybody in this space is a coder of some kind, and naturally, git would seem quite trivial to them.

Anyway this post has turned out quite long, so I will put it to rest for now.

It is still in early stage, and I plan to update it, if I see any interest in It.

Relevant links

Document's changelog

2024-04-20 Added a screen reader friendly version or the article, for accessibility reasons.

❇️ ❇️ ❇️

🧭 Site navigation