i would like to explore the concept of web vicinity or proximity: after realizing the internet is quite a lot more fragile than i presumed, i thought of an approach for sharing content between users different than the classic client-server recipe.

this idea is most likely unrealistic, maybe even laughable, and it is very likely that someone thought about it before, but i still want to try and research a bit into it conceptually speaking.

note that it is impossible to replace the internet with this way of sharing data. it would only be suitable for sharing large content files that are requested by a large number of people.

i am not sure if this would work but, i want to try to imagine a system where each user trying to access a resource on the internet has to ask for it from their neighbors.

this system would harvest the ability of each connected device to store some amount of data, as well as a kind of group logic that would make efficiency emerge from simple rules applied locally.

the main issues to tackle for such a system to work are:

• availability: how to make any resource available relatively quickly (max 24h) ?
• authenticity: how to guarantee that the content received is exactly what was asked for ?

• personal devices: tiny portable low-power devices that provide wifi internet access.
  • range: 1km ?
  • connections: up to 10
  • bitrate: ~10mb/s per connection ? (study required)
• city-wise devices
  • range: 50km ?
  • connections: up to 100 ?
  • bitrate: same as personal
• continent-wise devices (hypothetical)

• personal devices: 8gb storage ?

the first idea i had to guarantee content authenticity is to use checksums.

first, let's imagine user r makes some resource available under some packed format which can be checksumed.

in an ideal world, if user a wants to access that particular resource, they would request it to neighbors using its checksum. neighbors would relay that request until it reaches user r who has the resource or other users who have parts of the resource.

however, there is an issue with this approach: a malicious relay user might want to deliver a different (malicious) resource to user a.

for now, i didn't think of a solution to this issue but there has to be one, i think.