-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDESIGN.txt
164 lines (128 loc) · 6.32 KB
/
DESIGN.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
Project Aims:
- Can implement realtime-ish chat on top
- Should work on high latency links
- Low bandwidth links
- Both high and low connectivity meshes
- High and low density meshes (sometimes may just be a chain of single links)
- 0 trust of neighbours required
- Should be possible to hide the channels you are in
Applications:
- P2P chat on mobile devices at crowded events, e.g. festivals
- eventually consistent with outside world/people not there
- IRC/Matrix replacement
Stretch goal applications:
- emergency communication (see: serval)
- audio calls
- video calls
- IoT device communication
- file sharing
Nodes have list of subscriptions
Subscriptions come from generators: channel id hashed with counter
Subscription packet contains aggregated subscription prefixes
Different links may set different lifetimes for subscriptions.
- Want to avoid the need for "unsubscribe": only way to unsubscribe *now* is link-down
- Should be some timeout based on medium?
What do you do if you get *too many* messages in reply to a subscription?
- How do you know it's in reply to a subscription? (vs e.g. randomly generated messages)
- How to know it's not spam data
- Approach 1: keep first message received
- Approach 2: keep last message received
- Approach 3: keep or drop at random
- Prefer local subscriptions over neighbour subscriptions?
- Is this a potential side channel for a neighbour to figure out your local subscriptions?
- Forward before drop?
- "store-and-forward" vs "forward-and-store"
- Subscribe to less in future?
What do you do if you get *very little* data in reply to a subscription
- could be in isolated part of network
- subscribe to more (larger prefixes? expand your local counter(s)?)
Channel has secret ID
- On creation, pick random unsigned counter value to use?
- ID is channel public key?
To send to a channel, you encrypt your message with the channel secret key and store it
If/When another nodes sends has a subscription that matches, you send it across the link
Concept of "channel relay": knows generator, but doesn't have ability to decrypt contents
"proof of relay": is it sufficient to just subscribe to a specific message (e.g. with random known-to-be-published counter) to check that a relay is doing what it promised?
Idea: when node sends new subscription packet:
- own subscriptions (vary counter)
- send *some* of neighbours subscriptions.
- prefixes may be deaggregated
- node should keep a record of link peer subscriptions and rotate through them
How to prevent all messages being stored forever? How to prevent traffic metadata to be extracted from a relay?
Resource constrained devices
- Could be constrained in different ways. e.g. cpu vs network vs storage vs memory
- Use more exact subscription prefixes.
Why is counter not public?
- How to prevent neighbours figuring out your subscriptions?
Idea: multiple possible subscription prefixes that match a single message?
Related: maybe the subscription prefix comes with a nonce/random value that is used?
Idea: counter based on wall clock hour?
Idea: counter period configurable per channel? (Probably can't be changed after creation?)
Idea: time bots
Channel rotation: new channel created; advertised in old.
- new key
- new feature set/configuration
- new generator parameters?
- to add/remove participants?
- resets counter
Problems:
- who does the rotation? What makes them authorative? Race between multiple coordinators?
- channel relays would need to be told about new params
Problem: freshly booted relay: neighbour does subscribe all. Channel history metadata (number of messages/sizes) leaked?
- Is it a secure/privacy respecting solution to simply store some other messages too?
Fake message/traffic generation?
Hope: built in spam protection: only useful/subscribed messages get relayed for long
- Propagation of messages decrease exponentially with each hop in a busy network?
Idea: Messages contain in-reply-to field?
- Should be able to be in-reply-to multiple things
- Nodes can then subscribe to any missing parent messages and recurse to get history
Idea: user channel: node always subscribes to private channel about self. Can be used to send invites?
Problem: amplification attacks: a single subscription message could result in many messages.
- Require transport to have a handshake? (NOTE: UDP transport design restriction!)
- Amplification attacks in shared mediums is a weird concept
Terminology:
- Generator: a mathematical function that give a channel id and a counter, derives a possible message bucket
- Channel:
- Channel Repeater: knows generator, channel id: will repeat messages that match attempted counters
- Link: can be 1-1 or broadcast
Usually the first message on a link is a subscription message.
- Peers are free to ignore
Though published messages may be unasked for.
- Emergency broadcast system?
- Can always receive messages that you never subscribed to
- Out of band subscriptions?
Message size guides (bytes):
- SMS: 140
- Zigbee: 100(?)
- IPv4: 576
- UDP over IPv4: 508
- IPv6: 1280
- Firebase Cloud Messaging (FCM): 4096
- Apple Push Notification Service (APNS): 4096
Messages should have packetization.
- Use in-reply-to
Protocol enclosure (this could be out of band. e.g. a http header; or xmpp enclosing type; etc)
- Type (subscriptionlist/message)
Subscription List:
- list of message id prefixes
Message:
- Public:
- message id
- derived property: hash
- Inside envelope:
- counter
- is-continuation (related to packetization)
- in-reply-to
- list of message ids + hash of entire message?
- payload
- should be an extensible format
- cbor?
- optional compression
- selectable compression algorithms? (gzip vs xz vs ... )
- what does this mean for client compatibility?
- should support binary data (e.g. sharing emojis/"stickers"/images)
- stickers: support reference to some other message that is the sticker?
Storage model:
- Message ids and matching by prefix would seem to fit a btree quite well.
References
- "Spray Routing": https://www.researchgate.net/publication/3335442_Efficient_Routing_in_Intermittently_Connected_Mobile_Networks_The_Multiple-Copy_Case