Project

General

Profile

Design Elements » History » Version 9

Suravi Regmi, 11/25/2025 05:28 PM

1 1 Suravi Regmi
# Design Elements
2
This is the technical reference section.
3 4 Suravi Regmi
4
### **[[Naming_Scheme|Naming Scheme]]**
5 1 Suravi Regmi
6 9 Suravi Regmi
Stream naming hierarchy 
7
Manifest naming
8 1 Suravi Regmi
9
10 5 Suravi Regmi
### **[[Trust Model|Trust Model]]**
11 1 Suravi Regmi
12
Trust anchor
13
14
Component identities
15
16
Cert verification
17
18
Signing chain
19
20
What each module verifies
21
22 6 Suravi Regmi
### **[[Access Control|Access Control + Policy Structure]]**
23 1 Suravi Regmi
24
New policy structure (requester, allow/deny filters)
25
26
Example policy with evolution from old โ†’ new format
27
28
Filter semantics
29
30
Mapping to attributes
31
32 7 Suravi Regmi
### **[[NAC-ABE Design|NAC-ABE Design]]**
33 1 Suravi Regmi
Why KP-ABE
34
35
Data encryption โ†’ CK encryption โ†’ CK decryption
36
37
ABE encryption of CK (black box)
38
39
ABE key issuance (DKEY)
40
41
CK granularity (second/minute/hour)
42
43
Tradeoffs of CK reuse level
44
45 7 Suravi Regmi
### **[[Manifest Design|Manifest Design]]**
46 1 Suravi Regmi
47
Why manifests exist
48
49
Manifest format (full data names + digest)
50
51
Creation triggers: count/time threshold
52
53
Sequential numbering scheme
54
55
How manifests replace per-data sync announcements
56 7 Suravi Regmi
### **[[PSync Design|PSync Design]]**
57 2 Suravi Regmi
58 1 Suravi Regmi
59
Why PSync is used
60
61
How the sync list works conceptually
62
63
Manifest announcement via PSync
64
65
Differences from classical pub-sub
66
67
Limitations / assumptions
68
69
Boundaries (MGuard-specific usage, not raw PSync theory)
70 7 Suravi Regmi
### **[[Pub-Sub API|Pub-Sub API Design (MGuard Perspective)]]**
71 1 Suravi Regmi
72
73
Producer API: publish()
74
75
Consumer API: subscribe()
76
77
Callback delivery
78
79
Reliability guarantees
80 8 Suravi Regmi
81
### **[[Repo|Repo]]**
82
NDN-Python Repo and its ussage in MGuard