diff --git a/content/events/meme-month-2022.md b/content/events/meme-month-2022.md index d12b3e0..e02b0ff 100644 --- a/content/events/meme-month-2022.md +++ b/content/events/meme-month-2022.md @@ -6,6 +6,8 @@ extra: uses_flags: true --- +***This event has passed. Page preserved for nostalgia.*** + *Meme Appreciation Month* is an event organized by a bunch of LIDs as ~~an excuse to put rediculous callsigns on the air~~ *a celebration of the funny internet pictures your parents don't understand* during the period from **June 25th** to **August 5th** 2022. ## Who? ..asked? @@ -26,7 +28,7 @@ During the course of the event, the following callsigns will be active on air: The actual operators of these calls may (will) rotate throughout the event in order to get the most out of our money *(cries in $60 event callsign fees)*. -*It is assumed that participating operators are members of our Discord server. If you are not, but would like your meme call in this list, contact [`memecalls@va3zza.com`](mailto:memecalls@va3zza.com)* + ## Contacting us diff --git a/content/rfc/_index.md b/content/rfc/_index.md deleted file mode 100644 index 3df5817..0000000 --- a/content/rfc/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -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/hostname-standards.md b/content/rfc/hostname-standards.md deleted file mode 100644 index 1cc6871..0000000 --- a/content/rfc/hostname-standards.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "INFO: Host naming conventions" -date: 2021-11-23 -extra: - is_rfc: true - uses_graphviz: false ---- - -This document quickly outlines my public and private host naming conventions. - -## Nov 2021 to Present - -*wip* - -## Pre Nov 2021 - -Hosts before ZZANet were named in the following manner: - -- 2 character purpose code -- [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1) Alpha-2 country code -- 3 character city code -- 2 digit discriminator -- (optional) domain - -Example hosts are: - -| Short | Long | Info | -|----------------|-------------------------------------|------------------------------| -| `gw-ca-tor-01` | `gw-ca-tor-01.servers.retrylife.ca` | Toronto gateway server 1 | -| `nl-ca-lon-01` | `nl-ca-lon-01.servers.retrylife.ca` | London network link device 1 | \ No newline at end of file diff --git a/content/rfc/modern-repeater-linking.md b/content/rfc/modern-repeater-linking.md deleted file mode 100644 index 2a5c4d9..0000000 --- a/content/rfc/modern-repeater-linking.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -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