Hello, I'm thinking about making a fast paced multiplayer game with NPCs, wide variety of skills (fast and slow, wide range and short range) and movement, and I came to a problem- Networking.
Game like this should have a good synchronised, deterministic and seamless gameplay and netcode.
What type of netcode should I use? A) typical ue4 RPC approach seems to not consider lag and the game can easily desync if You don't take it into account. Also sometimes replicating variables with variable replication property takes a really long time. Not to mention, people on remote machines will see other people in incorrect positions because of lag. So if someone tries to headshot someonemoving to the left , he would in reality be a bit to the left so the headshot wouldn't be counted. There's no compensation with prediction(I mean, UE4 character movement DOES have prediction built in, but it doesn't predict actual position of other players according to lag) . B) Typical ue4 RPC approach with Client side predictions and compensations and coverage of all problems in A would be a good option, but it seems I would have to learn and change a hefty amount of ue4 code and add another hefty bunch of stuff. And still there would be inconsistencies I think.
I heard about Gameplay Ability system having what I mentioned, but I am not sure, does somebody know?
C) Rollback seems to be ideal approach, but I have several questions about it:
- How much would I have to change? Am I thinking correctly and I have to make everything from scratch? Doesn't UE4 have something like this built in? 2.Are there any instances of rollback games on UE4 or anyone at least trying to do that and documenting everything?
- How to do that? Do You have any Idea how to approach rollback? How to prepare everything? How to sync and simulate multiple frames at once to rollback etc. ?
- Is it worth it? Is client side prediction and compensation worth more and would work? Which approach needs more work? Would rollback work effectively in a game with more than 2 players anf NPCs?
So I have implemented a basic client-side prediction network where my player will send inputs to the server at 30Hz, and while it is waiting for server verified movement it will predict the client side movement and move the player (keeping track of its past inputs). Then when the server returns its confirmed position for an input, we verify our prediction was correct and if it is not, we move to server location, and re-run any un-verified inputs again on the client side. Great, all that is working and I am quite happy with it.
My issue is, now that I am running on a server tick of 30hz, it almost looks like the game is a little "choppy" because its now updating the movement (client side for local player) 30 times a second in stead of the previous 60+.
I was thinking a possible solution would be to sample input at a higher rate (60Hz) but only send it to the server at 30Hz so the client could predict movements at a faster rate, but the server still gets its inputs every tick. What problems are there with this (assuming the server can handle simulating 2 inputs per server tick)?
The other idea I had was collecting inputs every 30Hz, but having separate logic that does run at 60Hz+ to interpolate the client input and smooth out the movement. This is kind of of similar to how I update other players movement using interpolation, but not sure if the same idea could work for the local player? I'm not sure there is a way to do this nicely without assuming player input or causing a small delay?
Any ideas are greatly appreciated! (I am not sharing code as I think this problem isn't necessarily code specific and more from a network design aspect).
TLDR; My server only updates at 30Hz, and so client prediction causes the movement to only be predicted every 30hz, what is the best way to keep server at 30Hz but predict my client (local player who sent the inputs) more frequently without messing up the server inputs?
I've been looking into client-side prediction netcode, and I've got a few areas that I'm not sure how they can or should be handled.
- When a client action would spawn an object, in the interest of responsiveness, I would think that would happen immediately.
However, the client is not authoritative; it must request that the server do this. Nonetheless, I imagine the client should spawn the object immediately and somehow reconcile that object's state (e.g. position) later, after receiving an updated game state from the server.
1a) One problem is how to map the client-spawned object to the server-spawned one (or to know to undo its existence, if the server denies the request). I think I can figure this out, though I would of course be interested in any information or suggestions anyone might offer.
1b) The more confusing problem, is related to the client operating in the present, and the server in the past.
When the client spawns its object, that object's position is based on the present. If the server accepts the client's spawn request and spawns its own authoritative version of that object, that one is in the past.
How does one reconcile the difference in state between the client and server versions of the object, e.g. the positions, without that feeling weird?
My understanding is that the client normally interpolates objects based on the game state updates received from the server; that seems reasonable for objects that are not spawned by the client, because it should not cause them to jump backwards in time.
However, doing the same with objects spawned by the client would cause them to jump backwards in time, which seems like it might feel odd for the client.
- Related to the above, what happens when e.g. a client's player picks up an object?
Normally, the objects are in the past, and the fact that their positions are a bit offset in time from the player is not so noticeable. However, if a player picks up an object and starts walking around, if the object remains in the past, it would seem odd as it would lag behind the player.
On the other hand, snapping it to the player's time would seem to run into the same sort of issues as in 1b; likewise with returning the object to the past if the player drops it.
If anyone could advise me on how to research this, or offer information on how this is done, that would really help me, as I am finding this pretty puzzling.
So I have been studying mirror for like 1-2 weeks or so. I wanted to implement a third person player controller which is synced over the network and which is server authoritative. As soon as I started, I have noticed that there is a slight delay between... (yada yada, me explaining to myself that I need to use client side prediction).
So, I have been doing some digging about how to implement it. All of the examples which I've found were some kind of pseudo examples and none of them used mirror.
I have 2 ideas in mind, the first is rather simple but I'm not sure it will work and the other is going to be a hell to implement(especially for a newbie like me)
First Idea: Have 2 gameobjects on the player prefab. The first one will represent the player over the network and the second one will be the local player. The client will be able to move the local player(which wont have a network transform and therefore wont be synced over the network) but will also send the movement commands over to the server which will move the networked player. Then, the client will "listen" to the networked player's transform and implement client side prediction. Which means check if the networked transform is following the local transform(meaning all of the commands which the client has given are valid, I guess?). The client will see only his local player and the other players network player.
Second Idea: To rewrite/expand the network transform code which seems a little complex to me and I dont know if diving into it is a good idea right now...
Can the first idea work? Of course if there is something I'm missing and there is a third much simpler solution I would be glad to hear it.
Hello Reddit!
I'm building an Among Us clone, and I've implemented Client-Side Prediction just like Gabriel Gambetta suggests. Also, I have Field of View implemented, and the server only sends information about visible players, because I don't want any wallhack possibilities.
Because these two systems work simultaneously, and I'm having an issue, where a player standing behind a wall appears not instantly for another player. And it gets even worse the worse ping gets.
This is why it happens:
- Client 2 is standing behind a wall, client 1 knows nothing about him (server doesn't send information about client 2 because he is unseen for client 1)
- Client 1 peeks at the location where client 2 is standing at the server but sees nothing (because we predict game state with the information given by the server, and there is no one standing)
- At the server, client 1 gets to the point, where he sees client 2, and the server sends information about client 2 to client 1
- Client 1 receives this information and renders client 2, which results in this magical appearance.
Video-explanation is below.
How I want it to work (There server sends information about any players at the game)
I can't find any information about it on the internet. Has anybody of you guys coded something similar?
The only solution I see (which I don't like) is that the server sends information about every client in a certain radius, even behind walls (which makes it possible to implement wallhack) + I implement some anti-cheat system (which I haven't implemented yet in my entire life). But I don't like this idea, because I want a hack-free architecture.
Is there the right way of implementing Wallhackfree FoW in Client-Side Prediction architecture, or it is impossible?
I'm trying to learn how to make multiplayer games in Unreal. I already have some of the fundamentals down and have created a basic shooter that seems to work fine under a LAN environment. The problem is when I test with lag. As lag goes up, things start to get weirder and weirder, especially with shooting things.
Question 1: Does anyone have good resources for learning how to handle projectiles in a multiplayer game with lag compensation?
My game has archery. I read that I should be spawning the projectile on the client immediately, then spawn on the server, and the client should get updated to the server position eventually (sped up)?
Question 2: How to do backward reconciliation in Unreal? Does the Game Ability System already account for this?
I just started working with GAS and am just curious how it's actually working behind the scenes. Player 1 sees the other player in his sights, shoots and it's an unmissable hit. Player 2 already hid behind cover on his screen and is behind cover on the server. In GAS is this a hit, or a miss? Right now I believe most games would consider this a hit (server looks back in time to where Player 1 shot and sees if it would indeed be a hit).
Any resources available and example projects would be great!
Thanks guys.
Hey, I'm working on a directional gravity system, and I'm trying to figure out how to network the player's rotation. I want rotation to be handled using clientside prediction for a smoother gameplay experience (no need to wait on server), with an authoritative server to verify the clients action. How would it be best to go about this? Are there any good tutorials that cover doing stuff on the client but confirming the actions on the server, and rolling back if necessary? If someone could point me in the right direction that'd be awesome!
Is this something that can be achieved with the gameplay abilities plugin? I'm looking to not just update rotation, but also set a rotational velocity and allow clients to extrapolate for another client.
Hi there,
I'm making a 2D multiplayer game, a sort of mix between tee-world and Garry's mod, and everything's going pretty well so far, except for one thing I did try multiple times without ever being satisfied of it. I'm talking about client-side prediction.
So here's the thing: the world and every entity (including the player) is physical, with the client doing extrapolation on the server states.
Every tick, the client sends and stores its inputs (and predicts server tick index) in a buffer. The server builds and sends current entities states. When the client receives an input, it drops its stored inputs up to the current tick, teleports all entities to their packet state and applies every stored inputs back up until (if everything went well) the last player position.
And it works pretty well, here are two gifs illustrating this (the ghost is the instantaneous server position for debug purposes):
Left app/player has very small lag, right app/player has a lot of lag, both jump at the same time.
Ok so it looks and feels fine except for one thing: in those examples I only predicted the controlled entity (player's burger), so it's in not in the same timeframe as the other entities: every entity is updated/extrapolated to match the next server states packet (so current tick minus lag). This is not the case for the player entity because of prediction (so current tick), which means everything kinda explodes when the player tries to physically interact with other entities.
So I did remade that part using a simpler approach: let's just advance all the simulation to the current tick, doing prediction and reconciliation for everything. While still a WIP, it works well for physicals interactions but now the other players look terrible because the client tries to predict their moves, which of course doesn't work well.
So I'm asking reddit, how am I supposed to fix this? Should I predict all of the simulation except for the other players entities? What if they try to interact with other entities as well? Should I try to use a more complicated system trying to guess which entities needs to be predicted (entities colliding with the player?) and which shouldn't? I'm a bit lost at that part.
Some details:
- I did follow some tutorials from gabrielgambetta.com an
Hello, I'm new to multiplayer networking and have been struggling with client side prediction. I'd like to know if my approach is correct and if it's even applicable to grid based games.
In my game you have multiple players moving across a grid in realtime one tile at a time. The server runs at 20 ticks per second and sends a delta state update to the clients every tick. The client runs at its own framerate and keeps track of fractional ticks. When the player provides input it is handled immediately, the packet is stored locally and sent to the server. When the client receives a state update it sets the state, then runs 0.5rtt*tps ticks, applying the stored inputs between ticks when appropriate.
This results in incredibly messy behaviour that I'm sure I've messed up somewhere. Player locations are often off by one in the direction they were moving. After holding left then pressing up my character moves 1 to the right and 2 up, indicating the last left was missed by the server. Not sure where it's getting the second up from either, possibly applying it both from the input and the prediction? It's not something I expect can be debugged without looking at the code. I've tried a number of things but I can't shake feeling I've done something fundamentally wrong.
But running into these issues has me thinking, is client side prediction even applicable for grid based games? Usually if the prediction was off the correction would be unnoticable, but when working with a grid that's not the case. I tried running the program without prediction on 0.2s latency and it wasn't that bad, only slightly noticeable. 0.5s was bad, but feels like more than I need to compensate for. What do you guys think?
Making a separate post here since there have been posts of hooks detaching and what not every once in awhile, regardless of 2.0. Would also like to try and raise some awareness regarding client side prediction mechanics and roughly how it works. Feel free to discuss about how client side prediction affects your playing experience as well.
Onto the topic. Reference to this clip here, I'll try to explain why things happen as such.
Notice that there was no hitmarker made by the hook at all. Hook will give a hitmarker if it's registered as a hit by the server, even if it's detached by 2.0. Doesn't seem to be common knowledge but the client has its own viewmodel prediction for most if not all abilities / actions to make the game feel more fluid and usually give better feedback. However, in some cases, the client gives false feedback and leads to the player feeling cheated. This usually involves high ping, movement abilities being used, or death of player. There could be other factors as well, but these are just the more common ones.
In this case, MOONMOON threw out the hook before Genji dashed. As such, the client predicts based on current conditions that the hook will land, and gives the visual of it landing. However, with confirmation from the server, it rejects this prediction and simply returns the hook as if it missed entirely even if it does not look like it on the client side. Hitmarker and other damage indicators (that is not purely visual like blood etc) is the only reliable source of confirmation from the client.
Client misprediction can occur even at low ping due to other factors as shown in this clip. However, some form of client prediction is always useful to make the game feel better and let you know that you probably landed your hook and you should adjust your aim as such, rather than wonder if it landed and consider if you should aim based on the hook not landing or it landing as without client prediction, you'll get the result slower due to latency.
Client side prediction is a necessary evil and is part of the game, with which I hope more people acknowledge its existence. It can account for things like why did my Deflect not work, it made the sound, and similar issues, regardless if favor the shooter played a part. Simply put, if the client mispredicts, it's going to be misleading, but also be thankful for when client side prediction helped you.
I'm not sure how feasible it is bu
... keep reading on reddit ➡Hi,
I have a physics based games where players are rigid bodies and they collide a lot with each other.
I thought about it and I think it is not really possible to implement client prediction for the game because I have no way to simulate physics in currently in Godot. So I wanted to ask people who have experience in online game development - is client prediction the only way to go? What generally can I do to overcome this problem? It is possible to swap to another engine but its an overkill, isn't it?
I'm currently working on 2D rigid-body physics multiplayer game using Matter.js for physics (both the client and server side) and Phaser3 for rendering. Both the server and the client run the simulation and the server is authoritative.
The whole game consists of multiplayer players (who can collide with each other) and objects (boxes, balls, etc).
For now, I'm working on the client side prediction and while I understand the main concept, I just can't get it right.
Every game tick I gather the client inputs, store them locally, timestamp them and send to the server, while at the same time I start moving the player forward (by applying force). When the server receives the inputs, it processes them (by applying the same forces to the player). The server then sends the current state (coordinates, velocity, rotation, last processed input timestamp, etc) to all players at 20hz.
This is the part where it gets tricky. What I currently do, is I force the player to the coordinates sent from the server and apply the same velocity (both X and Y). After that, I remove all locally stored inputs which are older than the last processed input and apply them instantly in a single frame, by doing multiple physics steps.
With low latency (20-30ms) it works out quite well, with some jittering when rapidly changing the player direction or when I'm colliding with other players/objects, but with higher latencies 70-110ms, the prediction goes completely off. I can see the player constantly being pulled back and forth and the whole game becomes unplayable.
Example, with 90-100 ms latency
I can't wrap my head around, what exactly am I doing wrong? Is client side prediction even the correct way of handling this sort of thing in a rigid-body physics-based game?
Also, I turned off state updating from the server, and noticed that the position in the server and locally sometimes goes completely off, for example when I'm jumping, running and quickly changing direction. I believe that means that the physics engine is not deterministic?
In a small project I have some client side prediction and reconciliation for the user. This is so that the user can move smoothly.
However, they don't move as smooth as I would like. And with packets being dropped/delayed throughout the internet, it makes this worse.
For example, if I were to move the user right for a second or two, their x changes would look like this:
+5, +5, +5, +5, (+0), +5, +5, +5, (+10), +5, +5, +5, +5, (+5)
For simplicity sake, we have 5 ticks per second, and 1 tick on the server per second. Every update number not in brackets are client sided interpolation, i.e: we just move the player assuming that the move is valid (even if it isn't). The numbers in the brackets are ticks where we received an update from the authoritative server, telling us to override the current position to what the server says is our current position, and then interpolating from that point on. E.g: If the server says you're at x:100, you're at x:100. If the player is still moving this tick, your client might then display the player at x:105.
This works fine, but sometimes we get updates in the example above where the numbers in the brackets are not equal to the value in the client. When we get differences in positions from the server, such as +0 and +10, we get jitteryness. Ideally we want to get +5 from the server, because that means we received the delta update in a timely manner, not a tick earlier, not a tick later.
Perhaps we can have something smoother like this:
+5, +5, +5, +5, (+0)[+2.5], +4.16, +4.16, +4.16, (+10)[+5], +1.25, +1.25, +1.25, +1.25, (+5)
We could distribute the excess or "lack of" position over the next couple of frames (before receiving the next server delta) instead of jumping instantly. This could reduce the jumpiness of example: 5->0 (difference of 5) to 5->2.5 (difference of 2.5). Perhaps we could also distribute the "pending changes" in a non-linear fashion, and that we may also cache these changes, incase they aren't all handled in time for the next delta state.
My question is, given that it is impossible to receive these updates in a timely manner, how do we spread the interpolation to be done over multiple frames, instead of one frame?
UE automatically handles client prediction for character movement (which is nice) but I cannot figure out how to do prediction efficiently for other variables.
For example, I have an array of items (player's inventory) that I want to replicate. If I mark it with `DOREPLIFETIME` and only do logic on the server, the player is going to experience delay when interacting with his inventory because the client must wait for server to send the changes back.
My first solution was to do logic on client anyway and then overwrite the results in `OnRep_` function. This solution works but it doesn't seem efficient because the client is going to calculate correctly most of the time and the server's result are redundant.
My second solution to address this issue was to first do the logic on client, create a hash from the end state, and send the hash alongside the input to the server. Then the server can know if the need to send a correction to the client or not.
For example, if player wants to consume an item, I consume the item locally, calculate a hash of player's inventory, and send the consume request alongside the hash to the server. Then server does the logic, and creates a hash from the end state of the inventory. If the hashes match, then it doesn't need to send back the inventory to the player.
The first solution saves processing power but consumes more bandwidth. The second solution saves bandwidth but requires more processing power.
Is there any other solution to this or I'm forced to choose between these two?
Hello everyone,
I am working on a multiplayer FPS game in Unity using UNet LLAPI. My goal is to implement robust client side prediction, authoritative server, server-side reconciliation, entity interpolation, and latency compensation. I am modeling my architecture of source networking. Right now, the target tick rate for my game is 60 Hz. So, the user samples input 60 times a second and predicts a state for each time. However, it can appear choppy is the user has a higher refresh rate monitor with a frame rate higher than 60 FPS. The player will be in the same spot for multiple render frames. This problem becomes even more noticeable for update rates that are 30 or below. I was wondering if anyone could shed some light on how to alleviate this problem and produce a smoother experience? How do low update-rate games deal with this? Right now, the jitter of the movement is noticeable. I have thought of interpolation on the previous state, but this introduces a input lag for each movement.
- Quinn
First of all, I'm sorry if you can't understand since English is not my primary language.
I have been following this guide http://gabrielgambetta.com/fpm1.html for my 2D platformer multiplayer game.
However I can't do client side prediction in my game. I'll try to make an example.
[Client Perspective] My game is locked at 60 fps, the client sends to the server every frame if some input has changed and records it. For example client sends to server that key left is pressed. Client moves the player every frame, (lets say velocity is 1) so during 30 frames the client moves the player 30 pixels to the left, 1 pixel per frame. Now at frame 30 client releases the left key, sends the input change to the server and player doesn't move anymore.
[Server Perspective] Meanwhile the server receives the first input change, now every frame server moves the client player 1 pixel to the left every frame. Later it receives the second input change, the key release. Client player doesn't move anymore. Server sends X position to the client.
Now the problem. Ignoring the fact that I need to determine the order of the received package in the client and compare it with the input packages sent that have not yet been processed by the server, without even going into this. The server response will never match with my client prediction.
Why?
Because between the first packet (key press) and the second packet (key released) received by the server there may have been 25, 30, 40 or even 60 frames server side, because UDP packets are unreliable, so in the server the player may have moved 25, 30, 60, etc pixels... And in the client only 30. So when the server sends the player X position to the client it will never match with the clients X.
Someone can help me? Thank you in advance.
So I'm making a simple networked game in Unity using uLink. I'm not using any of the Utility Scripts that are included with uLink, as I wanted to learn how to do this the correct way. (They used a semi-authoritative set-up I think, because they are sending position/velocity, not input)
Here is my current setup:
My Client side character has a script that sends the latest input to the server. It also has an RPC called UpdateState that receives state data from the server. This state data includes Position, Velocity, Rotation, and a timestamp of when the state was broadcasted.
The server just takes the input data and feeds it into a CharacterController as soon as it gets it.
The problem I'm having is how to predict jumping correctly. Movement is easy, and has been working great so far, but jumping is erratic.
The way I've been figuring out movement is by doing something like this:
Vector3 extrapolatedPosition = serverPos + (serverVelocity * (currentTime - timeStamp))
Then I just interpolate from my current position to that new, "ideal" position. If they are very close then basically no movement happens. However, when I jump, things get weird. Especially if I'm jumping over and over again. I start bouncing all around on the client.
What is the standard way of using client side prediction to predict, and correct, jumping?
I should also mention that I've read the Valve networking article and various other networking guides and tutorials and still haven't seen this mentioned.
I had a client contact me for some sysadmin work a few years ago. I did it, but told them their code was running on PHP 5.4 and needed updating, plus server migrating. They initially agreed to the quote, then backed out after I'd done it (I didn't deliver, and no contract). I just migrated the server and charged them for that.
Anyway, their business relies on outbound connections. Guess who suddenly can't connect to their upstream providers, and now it's an emergency.
Sorry bro. I'm busy. And the quote has gone up 50%, even if I still have a copy of that new code somewhere.
Your lack of preparation isn't my emergency. Here's a bill for diagnosing the problem.
Hey guys,
You've probably seen me post and ask about networking around the place, such as the recent post here, and I've spoken to some of you one-on-one (thanks again, /u/acren) about it as well.
I've really tried to solidify my understanding of client-side prediction + server reconciliation, as described here by Gabriel Gambetta.
Here's some of my questions on this matter, paraphrased from some of my direct communications. When I say 'the example', I'm referring to the article I've linked above.
I think the root of my misunderstanding comes from not knowing how the server and client actually coordinate. When the client sends an input, the example has it also sending a number for which action it is in an ordered sequence. It's then got the server replying with the updated position/rotation and that same number, so if there is a disagreement, the client can roll back its physics to the server’s, and resimulate inputs from the action at the given index and all that follow. This makes sense until you have physics-based movement that takes time to execute - the position doesn’t change immediately - as well as wanting the server to correct the client not just when reacting to input, but in other areas too, i.e. collisions. If the server only tells the client where it should be after receiving input, a player not pressing any keys will never be told where to be or how to respond to a server-based collision.
At first I presumed one could just have the server constantly sending the physics information to the client, based on the input it receives, but I wasn’t sure how to ‘timestamp’ it. Would you send an in-world time value that’s synchronized across the network? I.e. the client and server have the exact same time value increasing over time, and the server says ‘At time x, you were here’, and the client resets to the sent physics state and finds and processes all input since then. In that example, the input is stored in a buffer using the same system of timestamping. The only reason I thought this might not be correct is the example's point that the server and client are actually playing through the world at different in-world times.
Additionally; when the server does reply with a timestamp, what should be done if that falls between input buffer entries? I.e. at T=0 and T=5 I have input, b
... keep reading on reddit ➡Spent the afternoon trying to sift through linked articles on how to accomplish Client-side prediction and reconsiliation using an authoritative server. Following links posted here and /r/Unity3D, I read through Valve's writeup of how they handle it, and a few others.
Being a hobbyist/noob at this, my take on it was to move the player on the server as I had been, using a command from the client and moving it directly on the server. I then removed my NetworkTransform from the player and tried to write my own.
Here is the code if you want to take a look, I'm sure its horribly written so my apologies for that, I'm trying.
Continuing, I setup a function to invoke every 0.1 seconds, as my sendRate. In this, I send the server my inputs to move the server side player as stated above, and I also called a function (only for local player) that will move the player client side, the exact same way.
While this is occuring, the server is syncing a vector2 of its position each time the command is run. A hook on this variable runs a function on the client that adds this variable each time it changes to a dictionary with the key being a time.
In the function that the player is using client side to move itself dependent from the server, it does the same thing, each time it fires, at the same rate as the command is run, it adds its position to a separate dictionary with the key being a time.
I thought that here I could check if the client's dictionary, which should be ahead and therefore its entries be more/more recent than the servers, contained the key of the most current server entry, since both time variables are (time.time) rounded to the nearest tenth, which would allow me to calculate the amount of error there was between my local player and its actual position on the server.
Running this using the matchmaking yields 100 latency, which I assume (using NetworkClient.GetRTT()) is the right way to get latency... and it seems correct. The keys of the two dictionary's seem awfully close in time, but this can't be the way to compare the two because they hardly ever match up to compare one to the other based on the time stamp.
Comparing one to the other without latency basically works as both add an entry pretty much every 1/10th of a second, but my error in positions isn't quite right I don't think without ADDING the amount of time the server is behind the player's timestamps to account for latency. If I compare the server position
... keep reading on reddit ➡If one of the administrators working under my webhost decide to grab my encryption keys and have a snoop around my files, they can do it extremely easily as encryption keys are stored on the server itself.
If only we had client side encryption.
Do we have any workarounds for that?
