diff --git a/sdata/dist-nix/README.md b/sdata/dist-nix/README.md
index 5febf4698..c027518d8 100644
--- a/sdata/dist-nix/README.md
+++ b/sdata/dist-nix/README.md
@@ -5,6 +5,13 @@
 
 **NOTE: The sdata/dist-nix is not for NixOS but every distro, using Nix and home-manager.**
 
+As we all know Nix and Home-manager has two major functionalities:
+- Handling dependencies (i.e. package installation)
+- Handling dotfiles
+
+They are discussed below.
+
+# Handling dependencies
 ## plan
 Note that this script must be idempotent.
 
@@ -29,3 +36,41 @@ See also https://github.com/caelestia-dots/shell/issues/668
 
 ### NixGL
 On non-NixOS distros, packages installed via home-manager have problem accessing GPU, especially Hyprland because it requires GPU acceleration to launch. `nixGL` should be used to address the problem.
+
+# Handling dot files
+
+## Requirements
+About handling the dotfiles, i.e. `dots/`, if we are doing this using Nix then the following requirements must be fulfilled.
+
+**1. Allow modifications over the existing dotfiles.**
+
+Current state of `./setup install`:
+- After finishing running `./setup install`, users can modify any dotfiles in a traditional way, and if they run `./setup install` again to update then they need to skip the steps which overwrite the targets that they have modified and later sync the upgrade manually for such targets by themselves.
+  - For Hyprland, specially we have a `custom` folder along with `~/.config/hypr/hyprland.conf` which will only get overwritten the first time but not the later times running `./setup install`.
+- This works but is not elegant. An experimental solution is using yaml config to store the selected behavior for each target, see #2137.
+
+If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation.
+
+**2. Allow choosing targets.**
+
+This is similar to the above. For example user may want to use their own `~/.config/foot` instead of the files under `dots/.config/foot` entirely.
+
+**3. Easy developing dotfiles or at least not worse than current state.**
+
+About the current state:
+- @clsty: "If I were the one who develops the dotfiles, I will make changes to the local Git repo `dots-hyprland` and rerun `./setup install-files -f` to apply the changes to observe the outcome."
+- @end-4 (who develops the dots; see [comment](https://github.com/end-4/dots-hyprland/pull/2278#issuecomment-3454929577)): "I modify my local copy of stuff, copy the relevant parts over, optionally selectively pick changes then commit. It's.... the most obvious way but I guess not necessarily the cleanest"
+
+If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation.
+
+**4. Others**
+
+Find out a good method to avoid what @end-4 [mentioned](https://github.com/end-4/dots-hyprland/issues/1061#issuecomment-2954725029):
+
+> About home-manager, from my limited understanding of and experience with it, any change to the config files require a rebuild right? If this is indeed the case, switching entirely to this is not okay. Having to wait 20 seconds for each change is absurd.
+
+Some information may help, e.g. @darsh032 [commented](https://github.com/end-4/dots-hyprland/issues/1061#issuecomment-3336839862):
+
+> I mean thats not really needed you can use mkOutOfStoreSymlink or use hjem-impure to change the configs without rebuilding
+
+And also the "hmrice" [mentioned](https://github.com/end-4/dots-hyprland/issues/1061#issuecomment-3353345504) by @Markus328 , and the `flake.nix` (for quickshell only) [mentioned](https://github.com/end-4/dots-hyprland/issues/1061#issuecomment-3354387126) by @darsh032 .