This website displays the Gemini protocol through a web proxy. The content is proxied from gemini://ols.wtf using Kineto.
InVis - Decentralized content sharing for Gemini
This page is currently a draft. More information and details will be added soon...
Recent discussions on the gemini mailists regarding mirroring and syndication feeds made me think about how could we use existing existing technologies to create something similar to a Fediverse on Gemini, content being distributed among other servers based on feeds.
This capsule is a draft for InVis, everything listed here might and will be subject to change
- InVis' role is to provide a way for like-minded people to share gemtexts with unanimous consent among each other in a distributed fashion.
- It achieves this by checking JSON feeds of each module in a station
- A module is a node that is willingly providing gemtext content through a feed and storing content from other modules' feeds.
- A station is a collection of modules that are sharing content based on a predefined set of rules.
- A module feed will be composed of a list of actions commited on the respective module, ordered from latest to oldest action.
- A module will aggregate all the other modules' feeds and commit changes locally based on the action.
- Each module must agree to a single path where the shared Gemini files are located.
- When module A which isn't part of a station chooses to connect to a module B in a station, module B will aggregate module A's feed and pass it to the rest of the modules through its feed. This is called "docking"
- When module A disconnects from module B, module B will stop aggregating module A's feed and inform the other modules in the station to do so trough its feed. This is called "undocking"
Module root directory
The module root directory is the directory that contains your JSON feed file and the gemtext files that were copied from the other modules in the station.
It may or may not coincide with the actual server root directory.
The module directory must contain the feed file in it's root and a directory for each module, named after their hostnames, which contain gemtext from the respective modules.
A feed is a JSON file containing some basic data about the module and a list of actions.
The feed must obligatory contain:
- A list of request paths to the feed file of each module(for example: "gemini://foo.bar/#station/feed.json")
- A lastUpdate field, which indicates when did the current module lastly aggregate the other modules' feeds, in UTC UNIX time.
- A modulePath field, which must indicate the absolute directory of where the module's root directory is located.
- A list of actions that happened on the module, see below
Each action described in a feed must obligatory have a field containing the UNIX time of when the action was commited, in the UTC time zone. An InVis implementation must only aggregate actions that are newer than the previous update time.
Docking and undockings
This is perhaps one of the most complicated part of InVis, but it is still quite simple.
For module A to dock to the station, it must first contact module B's host, who is in the station, and exchange their public certificates. After that, module A will be able to aggregate module B's feed and viceversa. Module B will then announce the other modules in the station about the newly docked module, by adding a "docked" event in its feed, which will contain module A certificate's DER encoded in base64, and its hostname. Module C, a module in the station, when aggregating module B's feed, will find the "docked" event and add the provided certificate to the list of authorized certificates, and the hostname to the modules aggregating.
The "docked" action should have the following fields:
- certificate - base64 of the presented certificate's DER
- time - UNIX UTC time for when the dockingRequest was instantiated
For a module to undock from the station, that is, make all the modules in a station to stop aggregating its feed, it must add an undock action in its feed. Next time the module is aggregated, the aggregator must forget about the feed in cause.
This is the main purpose of the protocol
Feed objects structure