# Asynchronous offline and distributed gemini content, by email.

If you are using a screen reader, or if this "decorated" text is not rendering correctly on your client follow the link below.

Prelude

𝕳aving recently discovered the 𝘎𝘦𝘮𝘪𝘯𝘪 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, 𝘎𝘦𝘮𝘪𝘯𝘪 and 𝘎𝘰𝘱𝘩𝘦𝘳 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 𝗙ear 𝗢f 𝗠issing 𝗢ut 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 𝘎𝘦𝘮𝘪𝘯𝘪 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 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

𝕿𝖍e 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.

𝘎𝘦𝘮𝘪𝘯𝘪, 𝘍𝘪𝘯𝘨𝘦𝘳, 𝘎𝘰𝘱𝘩𝘦𝘳, and probably all the other new protocols like 𝘚𝘱𝘢𝘳𝘵𝘢𝘯, 𝘕𝘦𝘹, 𝘛𝘪𝘵𝘢𝘯 – I think there is also 𝘚𝘤𝘳𝘰𝘭𝘭 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 𝘎𝘦𝘮𝘪𝘯𝘪 and 𝘎𝘰𝘱𝘩𝘦𝘳 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

𝕸𝖞 ideal internet is a mesh network of computers , of 𝗲𝗾𝘂𝗮𝗹 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?

𝕻loum 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 𝗼𝗻𝗹𝘆 𝘥𝘦𝘤𝘦𝘯𝘵𝘳𝘢𝘭𝘪𝘻𝘦𝘥 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 𝗻𝗲𝘃𝗲𝗿 going to have something decentralized like email — 𝘁𝗵𝗮𝘁 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 ⚠️

𝗪𝗶𝘁𝗵 𝘁𝗵𝗮𝘁 𝗼𝘂𝘁 𝗼𝗳 𝘁𝗵𝗲 𝘄𝗮𝘆; 𝗵𝗲𝗿𝗲 𝗴𝗼𝗲𝘀:

𝕴𝖋 𝘎𝘦𝘮𝘪𝘯𝘪 was a mailing list, anyone could just bundle their 𝘤𝘢𝘱𝘴𝘶𝘭𝘦 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 𝘤𝘢𝘱𝘴𝘶𝘭𝘦.

The url of the 𝘤𝘢𝘱𝘴𝘶𝘭𝘦 whould just be the file name, and the authors email, followed by a unique 𝘩𝘢𝘴𝘩 𝘯𝘶𝘮𝘣𝘦𝘳.

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

Redundancy

𝕿𝖔 achive redundancy of the content, every posted document should be downloaded and kept by a minimum number of 𝘩𝘰𝘴𝘵𝘴. Let's say 5*.

Those 𝘩𝘰𝘴𝘵𝘴 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 𝘢𝘶𝘵𝘩𝘰𝘳, with CC to the known 𝘩𝘰𝘴𝘵𝘴. The first one available should serve the request, with a reply, and CC to the other 𝘩𝘰𝘴𝘵𝘴 (and 𝘢𝘶𝘵𝘩𝘰𝘳).

To update the docunent, the 𝘢𝘶𝘵𝘩𝘰𝘳, should send an email to the known 𝘩𝘰𝘴𝘵𝘴, with the latest version of the document attached, as well as any subscribers to the document, and also update the 𝘪𝘯𝘥𝘦𝘹. (more about this later)

• The number of 𝘩𝘰𝘴𝘵𝘴, would depend on the total size of the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵.

The index

𝕬𝖓 𝘪𝘯𝘥𝘦𝘹 of every known 𝘤𝘢𝘱𝘴𝘶𝘭𝘦, or 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 hosted on the mailing list; should be kept, and available to any user on request. The 𝘪𝘯𝘥𝘦𝘹 should be updated every time one of the capsules have been changed,

The index — Format

𝕿𝖍e 𝘪𝘯𝘥𝘦𝘹 should begin with an introduction, containing the date of last modification, the version number, and the email addresses of the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴. (more about them later)

Also brief instructions on how to request or host a document on the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵, and the rules of use, should be included.

• The 𝘪𝘯𝘥𝘦𝘹 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 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 𝘢𝘥𝘥𝘳𝘦𝘴𝘴 should follow, that should consists of:
•     - the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 name (spaces should be represented as "-"),
•     - followed by the 𝘢𝘵 character "@",
•     - followed by the 𝘢𝘶𝘵𝘩𝘰𝘳‘𝘴 email address. Example:

pandion's-lair@pandionkarystios@protonmail.com

• After that, the 𝘢𝘥𝘥𝘳𝘦𝘴𝘴𝘦‘𝘴 𝘩𝘢𝘴𝘩 𝘯𝘶𝘮𝘣𝘦𝘳, preceded by the "#" character should follow.
• After that, the tag "hosts" should follow, with the email addresses of all the known 𝘩𝘰𝘴𝘵𝘴, 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 𝘢𝘶𝘵𝘩𝘰𝘳‘𝘴 PGP key
• After that, the tag "name" should follow, providing the name of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵–𝘤𝘢𝘱𝘴𝘶𝘭𝘦* included in quotes.
• Then the tag "URL" should follow providing the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 internet URL if available.
• Then, the tag "desc" should follow, providing a brief description of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 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 𝘩𝘶𝘴𝘩 𝘯𝘶𝘮𝘣𝘦𝘳 of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 𝘢𝘥𝘥𝘳𝘦𝘴𝘴.

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: 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵

The index — Keeping the index

𝕿𝖍e index should be kept and curated by a minimum number of 𝘩𝘰𝘴𝘵𝘴. Let's say 10*

The responsibilities of the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 will include:

• Serving the 𝘪𝘯𝘥𝘦𝘹 to every user that requests it by email
• updating the 𝘪𝘯𝘥𝘦𝘹, everytime some 𝘢𝘶𝘵𝘩𝘰𝘳 notifies them that their 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 has been updated.
• adding new entries to the 𝘪𝘯𝘥𝘦𝘹, everytime some 𝘢𝘶𝘵𝘩𝘰𝘳 notifies them that they wish some new 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, to be hosted on the mailing list.
• allocating 𝘩𝘰𝘴𝘵𝘴 for every new 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.
• allocating 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 to be hosted by any new member, as a form of 𝘳𝘦𝘤𝘪𝘱𝘳𝘰𝘤𝘢𝘵𝘪𝘰𝘯 (more about this later).
• reallocating 𝘩𝘰𝘴𝘵𝘴 to a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 when some 𝘩𝘰𝘴𝘵 becomes unavailable, or unwilling.
• moving 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 to the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 (more about that later), when their 𝘢𝘶𝘵𝘩𝘰𝘳 becomes unavailable
• Adding new 𝘩𝘰𝘴𝘵𝘴, if they request to volunteer in hosting some 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.
• Recruiting new 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, when they lose contact with anyone of their group, to make sure their number stays always, above the required minimum.

• Again depending on the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵‘𝘴 size

Reciprocation

𝕿𝖍e whole system should be based upon 𝘳𝘦𝘤𝘪𝘱𝘳𝘰𝘤𝘢𝘵𝘪𝘰𝘯.

For someone to have their content hosted, they will need to host a number of 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 themselves.

The number of 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 should be more than the number of 𝘩𝘰𝘴𝘵𝘴 of their own 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵. Let's say 7.

So, how does someone publish a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 on the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵?

• First they need to have a PGP key
• create an 𝘪𝘯𝘥𝘦𝘹 entry in their email message body, as described above, with the information they have.
• Send their request, and the 𝘪𝘯𝘥𝘦𝘹 entry to the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴.
• The first available of the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, will:
•     - Add the entry to the 𝘪𝘯𝘥𝘦𝘹, filling in the "hosts" area,
•     - Allocate the required 𝘩𝘰𝘴𝘵𝘴 and reply to the request, with the email addresses of the future 𝘩𝘰𝘴𝘵𝘴 of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵,
•      - Notify the future 𝘩𝘰𝘴𝘵𝘴 of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵,
•      - Allocate the available 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 for the new user to 𝘩𝘰𝘴𝘵, and send their 𝘢𝘥𝘥𝘳𝘦𝘴𝘴𝘦𝘴 and 𝘩𝘶𝘴𝘩 𝘯𝘶𝘮𝘣𝘦𝘳𝘴 to the new user
•      - Notify the 𝘢𝘶𝘵𝘩𝘰𝘳𝘴 of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 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 𝘩𝘰𝘴𝘵𝘴, in the form of a PGP signed attachment.
• Also soon – the new user, should receive the emails for the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 they need to 𝘩𝘰𝘴𝘵 themselfs.
• Hosting a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 means keeping the latest version saved to disk, and sending the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 as an attachment, to anyone that requests it.
• To update the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, one has to send the latest version to the 𝘩𝘰𝘴𝘵𝘴, and the date of revision to the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴. (and any other thing that might have changed in the entry, like the description, or tags etc)
• The more people hosting a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, the more readily available it will be, at any time. So enybody interested in the availability of any 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 could volunteer hosting it, by contacting the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴.

Hosting a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, 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 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 to be reallocated to an other 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.

But in no case are they to refuse serving the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 before that, or to attempt to hinder the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 circulation in any way.

Reciprocation — Responsibilities

• The 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 𝘸𝘰𝘶𝘭𝘥 𝘣𝘦 relieved of the responsibility to host 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴, since the curation of the 𝘪𝘯𝘥𝘦𝘹 is already a full time responsibility: The same applies for the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, due to the potential disk size of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 𝘵𝘩𝘦𝘺 𝘯𝘦𝘦𝘥 𝘵𝘰 𝘩𝘰𝘴𝘵.
• The 𝘩𝘰𝘴𝘵𝘴 would have the responsibility to check their email at least twice per week.
• The 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, once every day.
• The 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, every two days

The archive

𝕿𝖍e 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 should be kept by a minimum amount of 𝘩𝘰𝘴𝘵𝘴, the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴. Let's say— 10.

• When a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 is abandoned by its 𝘢𝘶𝘵𝘩𝘰𝘳, it is moved to the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦.
• the 𝘩𝘰𝘴𝘵𝘴 of the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, should forward it to the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, and a new 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 should be allocated to them, by the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴.
• the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 assume the responsibility af serving the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.
• The archived documents, are placed at the bottom of the 𝘪𝘯𝘥𝘦𝘹, and the "hosts" tag is removed.
• The 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 email addresses are available in the 𝘪𝘯𝘥𝘦𝘹 for anyone to request the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵.
• If someone refuses or is unable to participate in 𝘳𝘦𝘤𝘪𝘱𝘳𝘰𝘤𝘢𝘵𝘪𝘰𝘯 any more, their own hosted 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 will be transfered to the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦.
• An 𝘢𝘶𝘵𝘩𝘰𝘳 whose 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 have been archived due to absence, might ask for the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 to be revived by messaging the 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, and fulfilling the 𝘳𝘦𝘤𝘪𝘱𝘳𝘰𝘤𝘢𝘵𝘪𝘰𝘯 duties.
• The 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 in the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 should never be deleted and should be passed on from one "generation" of 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴 to the next.

Health report.

𝕰very 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 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴, and the 𝘩𝘰𝘴𝘵𝘴 and 𝘢𝘶𝘵𝘩𝘰𝘳 of every 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, 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 𝘩𝘰𝘴𝘵𝘴,
• 1 year for 𝘢𝘶𝘵𝘩𝘰𝘳𝘴,
• 2 weeks for 𝘪𝘯𝘥𝘦𝘹 𝘬𝘦𝘦𝘱𝘦𝘳𝘴,
• 2 weeks for 𝘢𝘳𝘤𝘩𝘪𝘷𝘦 𝘬𝘦𝘦𝘱𝘦𝘳𝘴.

When contact with an 𝘢𝘶𝘵𝘩𝘰𝘳 is lost for the time interval specified, the 𝘢𝘶𝘵𝘩𝘰𝘳‘𝘴 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 is moved to the 𝘢𝘳𝘤𝘩𝘪𝘷𝘦.

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

𝕿𝖍e aggregators issue on 𝘎𝘦𝘮𝘪𝘯𝘪 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 𝘎𝘦𝘮𝘪𝘯𝘪 intentions and philosophy, (𝗜n 𝗠y 𝗛onest 𝗢pinion), 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 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵, 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 𝘪𝘯𝘥𝘦𝘹 itself by putting the updated 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 on the top of the list.
• By the use of each member’s contacts –as relays.
•    - Every 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 𝘢𝘶𝘵𝘩𝘰𝘳 has a number of 𝘩𝘰𝘴𝘵𝘴, and also a number of 𝘢𝘶𝘵𝘩𝘰𝘳𝘴, whose 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 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 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 should not be aggregated this way. because the hosted content, should be 𝘰𝘯 𝘥𝘦𝘮𝘢𝘯𝘥. But the message that a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 have been updated, could be.
• Replies to articles, containing links to the mentioned 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴, could easily be publisized this way.

Management

𝕸anagement of the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵 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 𝘢𝘨𝘨𝘳𝘦𝘨𝘢𝘵𝘪𝘰𝘯 method, for decisions about the organization of the 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵, 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

𝕺bviously, 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 𝘤𝘢𝘱𝘴𝘶𝘭𝘦, should work fine; same goes for on-line links on the general internet.

But a link to an other 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 that is stored on the hard drive, should be a bit more challenging.

for example, if I were to make a link to a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 named foo-bar.gmi that is on a 𝘤𝘢𝘱𝘴𝘶𝘭𝘦 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 𝘓𝘢𝘨𝘳𝘢𝘯𝘨𝘦 because it uses a cache folder as a root for navigation, and not the actual folder, where the 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 is located on disk.

I don't know if it would work with an offline client like 𝘖𝘧𝘧𝘱𝘶𝘯𝘬.

It works wonderfully with a markdown viewer like 𝘔𝘢𝘳𝘬𝘰𝘳 though. The link can be something like:

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

Epilogue

Epilogue — Advantages

𝖀sing a 𝘮𝘢𝘪𝘭𝘪𝘯𝘨 𝘭𝘪𝘴𝘵 to host content, has the advantage.

• that it does not require the use of a server. Anyone can publish a 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵, 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 𝘥𝘦𝘤𝘦𝘯𝘵𝘳𝘢𝘭𝘪𝘻𝘦𝘥 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 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵‘𝘴 impact, and popularity—though there is a privacy concern. (more about this, later)
• It short of solves the 𝘢𝘨𝘨𝘳𝘦𝘨𝘢𝘵𝘪𝘰𝘯 issue, and also direct commmunication is encouraged; no need for a direct messaging, and comments-mentions system.
• And most importantly, it provides redundancy, snd 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 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 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 𝘢𝘶𝘵𝘩𝘰𝘳 and known 𝘩𝘰𝘴𝘵𝘴.
• Large files can be a problem. 𝘋𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴 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 𝘭𝘶𝘧𝘪¹
• There is a privacy issue: the 𝘩𝘰𝘴𝘵𝘴 and 𝘢𝘶𝘵𝘩𝘰𝘳, can monitor who is viewing specific 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴, 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 𝘎𝘶𝘦𝘳𝘪𝘭𝘭𝘢 𝘮𝘢𝘪𝘭². 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 𝘨𝘪𝘵 𝘪𝘥𝘦𝘢³, 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