Design Elements » History » Revision 7
Revision 6 (Suravi Regmi, 11/21/2025 07:39 PM) → Revision 7/8 (Suravi Regmi, 11/21/2025 07:42 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]]** 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]]** 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]]** 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 Pub-Sub API Design (MGuard Perspective)]]** Perspective) Producer API: publish() Consumer API: subscribe() Callback delivery Reliability guarantees