Something I realized while writing the peer shadow test is that managing peers is a lot more temperamental than managing clients, because in several places we have to track the relationship between user and peer/address:
In the shadow config, to track which IP each peer gets assigned.
In the peer's identity, so the peer knows what to listen on.
Anywhere the peer is listed as a contact, so the sender knows where to send to.
The third gets decoupled from the first one or two when using onion addresses, depending on how we set them up, but is still a problem for how verbose it is, and still having to match every other instance of the contact in any conversation. I think the best way around this is to make the first argument to the peer a hosts-like file that maps the human-readable name to the address, which can then be shared by all peers (either symlinks or path traversal).
On the note of "how onion addresses get managed", I'm pretty sure we'll need a different onion address for each user, to make sure we're adding load to the DHT, etc.. This would mean we could do something similar to the client management, where users could be migrated by simply moving the relevant config files to the right directory, but we'll have to be careful to keep each 127.0.0.0/8 addr:port pair unique to each user.
Something I realized while writing the [peer shadow test](https://git-crysp.uwaterloo.ca/j3tracey/MGen/commit/9d63492f8385dbb96f39f0ae5b463ba52bcc237f) is that managing peers is a lot more temperamental than managing clients, because in several places we have to track the relationship between user and peer/address:
- In the [shadow config](https://git-crysp.uwaterloo.ca/j3tracey/MGen/src/9d63492f8385dbb96f39f0ae5b463ba52bcc237f/shadow/peer/shadow.yaml#L17), to track which IP each peer gets assigned.
- In the [peer's identity](https://git-crysp.uwaterloo.ca/j3tracey/MGen/src/9d63492f8385dbb96f39f0ae5b463ba52bcc237f/shadow/peer/shadow.data.template/hosts/peer1/alice-group1.toml#L1), so the peer knows what to listen on.
- Anywhere the peer is [listed as a contact](https://git-crysp.uwaterloo.ca/j3tracey/MGen/src/9d63492f8385dbb96f39f0ae5b463ba52bcc237f/shadow/peer/shadow.data.template/hosts/peer1/alice-group1.toml#L3), so the sender knows where to send to.
The third gets decoupled from the first one or two when using onion addresses, depending on how we set them up, but is still a problem for how verbose it is, and still having to match every other instance of the contact in any conversation. I think the best way around this is to make the first argument to the peer a hosts-like file that maps the human-readable name to the address, which can then be shared by all peers (either symlinks or path traversal).
On the note of "how onion addresses get managed", I'm pretty sure we'll need a different onion address for each user, to make sure we're adding load to the DHT, etc.. This would mean we could do something similar to the client management, where users could be migrated by simply moving the relevant config files to the right directory, but we'll have to be careful to keep each 127.0.0.0/8 addr:port pair unique to each user.
Something I realized while writing the peer shadow test is that managing peers is a lot more temperamental than managing clients, because in several places we have to track the relationship between user and peer/address:
The third gets decoupled from the first one or two when using onion addresses, depending on how we set them up, but is still a problem for how verbose it is, and still having to match every other instance of the contact in any conversation. I think the best way around this is to make the first argument to the peer a hosts-like file that maps the human-readable name to the address, which can then be shared by all peers (either symlinks or path traversal).
On the note of "how onion addresses get managed", I'm pretty sure we'll need a different onion address for each user, to make sure we're adding load to the DHT, etc.. This would mean we could do something similar to the client management, where users could be migrated by simply moving the relevant config files to the right directory, but we'll have to be careful to keep each 127.0.0.0/8 addr:port pair unique to each user.
See also: #21
Fixed via
4e47a78e82.