I think there is some confusion and misunderstandings regarding network architecture and hosting strategies. I've been working on this for my own indie game recently so I'll try and help clear this up to the best of my understanding. Its a bit long, so bare with me!
First off I'm taking what they have said at face value. It's possible they were just speaking generally and freely interchanged terminology to help communicate to the press the general gist without being accurate to the technicalities.
By hybrid approach, what I understand is they are using server authority for progression and client for gameplay. Progression would be things like earning in game gold, items, levels etc. Stuff you don't' want people to be able to cheat because it could cost you real dollars via in app purchases etc. They are then using client authority for gameplay.
Client Authoritative Movement:
In a client authority based model of movement the client has final say or "Authority" over their movement. In an FPS example lets say you spawn at XYZ location of 0,0,0. If the user press the forward key once (W key). If one input equals one unit forward they would then move to 0,0,1. In the client authority model this location would then be communicated to the server or other clients. The Client would say "Hey server I'm now at 0,0,1". The server would then broadcast this new position to all other players. The problem with this is you could potentially cheat and overwrite that value and say you are at 0,0,900 instead. Since the movement code is running on the client and it has authority the server would believe you. Thus you could exploit this to do speed boosts and warp around the map etc.
Server Authoritative Movement:
In a server authority based model of movement the server has the final say or "Authority" over the movement. Using the same example. Instead of sending a location of XYZ coordinates, the client would instead send inputs. If the user presses the "W key" once, this input gets sent to the server, the server then interprets this. The server takes it's current position of the player which is at 0,0,0 and calculates the new position based on the input. Example: 0,0,0 + "W key" = 0,0,1. This new position is then communicated to all players. This solves the problem in the client authoritative approach of being able to lie about your position, but it also means the code is being run on the server. Which would mean just as much lag for your own inputs as it would mean for other players. How do you solve this?
Client Side Prediction with Server Reconciliation:
This uses the same server authoritative movement but it adds a layer of predication to solve the latency problems inherit with remote internet connections. What happens is that both the client and server run the same movement code based on inputs. So if the player starts at 0,0,0 and presses the "W key" once. Both the player and the server run the game logic that calculates the new position (0,0,0 + "W key" = 0,0,1). This way the client input is registered immediately for the player. This is Client Side prediction. In a perfect world this code would always line up, but unfortunately you can't rely on that. So what you do is add Server Reconciliation. Much like sending the resulting position in the Server Authority model to all other players, the server also sends it back to the original player that sent the input. The client updates their position to reflect the server authoritative position. But... By the time the server sends back the position for the first input, the player has probably pressed the W key dozens of times more. To solve this location issue you can then re-run all the prediction logic to get the latest client predicted position based on the last validated server position. Lets use the same example of 0,0,0 + "W key" = 0,0,1. After a few hundred milliseconds the server tells you the resulting position of your first input is 0,0,1. In the elapsed time you have pressed the "W key" five more times. If you are keeping track of inputs this is easy to solve. The first input equals 0,0,1 as validated by the server. So you remove the first input which leaves you with 4 more inputs. You then recalculate your current position of 0,0,1 + "4 W keys" = 0,0,5. Then you repeat the same logic as before. The server interprets those 4 inputs, and you get a new position back that includes those 4 inputs but not others that you've entered during that elapsed time. This way you can get server authority based movement without input lag. 99.9999% of the time this logic works out and you never notice this happening. In the case where it doesn't, the server wins and you see your player warp to the correct server location if the clients previous prediction was wrong.
Hosting Strategies:
Peer To Peer:
Peer to peer hosting is when one or more of the players also acts as a server to host the match. Do not be confused though, this has nothing to do with the different authoritative models. A Peer to Peer hosting strategy can have either client base authority or server based authority models, or both probably. The "Host" in peer to peer is only used to communicate the game state to all other players. All players could still have authority over their movement, or the host could have authority over it. In the scenario where you have a Peer to Peer hosting strategy with Server Authoritative based movement you could help prevent cheating of most players, but not all. The host, since it is being hosted by a player would be open to exploitation since you do not have control of it. It also maybe possible for multiple hosts in peer to peer, where multiple users have authority over different portions of game logic. I have not heard of this in use, but I'm going to assuming anything is possible. If anyone knows of example please let me know, I'd be interested.
Dedicated Server:
This is where the hosting server is not one of the players. Usually hosted on an external cloud server of some kind. In this scenario the owner of the dedicated server has full control of the machine and code running. This is helpful to prevent hosts from cheating as the owner has final say of what code runs. Also due to the nature of dedicated servers running out of server hosting centers there should be a connection improvement, although there is nothing stopping someone from running a dedicated server from the bedroom with equally bad connection as a peer to peer solution. Be aware though, you could still have a dedicated server with client or server authoritative movement. Although I'm not sure why would use client authoritative movement in this scenario there is no reason why you could not.
Anyways, this was just a brief overview from the best of my understanding. I also did not mention anything regarding anti cheat scenarios the could potentially be applied in either scenario.
Related Sources:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
This gentleman has a nice demo of what client side prediction looks like if anyone is interested:
http://www.gabrielgambetta.com/fpm_live.html
