So there's the usual MVP -- Model / View / Presenter pattern, exploded in a distributed fashion. A server sends data, and the client has a bunch of presenters for that data. That makes the client somewhat "generic" in the sense that it just presents whatever data it is given.

MVP : model → presenter → view.

The view is "dumb" and only displays stuff. It's a ViewHolder essentially.

Model has all the data and no logic.

All the logic is in the presenter. The presenter is notified of view changes and updates the model and the views.

For a distributed server-client system, we want all the logic server side.

So really what we have is:

        Server model → server presenter (logic) → client proto → view renderer.

where proto is naturally a Cap'n Proto for example.

The difference between MVP and MVC: in MVC, the model has part of the logic (it dictates what gets sent to the View) and the Controller accepts the input and updates the model. In MVP, the view and the model are dumb, and the presenter embeds both the logic to go from M-to-V and the logic from the Controller (to go from V to M.)

Thinking ahead in terms of a game. Interaction cannot only be handled server side. Otherwise it would mean every user action would have a huge network delay impact. That prevents offline usage at best, and of course implies lag, at worse.

That means part of the model/presenter needs to be on the client:

        [Server + Client model] → server presenter → | → [Client model] → [presenter] → View.

The client presenter handles the immediate interaction and at the same time pushes back some updates to the server.

For offline play, that's all we need. For live server-backed play, that has 2 frequent issues:

Server needs to sanitize / validate inputs from the client. They cannot be trusted. Otherwise it encourages cheating by simple MITM techniques.

Server pushes updates to client regularly which are more trusted than local updates. That can create magical warping when there's a lag.