An idea for a gossip messaging protocol (Re: The Monstrosity that Email Has Become)

Posted on Thursday October 21, 2021

I recently read thought-provoking response to another gemininaut's post regarding the late state of e-mail. In that response, the author enumerated some of the characteristics of a physical (paper) letter, and contrasts them with the characteristics of e-mail as we know it today.

The (response) post in question

At the end of their post, the author asks us what we can imagine in terms of a messaging protocol that shares more characteristics with snail mail than conventional e-mail does.

Immediately I was reminded of a file I had written and almost forgotten about, describing an idea I'd had for a decentralized messaging service. The contents of the note are rather technical, and I wrote it back in February of this year so there are several points in it that are misinformed. I wanted to post it to my gemlog nonetheless, in the spirit of sharing knowledge.

I don't have any delusions that this is a particularly novel or unique idea, it's just something that I thought sounded interesting and decided to jot down one day. I'm sure it's already been tried.

What follows is the contents of that file, cleaned up for the gemtext format:

---

Key terms

Backround

Encrypted message traffic being transmitted over traditional infrastructure (network cables, transmission lines, undersea cable, ISP backbones) can be intercepted, tracked, or otherwise interfered with by state actors and ISPs. Popular messaging services such as Signal rely on a central network of servers owned and operated by a single entity. Whether or not those service providers can access the contents of the (hopefully) encrypted message traffic they facilitate, the transmission of data to and from their servers still provide ISPs and state actors a means of interference and invasion of privacy.

One possible means of reducing the likelihood of interference with our communications by external actors is by circumventing traditional telecommunications infrastruction entirely. This can be accomplished by passing encrypted messages between users' devices over LAN connections (or other non-internet means). People physically travelling and connecting to networks shared with other people provides a means of moving messages from one point to another. This mechanism of information exchange is analogous to people passing paper notes from one person to another. I'm not sure if the term applies exactly, but I think that this is related to the concept of a "Gossip Protocol".

The obvious drawback to transmitting data this way is that messages can take an unpredictably long time to reach their intended recipients, and indeed may never be received. The likelihood of messages being successfully received can be improved by incentivizing users' traveling and putting themselves in the position to exchange message traffic with other users.

Goals

I want to develop a protocol for facilitating secure, anonymous messaging between disparate users that is transmitted solely via hopping between other users' devices directly without traversing the web. Such a protocol has the potential to enable wide-ranging, unmolested communication that is truly decentralized, having no single point of failure or central authority.

In order to make such a means of communication viable, I want to build a system on top of the protocol that "gameifies" participation in message exchange. Users can be incentivized to compete with one-another by being rewarded for participating in successfully sending messages to their intended recipients.

Design:

Messages

Messages are the data interchange format that make up the content sof all secure traffic that takes place across the decentralized network. Messages are encoded as ASCII (TODO: unicode?) characters in the following format (line breaks added for clarity):

Each message is comprised of the following named components:

Agents

Agents are the nodes that make up the decentralized web of communications traffic that this protocol facilitates. They will typically be associated with a single user. It's likely that some users may choose to create agents that are stationary and run on a fixed piece of hardware. So-called "fixed agents" have interesting implications in terms of network reliability and gamification mechanics. Agents must embody the following characteristics:

Broadcasts

While an agent is connected to a WLAN or similar, it must broadcast hashes of its cached messages to other agents on the network. These broadcasts must each consist of a string in the following plaintext ASCII format (line breaks added for clarity):

The broadcast is message is described as follows:

While an agent is connected to a WLAN or similar network it must listen for broadcasts from other agents.

When an agent receives a broadcast, it should compare the message hash contained therein with hashes of the messages stored in its cache. If the broadcast's hash does not match any of the recipient's cached messages, then the recipient should request a copy of the corresponding message from the broadcaster. The request should be sent via TCP to the address and ports specified in the broadcast's ADDR field. It should consist of the following (line breaks added for clarity):

The meanings of the fields are the same as those in the broadcast message format.

Exchange

The broadcaster, upon receiving the above request in response to its broadcast, should respond to the request with the full body ofthe requested message as described at the beginning of this section.

Upon receiving the full body of the requested message from the broadcaster, an agent should perform the following checks:

An agent should periodically check for expired messages in its cache and delete them.

Authoring

An agent wishing to send a new message should follow the following procedure:

An agent caching and forwarding a message should not alter the message's TTL. In the future there should be a safeguard against this.

Example Scenario

Tianliang wishes to send Arthur a message. They have previously met in-person and exchanged contact information, including their public keys.

Tianliang packages up their message and it's stored in their device's cache. They then go to a coffee shop and connect to its wi-fi network.

Also on the wi-fi network is Kain, who happens to be standing in line at the register.

Tianliang's device broadcasts that it has a message. Kain's device receives that broadcast and requests a copy of the message.

Tianliang's device sends a copy of the requested message to Kain's device.

Kain then goes about her day, and a week later is at a grocery store which Arthur happens to be at as well.

Kain's device broadcasts that it has a message to pass along, and Arthur's device requests a copy of that message.

Upon receiving the message, Arthur's device sees that the key hash attached to the message matches his own. Seeing that this message was intended for him, the device decrypts the it and notifies Arthur, who can then read what Tianliang had written for him.

- panda-roux -

next: "Upcoming changes to MoonGem"

prev: "Trade-in and New Lens"

index

home

This entry has been viewed 232 times

Leave a comment

Proxied content from gemini://gemini.panda-roux.dev/log/entry?38 (external content)

Gemini request details:

Original URL
gemini://gemini.panda-roux.dev/log/entry?38
Status code
Success
Meta
text/gemini; encoding=utf-8
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.