Questions about data validation about field-manual HOT 4 OPEN

Let me pile on another data validation question: How do we validate data when syncing with another peer?

In regards to the original question: Someday js-ipfs will be mature enough to allow the client to store their own data in the browser and use a server as a WebRTC gateway to sync with other peers. Until then we can use OrbitDB in the backend and have the server act as an oracle.

from field-manual.

@zbyte64 PouchDB stores data in the browser and can use PeerPouch to replicate data over WebRTC. Also, CouchDB (which can sync with PouchDB) allows you to add validation rules (written in js) inside the database itself. When the data is replicated to other servers in the cluster, the data is checked against these rules. Something similar to that on IPFS would be cool ;)

from field-manual.

but how would i prevent malicious users from spamming the application if i can’t perform server-side validation?

Short answer, in a strictly P2P sense, you can't. Just like you can't actually prevent them from spamming your validation server. I think what you were driving at though was an intermediary that could play referee.

Here I can point to two ideas:

1. The library itself. This only works for actors that are using the library; most people will be using libraries that follow the "play nicely" rules. One of those rules is enforcing message validation before blasting it out to all the peers; others could be honoring message rates/bandwidth consumption limits.

Users that try and bypass the library and go direct will most likely be able to get messages sent to all the connected peers. The peers will validate these messages before applying the message and likely reject the request (assuming it's invalid).
But the malicious user can make the peers work. I'm hoping orbit-db has something similar to the bitSwap algorithm for punishing peers issuing spam and eventually severing connections with that peer.

2. Put servers in the middle.
   At the application level create two channels; one channel listens directly to the public channel that only a few "server" peers can update, while other channel is a private messaging channel to a "server" peer. These "servers" get messages from clients; validate it; then repeat it on the public channels.

Again a malicious attacker can make the servers work; hopefully getting banned from the channel if it's malicious.

from field-manual.

Moving to the Field Manual to go into more detail

from field-manual.