Peer ideas (Updated)

[Winterhuman]

(Mainly making this post to explore some options I've thought of, I am in no way a coder and do not know how complicated any of my ideas are to implement, nor if any of them are a good direction to take). EDIT: See bottom post which outlines a much simpler system.

Unknown peer authorisation

PEER-A

hyprspace init hs0 --allow-all [Allows any peer to connect, also allows any peer to pick what group they are a part of]
  Your peer-id is... [PEER-ID-A]
  Your discovery key is... [PEER-A's discovery key]

PEER-B

hyprspace connect hs0 [Creates hs0 interface and then prompts for questions]
  Who is the other peer? [Enter PEER-ID-A]
  What is the discovery key? [Enter PEER-A's discovery key]
  What group are you apart of? [Only if "--any-group" or "--allow-all" is used by PEER-A, happens during "Sending config information." so PEER-B can get the list of groups in the network]

PEER-A

hyprspace init hs0 --allow-all
  Your peer-id is... [PEER-ID-A]
  Your discovery key is... [PEER-A's discovery key]
  PEER-ID-B is attempting to connect, allow connection? [yes/no]
  Sending config information. [Sends PEER-B the group list from PEER-A's config so they can choose a group]
  Adding PEER-ID-B as an authorised peer to config.

Additional:

• --allow-all allowes any peer to connect to any group regardless of if they're defined in the config.
• --any-peer allowes any peer to connect, but, they can't pick the group they're apart of.
• --any-group only allowes peers defined in the config, but, they can pick any group to be apart.

[Winterhuman]

IP-less peer list

Peer's ip-addresses would be controlled by a DHCP-like system, ip-addresses are random but with two exceptions:

1. No two peers, where at least one of the peers was randomly given an ip-address, can have the same ip-address. If all ip-addresses in a network or group are taken (Unless a peer is stated to share an ip-address with another peer) then reject new peers stating Can't initialise connection, all ip-addresses are taken..
2. Peers can't have ip-addresses that are already mentioned in the config, stops peers with defined ip-addresses having their ip-address taken from them.

[Winterhuman]

Peer groups

WARNING: This is a really complicated solution that would take a lot of effort, please say if this is way too much to ask for from a project like this.

groups:
  home: [Groups are defined by their name, the "ungrouped" group is hardcoded]
    10.1.1.0/16 [Groups are defined by an ip-address range]
  work:
    10.1.2.0/16 [Groups can be given multiple ip-ranges]
    10.1.3.0/16 [Peers could have an ip-address anywhere within 10.1.{2,3}.0/16]

peers: [Peers can be assigned a group AND a specific ip-address like so]
  home:
    10.1.1.1: [These peers share an ip-address to allow multicast support]
      PEER-ID-1
      PEER-ID-2
  work: [Peers can be defined multiple times so that they can be in multiple groups]
    10.1.2.1:
      PEER-ID-1 [This peer is in both "home" and "work" as 10.1.1.1 and 10.1.2.1]
  work:
    PEER-ID-3 [This peer is in the "work" group and is assigned a random ip-address]
  10.1.4.1:
    PEER-ID-4 [This peer will be 10.1.4.1 in the "ungrouped" group]
  PEER-ID-5 [This peer will be in the "ungrouped" group with a random ip-address]

Additional:

• Peers can only see and interact with each other if they're in the same group.
• Peers in the same group can always communicate with each other, even if their ip-addresses are in two of a group's ip-ranges (e.g. A peer in 10.1.2.0/16 could still talk with a peer in 10.1.3.0/16 since they're both ip-ranges within the work group)
• A peer cannot have an ip-address that fits into the ip-range of a group they are not apart of, ungrouped peers couldn't have 10.1.1.1 since they're not in home.
• Groups cannot share ip-ranges since otherwise a peer could see and interact with peers not in their group making group isolation much more complex, hyprspace should state Config error detected in groups file. to prevent this from happening. Peers can have multiple groups to overcome this.
• If your PEER-ID is not specified anywhere in the server-peer's config, but they used --any-peer, then you'd be in the ungrouped group with a random ip-address.

[Winterhuman]

Possible directory structure

This allows the above ideas to work per-interface, it should also make it easier to write changes and new information via a CLI to each file separately.

.config/
  /hyprspace/
    /hs0/
      /config.yaml
      /groups.yaml
      /peers.yaml

[alecbcs]

This is super cool! I might not have time until this next weekend to go over this all but I'm really looking forward to how we might better integrate some peer management into Hyprspace.

[Winterhuman]

I'm glad you like my ideas, I thought I might of been asking for too much, but, if you think this is a good direction I'm happy to explain my ideas in more detail to help out!

[Winterhuman]

I've rewritten all the posts with code blocks now, I've also added two new options --any-peer and --any-group since I realised someone would likely need them for certain use cases I mentioned in the first post, hopefully everything is better worded and easier to read now.

[Winterhuman]

Possible CLI commands

WARNING: This comment is somehow even longer than the last one; I'm not doing this on purpose. Hopefully this is a solution to CLI integration, sorry in advance for the length of this comment you're about to read, tried covering all use cases.

Current:

hyprspace init INTERFACE
hyprspace up INTERFACE
hyprspace down INTERFACE
hyprspace update

Replacement:

Connectivity:

hyprspace up/down INTERFACE [hyprspace init/connect/disconnect make these redundant]
hyprspace update [Stays the same]
hyprspace init INTERFACE (--allow-all,--any-peer,--any-group,etc)
hyprspace connect INTERFACE (Prompts for questions) [Will ask if you want to join a peer you've already connected to previously before asking for new connection details]
hyprspace disconnect INTERFACE (Disconnects from and shuts down interface)
hyprspace reconnect INTERFACE (Retries connection for interface) [Temporary fix for long reconnection times when peer change ip-address]

To explain things better, I will use the layout shown below for my explanations.

Command layout

Example of command

Output of example

Peers:

":" acts as connectors and "," acts as a list (e.g. ITEM1,ITEM2:ITEM3,ITEM4)

hyprspace list peers INTERFACE (List peers visible over interface)

hyprspace list peers hs0

home 10.1.1.1,10.1.1.5 PEER-ID-A [Perhaps output as a table?]
work 10.1.2.1 PEER-ID-B

hyprspace add peers INTERFACE GROUP:IP-ADDRESS1,IP-ADDRESS2:PEER-ID ...

hyprspace add peers hs0 home:10.1.1.1,10.1.1.5:PEER-ID-A

.config/hyprspace/hs0/peers.yaml [Information below is appended to file]
peers:
  home:
    10.1.1.1
      PEER-ID-A
    10.1.1.5
      PEER-ID-A

hyprspace view peers INTERFACE PEER-ID-1 PEER-ID-2 ...

hyprspace view peers hs0 PEER-ID-A

Peer: PEER-ID-A [The ":"'s are just visual here]
authorised: yes [Says if this peer is described in the config or not (eg. For peers who connected via --allow-all)]
home: 10.1.1.1,10.1.1.5
work: 10.1.2.1
other: [Groups the peer is not apart of will have no ip-address shown for it]
random: 10.6.4.2 (random) [Random ip-address will have (random) next to them]

hyprspace mod peers INTERFACE PEER-ID del/add GROUP1:IP-ADR1 GROUP2:IP-ADR2 ...

hyprspace mod peers hs0 PEER-ID-A del work:10.1.2.1
hyprspace view peers hs0 PEER-ID-A

Peer: PEER-ID-A
authorised: yes
home: 10.1.1.1,10.1.1.5
work:
other:
random: 10.6.4.2 (random)

hyprspace del peers INTERFACE PEER-ID-1:GROUP1,GROUP2 ...

hyprspace del peers hs0 PEER-ID-A:home

.config/hyprspace/hs0/peers.yaml
peers:
  home:
    10.1.1.1
#      PEER-ID-A [Peers are commented out instead of deleted]
    10.1.1.5
#      PEER-ID-A [Ip-addresses without peers will be ignored in the config]

Groups:

hyprspace list groups INTERFACE

hyprspace list groups hs0

home: 10.1.1.0/16
work: 10.1.2.0/16,10.1.3.0/16
other: 10.1.5.0/16
random: 10.6.4.0/16

hyprspace add groups INTERFACE GROUP:IP-RANGE1,IP-RANGE2, ...

hyprspace add groups hs0 work:10.1.1.0/16,10.1.2.0/16

.config/hyprspace/hs0/groups.yaml
groups:
  work:
    10.1.2.0/16
    10.1.3.0/16

hyprspace view groups INTERFACE GROUP1 GROUP2 ...

hyprspace view groups hs0 work

Group: work
Ip-range: 10.1.2.0/16,10.1.3.0/16
Peers: PEER-ID-A,PEER-ID-B, ... [Perhaps a vertical list for large groups?]

hyprspace mod groups INTERFACE GROUP del/add IP-RANGE1,IP-RANGE2, ...

hyprspace mod groups hs0 home add 10.1.7.0/16
hyprspace list groups hs0

home: 10.1.1.0/16,10.1.7.0/16
work: 10.1.2.0/16,10.1.3.0/16
other: 10.1.5.0/16
random: 10.6.4.0/16

hyprspace del groups INTERFACE GROUP1 GROUP2 ...

hyprspace del groups hs0 work

.config/hyprspace/hs0/groups.yaml [Groups are commented out instead of deleted]
groups:
#  work:
#    10.1.2.0/16
#    10.1.3.0/16

peers:  [Peers under a deleted group are commented too, avoids creating ungrouped peers with specific ip-addresses after group deletion]
#  work:
#    10.1.2.1
#      PEER-ID-B

In Summary:

hyprspace update
hyprspace init INTERFACE
hyprspace connect INTERFACE
hyprspace disconnect INTERFACE
hyprspace reconnect INTERFACE
hyprspace list/add/mod/del/view peers/groups INTERFACE SELECTION+OPTIONS

Additional:

• The add, mod, and del commands are restricted to the peer who is being connected to.
• Peers can only use view and list on peers and groups they know and are apart of, this prevents peers finding out information about peers and groups they shouldn't be able to know about.
• Perhaps an admin_peers: option could be used to allow certain peers to run restricted commands?
• Perhaps a TUI or curses-based CLI would be a more suitable solution given the number of options and configurations? (e.g. hyprspace configure hs0) [Or borrow from rclone config like you said]

[Winterhuman]

Simplified Group Model

Intro

The system outlined above is too complex now looking back at it, so, this post will explore a much simpler model which should still satisfy all of the most useful aspects.

Group key

In the same way a discovery key was required to join a hyprspace network, we can introduce a group key as well as a group ID to create groups within a hyprspace network, this is how it might be constructed within a config:

peers:  [Borrows from config format outlined in previous posts]
  10.1.1.1
    Peer-ID-A

groups:
  Group-ID-A
    Group-ID-A-Key
  Group-ID-B
    Group-ID-B-Key

Groups in this model are client-side defined; the server/gateway node doesn't define the groups, peers will attempt to join all groups defined in the config, this doesn't restrict nodes into having an ip-address in a specific ip-range and it entirely removes the need for view/list/admin_peers/etc.

However, being able to join multiple groups means some form of isolation needs to be added, otherwise Peer-A could be in groups A and B and someone in group B could ask Peer-A for a group A peer when they shouldn't be able to.

A consideration to make is whether a peer should ask everyone in a hyprspace network if they accept a group-key or whether to implement a PubSub system for asking for a group-ID, in large networks the first solution (along with many groups) could become noisy so the second is probably the best solution unless someone can think of something better.

Additional

To achieve the functionality detailed in IP-less Peers, peers could use ip-ranges instead of ip-addresses to self-assign themselves with a random ip-address, this removes the need to centralise on a DHCP system for the server/gateway node. If a peer realises they share an ip-address with someone, and has an ip-range set instead of an ip-address, then they will change their address for one that isn't taken.

Summary

• Much simpler to implement since it reuses the older discovery_key concept.
• Allows peers to be in multiple groups at once.
• Peers could reuse group-keys in multiple interfaces to create mirrored groups.
• Removes the need for many commands like before.