Design Elements » History » Revision 9
Revision 8 (Suravi Regmi, 11/21/2025 08:22 PM) → Revision 9/19 (Suravi Regmi, 11/25/2025 05:28 PM)
# Design Elements This is the technical reference section. ### **[[Naming_Scheme|Naming Scheme]]** Stream naming hierarchy (include diagram from paper) Data naming: /org/md2k/.../DATA/<timestamp> Attribute names (/org/md2k/ATTRIBUTE/...) Manifest naming (.../MANIFEST/<seq>) CK naming conventions DKEY naming conventions PUBPARAMS naming ### **[[Trust Model|Trust Model]]** Trust anchor Component identities Cert verification Signing chain What each module verifies ### **[[Access Control|Access Control + Policy Structure]]** New policy structure (requester, allow/deny filters) Example policy with evolution from old → new format Filter semantics Mapping to attributes ### **[[NAC-ABE Design|NAC-ABE Design]]** Why KP-ABE Data encryption → CK encryption → CK decryption ABE encryption of CK (black box) ABE key issuance (DKEY) CK granularity (second/minute/hour) Tradeoffs of CK reuse level ### **[[Manifest Design|Manifest Design]]** Why manifests exist Manifest format (full data names + digest) Creation triggers: count/time threshold Sequential numbering scheme How manifests replace per-data sync announcements ### **[[PSync Design|PSync Design]]** Why PSync is used How the sync list works conceptually Manifest announcement via PSync Differences from classical pub-sub Limitations / assumptions Boundaries (MGuard-specific usage, not raw PSync theory) ### **[[Pub-Sub API|Pub-Sub API Design (MGuard Perspective)]]** Producer API: publish() Consumer API: subscribe() Callback delivery Reliability guarantees ### **[[Repo|Repo]]** NDN-Python Repo and its ussage in MGuard