Using lokinet on a router is a very convenient way to run it--I do it on my network so that all my devices have lokinet accessibility without needing to run lokinet.
One deficiency of this design, however, is that it is still NATing a lokinet connection: all devices behind my lokinet-enabled router can reach lokinet, but are not independently reachable and getting around this requires some sort of NAT holepunching mess, which we don't have to require for lokinet.
The idea is that such a routing lokinet would have the ability to manage multiple lokinet addresses at once, publishing introsets for each of them. Each published introset would map to one internal address (e.g. xyz123blahblah.loki <-> 10.0.0.123), so when data arrives to the lokinet client, it can send it to the proper internal address.
This might get messy in terms of the number of introsets being juggled, so an alternative to consider would be that we have some sort of "tag" on the data -- still use one address, but each local client gets assigned a different tag in the messages, remote clients learn about this tag, and can direct messages to a specific client by directing them at the router's lokinet address + appropriate tag. We would probably want to build this into the DNS, so that tagged data comes from/goes to some subdomain e.g. tag-147175123.someaddr.loki. The disadvantage of this is that you can easily see devices behind the same router, while using independent introsets would not let you see this.
Using lokinet on a router is a very convenient way to run it--I do it on my network so that all my devices have lokinet accessibility without needing to run lokinet.
One deficiency of this design, however, is that it is still NATing a lokinet connection: all devices behind my lokinet-enabled router can reach lokinet, but are not independently reachable and getting around this requires some sort of NAT holepunching mess, which we don't have to require for lokinet.
The idea is that such a routing lokinet would have the ability to manage multiple lokinet addresses at once, publishing introsets for each of them. Each published introset would map to one internal address (e.g. xyz123blahblah.loki <-> 10.0.0.123), so when data arrives to the lokinet client, it can send it to the proper internal address.
This might get messy in terms of the number of introsets being juggled, so an alternative to consider would be that we have some sort of "tag" on the data -- still use one address, but each local client gets assigned a different tag in the messages, remote clients learn about this tag, and can direct messages to a specific client by directing them at the router's lokinet address + appropriate tag. We would probably want to build this into the DNS, so that tagged data comes from/goes to some subdomain e.g. tag-147175123.someaddr.loki. The disadvantage of this is that you can easily see devices behind the same router, while using independent introsets would not let you see this.