-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split README into Wiki #56
Comments
The docs could certainly be better organized. I tend to prefer a table of contents and Cmd+F rather than having to rely on a wiki search bar and jumping between pages though. Moving the demo section to a Wiki page and linking to it from pretty high up in the existing readme would be a good first step I think. |
ToC and some cleanup might be good enough. I'll get some additional internal feedback on user preferences before committing to the full Wiki idea. Agreed that would be a good first step either way. |
@luker983 Can you review the new How it Works section in this branch and make sure I got it all right? In particular some clarification about how the API address relates to the Relay or E2EE interfaces would be helpful. Including how they get assigned, since I don't see them in the config files. Any other feedback on the Readme there is welcome too, but it's still a WIP |
Sure! Looks good. Some feedback: I think this section could probably be moved to the wiki as well since it's grown quite a bit. Maybe just leave the diagram and a link to the wiki page?
I think we can do both, demonstrate the concepts without compromising accuracy
All of the network traffic occurs over "real-world" network infrastructure, we just add one additional layer over a traditional VPN. I think "overlay network" might be the most common term for this.
This is all configurable, consider adding "By default, " before this line.
The API addresses are assigned just like the relay/e2ee peer IPs, it's an incrementing value kept track of by the first Server: https://github.com/sandialabs/wiretap/blob/readme-updates/src/transport/api/api.go#L262 They appear in the e2ee config under AllowedIPs (so the client has a route to the API). The API handler binds to the API address on the e2ee interface (internal to the program, the userspace networking stack, only reachable by clients). |
Yeah the Details section is probably better off in a Wiki page, I'll move that.
Fair, that was mostly in reference to my explanation of Servers acting like typical TCP/IP Routers, and I wasn't sure if that was actually how they worked under the hood.
I'm trying to differentiate between traffic that is visible to "real world" devices (packets that have IP headers for routing to host NICs) vs. packets that only get routed inside the userspace Wiretap network and are effectively invisible to the hosts during transport. Since I'm already describing the "Relay" and "E2EE" virtual/overlay networks, "real-world" network seems like the most appropriate term to differentiate where those outer-most connections happen, but I'm open to better terminology ideas. Thanks for the API clarification, I've expanded on that section in the new Wiki page. |
The Readme is really long, would probably be more useful to have the different headings split into topics in a Wiki format.
The text was updated successfully, but these errors were encountered: