docs: add directory storage redesign notes

REDESIGN.md

@@ -473,6 +473,127 @@ Use new processes only where shared state, isolation, and lifecycle justify the
 extra IPC complexity.
 ```
 
+
+## Future NetWare 4.x directory, LDAP, and storage direction
+
+NetWare 4.x support should not be added by letting `nwbind` grow into a second
+large catch-all service.  The long-term directory design should keep the legacy
+Bindery, the future NDS compatibility layer, and the LDAP protocol frontend as
+separate logical layers above one shared directory store.
+
+The intended naming model is:
+
+```text
+libflaim
+  persistent embedded database engine
+
+directory core/store
+  mars-nwe object model, schema, indexes, ACL/auth primitives
+  persists its data through libflaim
+
+nwdirectory
+  mars-nwe service name for the integrated tinyldap-derived LDAP service
+  owns LDAP/LDAPS/StartTLS protocol handling
+  uses wolfSSL only at the LDAP network/TLS edge
+  calls the directory core/store, not Bindery or NDS packet handlers
+
+nwnds
+  future NetWare 4.x/NDS compatibility layer
+  owns NDS/NCP directory semantics, contexts, tree-oriented operations,
+  NetWare-specific rights/auth behavior, and later compatibility glue
+  calls the directory core/store directly
+
+nwbind
+  legacy NetWare 2.x/3.x Bindery compatibility layer
+  maps Bindery objects, properties, sets, security, and login-visible behavior
+  onto the shared directory core/store where possible
+```
+
+In this model, `nwdirectory` is not a separate design from tinyldap.  It is the
+mars-nwe integration name for the tinyldap-derived LDAP directory service, so
+that the installed binary/module follows the existing `nw*` naming scheme.  The
+upstream tinyldap code can provide the LDAP protocol implementation, but the
+project-facing component should be named `nwdirectory`.
+
+`nwnds` should remain a separate layer because LDAP is only one protocol view of
+the directory.  NDS has NetWare-specific semantics that should not be forced into
+the LDAP frontend.  Conversely, LDAP clients should not be required to pass
+through the NDS/NCP compatibility handler just to reach the directory database.
+The preferred relationship is sibling frontends above one core:
+
+```text
+                         +----------------------+
+                         | directory core/store |
+                         | backed by libflaim   |
+                         +----------+-----------+
+                                    ^
+                    +---------------+---------------+
+                    |                               |
+              nwdirectory                         nwnds
+       tinyldap-based LDAP/LDAPS          NetWare 4.x/NDS semantics
+       frontend, wolfSSL TLS edge         NCP/NDS compatibility layer
+                    ^                               ^
+                    |                               |
+              LDAP clients                 NetWare/NDS clients
+```
+
+The legacy Bindery service should also move toward this shared store over time:
+
+```text
+NetWare 3.x client -> Bindery NCP -> nwbind -> directory core/store -> libflaim
+LDAP client        -> LDAP/LDAPS -> nwdirectory -> directory core/store -> libflaim
+NetWare 4.x client -> NDS/NCP    -> nwnds -> directory core/store -> libflaim
+```
+
+That means `nwbind` should become a compatibility mapping over directory objects
+and attributes instead of maintaining a completely separate long-term identity
+truth.  This is especially important once NetWare 4.x/NDS support exists, because
+Bindery compatibility can then be implemented as a legacy view of the same
+underlying users, groups, properties, and rights data.
+
+The internal path should not be:
+
+```text
+nwbind -> LDAP protocol -> nwdirectory -> directory store
+nwnds  -> LDAP protocol -> nwdirectory -> directory store
+```
+
+Using LDAP as the mandatory internal storage API would mix protocol concerns into
+server internals, make old Bindery behavior harder to preserve, and add needless
+encoding/search semantics between tightly coupled modules.  LDAP should remain an
+external protocol frontend.  `nwbind`, `nwnds`, and `nwdirectory` should all use a
+shared directory-core API or a clearly defined IPC protocol to the directory
+store.
+
+FLAIM should therefore be treated as the long-term persistent storage engine for
+the directory core, not as an LDAP-only database.  The directory core owns the
+schema, object model, indexes, transactions, ACL checks, and authentication
+primitives that the protocol/provider layers need.  `nwdirectory` exposes those
+objects through LDAP; `nwnds` exposes them through NDS semantics; `nwbind` exposes
+them through legacy Bindery calls.
+
+Kerberos should not be part of this initial design.  Classic NetWare 4.x/NDS
+compatibility should focus on native NDS-style authentication and directory
+semantics.  If a later eDirectory/NMAS compatibility effort ever needs Kerberos,
+it should be considered a separate future authentication-provider topic, not a
+requirement for the `nwdirectory`/`nwnds`/`nwbind` split.
+
+The migration path should be conservative:
+
+1. add the design boundary and naming notes first;
+2. import or integrate tinyldap under the project-facing `nwdirectory` name;
+3. keep wolfSSL confined to the LDAP/LDAPS/StartTLS network edge;
+4. introduce a directory-core abstraction before making Bindery depend on it;
+5. map selected `nwbind` objects/properties to the directory core only after the
+   legacy behavior is documented;
+6. add `nwnds` later as an NDS semantic layer, not as an LDAP wrapper;
+7. only then consider replacing private Bindery persistence with libflaim-backed
+   directory storage.
+
+This keeps the future NetWare 4.x work aligned with the provider/process split:
+`nwdirectory`, `nwnds`, and `nwbind` may be separate processes or modules, but
+they should not be separate sources of truth for identity and directory data.
+
 ## Logging connection
 
 The dispatch redesign also supports the desired log cleanup.  If every request