diff --git a/content/rfc/_index.md b/content/rfc/_index.md new file mode 100644 index 0000000..3df5817 --- /dev/null +++ b/content/rfc/_index.md @@ -0,0 +1,10 @@ +--- +title: Proposals +extra: + inject_rfcs: true +--- + +# Proposals & RFCs + +This section contains project proposals that I either lack the time or resources to complete. This is a bit of a public TODO list. + diff --git a/content/rfc/modern-repeater-linking.md b/content/rfc/modern-repeater-linking.md new file mode 100644 index 0000000..2a5c4d9 --- /dev/null +++ b/content/rfc/modern-repeater-linking.md @@ -0,0 +1,150 @@ +--- +title: "RFC: A fast system for repeater linking using modern web technology" +date: 2021-11-17 +extra: + is_rfc: true + uses_graphviz: true +--- + +The three common standards for amateur radio repeater linking are all built on old and cumbersome technology. In the world of repeater linking, the most predominant standards for interconnection are: + +- [Echolink](https://secure.echolink.org/) + - Closed-source + - Strict governance + - A strong lack of APIs + - Does not allow cross-system linking + - ex: cannot link Echolink conferences to Allstar nodes +- [AllStarLink](https://allstarlink.org/) + - Absolute overkill + - Most node configurations require special hardware to set up + - Built on the Asterisk PBX + - Uses phone networks to link repeaters +- [IRLP](http://www.irlp.net/) + - Requires specialized hardware + - Uses old connection standards + - Closed-source + +In my ideal world, there would be a small, lightweight, and configurable linking backend that developers could extend in any way they wished. This proposal is not the end-all-be-all solution, but a step in the direction of this vision. + +## Node discovery + +In a linking system like Echolink, *all* clients announce themselves to a central directory server. This server then decides if a client is "worthy" (verified license, not banned from the service, ...) then lists the client on [a somewhat parsable webpage](https://secure.echolink.org/logins.jsp). The topology for such a setup is as follows: + +
+flowchart LR + You(You) --- D1((Directory Server)) + D1 --- NA(Node A) & NB(Node B) & P1(Proxy) & ND(Node D) + P1 --- NC(Node C) +
+ +In most cases, this works just fine. However, there are two off the top of my head that raise an issue: + +- `Node A` and `Node B` are owned by a club that wants to keep the nodes private for member use only. +- `Node C` is behind a restrictive firewall, or does not want to expose a host to the public internet. + +The second of the two scenarios is solved already in the above graph using a proxy. Echolink proxies have become extremely common due to the fact very few people have access to a network where their host can be exposed publicly for other nodes to directly connect to when making a link. + +Echolink's solution to the first issue is fairly lacking in my opinion. Nodes only have the option to restrict connections based on a REGEX on their callsign. This means maintaining a list of allowed users, and updating *every* club-owned node when that changes. + +### Decentralizing directory services + +While I like Echolink a lot, I think some improvements could be made to both the node directory system, and how nodes link to each other. Ideally, I see a setup as follows: + +
+flowchart TD + D1((Directory A)) + D1 --- NA(Node A) & NB(Node B) & NC(Node C) + D2((Directory B)) + D2 --- NC & ND(Node D) + D3((Private Directory)) + D3 --- NE(Node E) & NF(Node F) + NE --> D2 +
+ +In this world, anyone could host a directory server, and either open it up to the public, or restrict it by means of their choosing (callsign rules, password, key-based access, ...). Nodes can then connect to one or many directories of their choosing. This could allow situations where a node could sit on the edge between two private intranets and have access to other nodes on *both* sides of the boundary without requiring either side to expose some part of itself to the public internet. + +### Routing + +I also envision a routing system where nodes attached to more than one directory service would periodically propagate information about their first-hop directories to other first-hop directories. An example of such interaction from the perspective of `Node C` would be: + +```text +Node C -> Directory A: You can find Directory B at
+Node C -> Directory B: You can find Directory A at
+``` + +`Node E` would have a different interaction. Since `Private Directory` is *private*, its announcement would *exclude* that directory: + +```text +Node E -> Private Directory: You can find Directory B at
+``` + +At this point, the directory servers should then be able to directly query eachother about their "routing tables". Over time, each directory server would build a list of which directory servers it can reach for information about nodes. + +The rable for `Private Directory` would look like this: + +| Server | Address | Hops | +|-------------|-------------|------| +| Directory B | `
` | 1 | +| Directory A | `
` | 2 | + +If `Node F` were to try connecting to `Node A`, the order of messages would be: + +```text +Node F -> Private Directory: Do you know Node A? + +# Private Directory queries the first table entry +Private Directory -> Directory B: Do you know Node A? +Directory B -> Private Directory: No + +# Private Directory queries the second table entry +Private Directory -> Directory A: Do you know Node A? +Directory A -> Private Directory: Node A is at
+ +# Node F is informed of the address of Node A +Private Directory -> Node F: Node A is at
+``` + +Of course, since `Node F` is *only* connected to a *private* directory service, if `Node A` were to try connecting to `Node F`, the order of messages would be: + +```text +Node A -> Directory A: Do you know Node F? + +# Directory A queries the first table entry +Directory A -> Directory B: Do you know Node F? +Directory B -> Directory A: No + +# Directory A was never informed that Private Directory exists, since it is private +# Thus, there is no route to Node F +Directory A -> Node A: No +``` + +Like every other piece of amateur radio backbone software, this routing system relies on trust. I am not an expert in identity verification, and I will not attempt to devise a system for stopping bad actors from poisoning the routing tables in this document. + +## Audio transport using modern tech + +So far in this document, node addresses have been used extensively, yet nodes are not expected to expose any ports to the internet. In the real-world, it has become very common to see peer-to-peer real-time media links in the form of video conferencing services. These services largely rely on WebRTC, a standardized, strong, and reliable protocol for peer-to-peer content streams. + +While WebRTC still struggles to deliver perfect quality audio and video simultaneously, it is more than capable of *just* streaming audio, with the added benefit that basically every browser supports it natively. Most programming languages also have one or many strong WebRTC libraries to work with. + +This means that a full implementation of this document would result in something similar to the following: + +- Directory server + - Handles incoming clients + - Handles routing tables + - Handles access rules + - Performs client lookups when requested + - Possibly provides telemetry information +- Client library + - Establishes connections with one or more directories + - Periodically propagates information about connected directories + - Can request to create or destroy a link + - When a link is created, it exposes a direct WebRTC connection to the remote node + - Hands off responsibility for the connection to whatever software wraps the library + +The wrapping software could be one of: + +- A website +- A smartphone app +- A headless application running on a Raspberry Pi that connects straight to a radio for a simplex node +- An application running on a repeater controller +- Anything else \ No newline at end of file diff --git a/sass/styles/layout.scss b/sass/styles/layout.scss index e386ced..4965157 100644 --- a/sass/styles/layout.scss +++ b/sass/styles/layout.scss @@ -132,3 +132,8 @@ ul { } } } + +.mermaid { + width: fit-content; + margin: auto; +} diff --git a/templates/base.html b/templates/base.html index 6a3c535..6be9243 100644 --- a/templates/base.html +++ b/templates/base.html @@ -78,7 +78,8 @@

Home | Blog | - Hobbies + Hobbies | + RFC

diff --git a/templates/page.html b/templates/page.html index fa6f24f..63728e5 100644 --- a/templates/page.html +++ b/templates/page.html @@ -67,7 +67,7 @@ MathJax.Hub.Config({tex2jax: {inlineMath: [['$','$'], ['\\(','\\)']], displayMat {# Comments only on blog posts #} - {% if page.description and page.date %} + {% if page.extra.is_rfc or page.description and page.date %}
{% endif %} +{% if page.extra.uses_graphviz %} + +{% endif %} {% endblock content %} \ No newline at end of file diff --git a/templates/section.html b/templates/section.html index a6b0549..25b29d4 100644 --- a/templates/section.html +++ b/templates/section.html @@ -49,6 +49,7 @@ {% block content %} {{section.content | safe}} +{# Blog posts #} {% if section.extra.inject_blog_posts %}
    {% for page in section.pages %} @@ -59,4 +60,16 @@ {% endfor %}
{% endif %} + +{# RFCs #} +{% if section.extra.inject_rfcs %} +
    + {% for page in section.pages %} + {% if not page.extra.hidden %} +
  • {{page.title}} ({{page.date}}) +
    • + {% endif %} + {% endfor %} +
+{% endif %} {% endblock content %} \ No newline at end of file