Design Elements » History » Revision 8
Revision 7 (Suravi Regmi, 11/21/2025 07:42 PM) → Revision 8/19 (Suravi Regmi, 11/21/2025 08:22 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