Design Elements » History » Revision 3
Revision 2 (Suravi Regmi, 11/21/2025 06:42 PM) → Revision 3/8 (Suravi Regmi, 11/21/2025 07:31 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 anchor
Component identities
Cert verification
Signing chain
What each module verifies
### 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
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
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
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 Design (MGuard Perspective)
Producer API: publish()
Consumer API: subscribe()
Callback delivery
Reliability guarantees