[namecast]

This is very cool @dhaavi! Can definitely see where you've taken lessons learned from cjdns and yggdrassil.

I hate to nitpick but this project looks promising enough - and the new project you mentioned interesting enough - that I feel the need to. From your FAQ:

> First, there is some structure to the router IPs. While there are special purpose prefixes, most IPs will be in a geo-marked prefix. Every country (+ States in the US) has their own prefix within Mycoria. This means that on the global level, Mycoria routers in the same country share the same prefix. These prefixes are also (tendentially) similar to nearby countries.

Second, within a country prefix, Mycoria uses address-distance routing. This means that packets are sent in the direction of the "address-nearest" other router known. While this is not the most efficient way to route packets, it does work quite well with some additional steps - especially if confined to a smaller geographic region, as Mycoria is doing.

My commentary: One of the unfortunate lessons we learned from the IPv4 internet and management of IANA IPs by the different RIRs (and the subsequent tagging of IPv4 blocks with geographic information) is that layer-8 folks love the idea of layering policy on top of geographic tags. (E.g.: Maxmind says your address is in Pakistan, and according to Pakistani law content offered by another address is verboten, ergo you are blocked.)

Geographic awareness built in to network prefixes may be used against your users in ways that you'd prefer to avoid. Or perhaps it's an acceptable tradeoff for you - it's easy to envision scenarios where 'the juice is worth the squeeze' and users derive enough benefit from geo-aware prefixes to accept the drawbacks. If it's the former, I'd recommend investigating moving from geo-aware prefixes ("I'm within X miles of other people in this jurisdiction") to latency-aware prefixes ("I'm within X ms of other people within this prefix").

(Steelmanning my own recommendation - it's possible that anyone trying to implement layer 8 policies on top of geographical-aware prefixes will just willfuly misinterpret latency-aware prefixes as being close enough to them, which would mean a lot of wasted effort for nothing).

Anyway, just my two cents. Again, very cool project, looking forward to seeing what you build on top of it!

[dhaavi]

Thanks for taking the time for this feedback.

This is what I hope to solve with the private addresses: These are not geo-marked and not routable. Eg. they are randomly generated and cannot be attributed to a geographic location (easily).

[namecast]

Ah nice! Glad to see you've already thought of this. Any sense of what % of addresses you would hope to be private vs geo-marked? (Asking because it's easy to mark all private addresses as being "bad" if they're in the minority, but once they reach a tipping point that becomes infeasible - at least we've seen this with addresses tagged as belonging to VPN providers).

If you have a decent amount of private addresses in the mix (1) such that blocking them would 'break' the mycoria experience(2) then it sounds like you've got a decent solution here - geo-aware prefixes for convenience and private addresses for when you'd prefer the anonymity.

1) I freely confess to not knowing what percentage a good mix would be. 20%? 5%? In practice, going back to the VPN example for IPv4, it's "a high enough percentage of important users complaining that their VPN connections are broken for a long enough time". Depending on the jurisdiction that can be 1% (well off / well connected people in a jurisdiction complaining to the right people that in turn overwhelm management with their complaints) to >20% (not necessarily well off or well connected users, but a critical mass that instead overwhelms ISP help desks with complaints).

2) Assumption: mycoria / the app you're building on top of it becomes so important that breaking it completely is a non-starter for the average ISP.