[__MatrixMan__]

But that's request/response, because you're requesting blocks.

I'm saying that when two nodes pass each other in the street or whatever they think "hey, a peer is in range" so they see if:

- The peer carries any topics they're interested in

- That topic's synchronization algorithm indicates that any actual synchronization is needed in this case

So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

If you subscribe to topics with dumb synchronization algorithms that just copy everything they see and don't check a web of trust, then yeah you could still get floods of data that saturate whatever resources you've allocated to that topic, but that would quickly become a useless topic, so just unsubscribe and pick smarter topics next time.

In summary, push the routing problem to the application layer.

Different data is going to have different needs. Map tiles need to stay near the parts of the planet that they describe. Information about how to mitigate a harm needs to be near the audience that might be harmed. Manuals need to be in the hands of people who are interested in the objects that they describe. Menu and open hours data needs to be near the restaurants with those menus and hours, or to nodes whose owners like that kind of food...

The goal is to converge on a particular distribution of data across nodes, not to get any one piece of data to any one particular node. No requests, and no handling data that you haven't opted into handling by subscribing to that topic.

I suppose you might conceive of the synchronization process as a series of requests, but they don't propagate anywhere. For each datum you either already have it, you decide to take it, or you decide to leave it.

[cyberax]

> But that's request/response, because you're requesting blocks.

It doesn't matter.

> - The peer carries any topics they're interested in

How do you implement it? Do you have a human manually looking over each message and marking the interesting ones? Heck, it's likely that everything is encrypted anyway!

> So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

So you get 10^12 anonymous peers arriving at your node. How do you filter them?

[__MatrixMan__]

The node operator subscribes their node to topics, so yeah that part is manual, and that's how the humans express their interest. You might have to update it every now and then if one topic is killing your battery or your hard drive or you just don't care anymore. The data which that topic governs is handled by the synchronization function which runs periodically without supervision.

Whether some or all of the data is encrypted is an application level detail. At the network layer you just call the function provided by the app/topic and it tells you whether to accept or ignore a datum, and which datum to delete if the storage quota for that topic is full. Lots of things don't need encryption (e.g. map tiles). Or if there's some kind of trust structure in place, the node may have keys necessary for doing the decryption--it's not like you're carrying data for apps besides those you're participating in.

As for the peer filtering thing, peer-discovery and synchronization would happen in time slots. So if it happens for 30 seconds each time and this app in particular gets 30% of that, then I guess you spend 10 seconds trying to see if any of those 10^12 peers are worth synchronizing with. Maybe you're checking to see if they're n hops away on your web of trust for that topic or something like that, it would depend on the case. But I don't see how this case has anything to do with mesh networking: all forms of communication are susceptible to DOS of some kind or another. The best we can do is limit the blast radius and maybe raise it to the user so they can handle the adversary out of band.