Do I need a salt for Scrypt if the data is client-side? I have a web app, in which I am encrypting user data client side. Each client has their own password, which is used to derive an encryption key (via Scrypt) for encrypting their data. Since the data is client side and a hacker has full access to the (encrypted) data, would it be necessary to use a salt for Scrypt? The reason why we use a salt for KDFs is to reduce rainbow tables affecting web servers. Since there is no web server in play here, and the attacker can attack however they like, then a salt would provide no additional benefit, am I correct?
Can you guarantee that the users are going to use high-strength passwords like dicewire? What if they are using simple passwords? Are they going to sue you when they are hacked and their data exposed? Lots of questions?
Consider that all of your users are hacked due to a bug in your application, then the attackers can execute a batch attack, too. Using salts can prevent this batch attack.
Using salt is the countermeasure to the rainbow tables where applicable. Therefore you limit them to single searching. In this case, two vectors remain

How good are the users' passwords?
How much can the password hashing algorithm slow the attacker?

The answer to the first question has a human side. You can test the quality of passwords up to some point and reject if lower. Teach your users to use the dicewire. Not hard to learn, see XKCD 936
The second question has a better answer as the Argon2id is the best choice. You can parametrize;

Number of iterations $t$, affecting the time cost.
Size of memory used $m$, affecting the memory cost.
Number of threads $h$, affecting the degree of parallelism.

This parameter must be tuned according to your target systems.
Therefore you can limit the attackers to use Massive GPU/ASIC parallel search mostly single case and with the timing, you can cripple their effort.
The recommendation is to use the salt, it is not hard to generate one by using /dev/urandom or similar methods.
And remember that the entropy and output cannot exceed the entropy of the input. Make sure that users have high-strength passwords.