[rtkwe]

There's going to be people who travel more often between the two network islands already so there's several ways you could do it. The network as a whole could track nodes who often see rarely seen nodes and navigate packets towards those 'bridge/traveller' nodes or the nodes themselves could keep track of nodes they commonly see and choose to cache more messages intended for those nodes it thinks it might reach in village B in the future.

It gets more complex if there's messages intended for Village C where no one from Village A visits though without some deleterious privacy impacts from needing to know what nodes see what other nodes but if the messages are relatively small you can address that with just increasing the level of optimistic caching and forwarding perhaps. Also the higher bandwidth the link the better so you can transfer more of these optimistic packets.

I'm generally against strapping a coin to this since it seems inevitably to hamper end user adoption in favor of making money for speculators and the people in the ICO. It could incentivize creating static point to point links though by providing potential revenue. Not sure that gets over the downsides of strapping a coin onto this though.

[tgv]

I think there are other difficult scenarios as well, and that you might underestimate the size of an island. There are isolated cities, e.g. Perth with 2M inhabitants, and practically nothing around it.

One option --but it might require some centralization-- is that people announce they're going to travel, and stash a bunch of messages. If the sender can provide information about the geographical destination, that could help.

About monetization: remember what money did to the internet. But the above option would practically invite some form of payment. Thinking of Perth, that would lead to a kind of "Mad Max meets Johnny Mnemnonic".

[rtkwe]

Building the map of what nodes are where is definitely a hard challenge and why most mesh networks have just resorted to flood broadcasting with occasional replays instead of trying to build actual routing in then adding 'mesh tunnels' over the internet like Meshtastic's use of MQTT to link geographically disparate clusters of nodes. It's better with static nodes where you don't have to constantly rebuild your routing tables but gets tough when you mix in mobile nodes and another level when you add intermittent connections like Australian cities, best solution is probably long range backhaul nodes purpose built to link those in the end.

[tgv]

I'd recommend building simulations before you spend time on implementing any strategy. You could also looks up random graph theory. There might be some usable results wrt. connectivity.