diff --git a/README.md b/README.md index ff8de38..e831f72 100644 --- a/README.md +++ b/README.md @@ -7,3 +7,15 @@ > Ultralight Beam describes a protocol for sending offline messages that will later be broadcasted through relay nodes. This repository contains the specs for [Ultralight Beam](https://ultralightbeam.io), a transport agnostic MANET (Mobile Ad-Hoc Network) for sending arbitrary data. + +## Status + +Ultralight Beam is under active development, each specification has its own `status` which is reflected through the version number at the top of every document. We use [semver](https://semver.org/) to version these specifications. + +## Core + +These specs document core functionality of the Ultralight Beam protocol. + +- [Message Relaying](./message-relaying.md) - The process for sending and relaying messages within Ultralight Beam. + +All specs follow [RFC-2119](https://tools.ietf.org/html/rfc2119). \ No newline at end of file diff --git a/message-relaying.md b/message-relaying.md new file mode 100644 index 0000000..062aed4 --- /dev/null +++ b/message-relaying.md @@ -0,0 +1,44 @@ +# Message Relaying + +> Version: 0.1.0 (Draft) +> +> Authors: Dean Eigenmann + +## Table of Contents + +1. [Abstract](#abstract) +2. [Definitions](#definitions) +3. [Relaying](#relaying) +4. [Footnotes](#footnotes) + +## Abstract + +In this specification, we describe how nodes relay messages. This includes nodes sending initial messages as well as nodes relaying messages they have received from other nodes. + +## Definitions + +| Term | Definition | +| ----------- | --------------------------------------- | +| Origin | The initial sender of any message. | +| Last sender | The last node a message hopped through. | + + +## Relaying + +There are three modes with which a packet can be sent to peers, they both depend on the message along with the nodes state. + +A message MUST either contain a `recipient` address or a target `protocol`. + + + +If a message contains a `recipient`, a node MUST initially try and send it to the recipient's address. If a node does not have a direct connection it MAY send it to any number of its peers. + +If a message contains a `protocol`, a node MUST initially try and send it to any peer that supports it. If non of the nodes peers support this protocol, we MAY send it to any number of its peers. + +When sending a message to any peer, a node MUST ensure they are neither the `origin` nor `last sender`. A node SHOULD abstain from flooding a message given it has a more effective manner to route it towards its target. + +## Footnotes +1. - A pull request in the swift implementation that implements this sending logic. + + +