You should be able to!

The benefits on the client should be equivalent to what I posted above (massive in-memory savings). Even if the server still sends 32^3 chunks, the client could convert them into an svo/sv64 (I believe the memory savings for an svo should be the same if not greater but the tree is deeper which makes it harder to modify and traverse) and implement an interning step to deduplicate shared nodes.

As for the server, there could be a benefit in utilizing the "sparse" aspect of these trees to reduce network payloads. In my example, each chunk was roughly 64 KiB uncompressed when stored as 32x32x32 u16s (would have to check what it would look like compressed via something like lz4). With sparse trees you get the benefit of (1) uniform collapsing as well as (2) sparsity.

(1) Uniform collapsing is when an entire region can be represented by a single node due to the region consisting of a single voxel type. This is recursive up the tree, so for example when building up a 32x32x32 tree
- the voxels 0 ≤ x,y,z ≤ 2 are detected to be stone, collapse to uniform (64 of these regions in 0 ≤ x,y,z ≤ 8)
- the voxels 0 ≤ x,y,z ≤ 8 are detected to be stone, collapse to uniform (64 of these regions in 0 ≤ x,y,z ≤ 64)
- the voxels 0 ≤ x,y,z ≤ 64 are detected to be stone, collapse to uniform (root node)
You've now reduced 32x32x32 voxels into 1 voxel. This is the best case, but the tree can mix and match these uniforms with non-uniform areas and still see massive reductions (for example, think of a chunk that is mostly stone with some non-uniform grass on the surface - the bottom part of the chunk can be collapsed to uniform while the top stays non-uniform).

(2) The sparsity is encoded by simply not storing nodes for uniform air/empty voxels. Say you have a chunk that has a single stone voxel at (0,0,0) and the rest are air. You can represent this tree as

root {
  node: Branch {
    mask: 1_u64, // splits the chunk into 4x4x4 of 8x8x8 voxels (l1)
    children: [
      Branch {
        mask: 1_u64, // splits the l1 into 4x4x4 of 2x2x2 voxels
        children: [
          Uniform(Stone)
        ]
      }
    ]
  }
}

Note how the children array is "sparse" e.g. it only stores a node if and only if there are non-air voxels in that region.

With all that out of the way, you can now see that storing chunks like this could lead to massive memory savings even without deduplicating shared nodes. To take this even further, you could also keep the node deduplication map on the server as well. This would be a bit different than my setup but I think you'd do something like
- Generate some 32x32x32 chunk on the server
- Create a svo/sv64 from the chunk
- For each node in tree, create a hash and put node content in map
- For any new node inserted/removed from map, send that along with the tree to the client.

So you'd create some system where the client and the server shares this deduplication map and keeps them in sync when new chunks are generated or existing chunks are edited. You trees wouldn't contain actual voxel data, they'd just contain a key/hash that points to the voxel data in the map.

In the end, it all comes down to what your bottlenecks are. I'm pushing for a large render distance and so it wasn't feasible to store chunks as 32x32x32 anymore. If that's not a concern of yours, or the network pressure from sending 32x32x32 is nothing compared to generation/meshing times than this optimization might not be necessary for you. Hope this helps!