---
tags: Meetings
---

# 12/1/2022 Meeting Notes
-Sean, Sam, Juuso, Jakob, Eric

## Path forward:
**- Simplest of models to start with**
- Watcher model could be (to some degree) included in normal broker operations
- Problems:
occasional signing of messages between nodes so far rudimentary
time-varying aspect (topology constantly changes)
signing on each node would induce latency
- Potentially workshop needed with network team
- **Scoping / benchmarking other projects (Helium - authoritative packet approach)**

### Possible implementations:
- Have to sign everyone and have everyone sign you as possible implementation
- Receipts are windowed according to timestamps of the actual messages
- Propagate trust across network

### Kick Out Voting Proposal V1
- Link to document: https://hackmd.io/iq1S1DK7QyuWtsevKll24g
- This first proposal uses the watcher model as a basic implementation
- Only cost of changing identity is min. stake
- No cost of leaving -> anyone can leave with their stake (after waiting period)
- Sponsor cannot just slash anybody at will since its abusable
- If brokers leave before being slashed -> would also be preferable
- Q: On SC level what does it mean to be kicked out?
- not sharing bounty rewards anymore
- Sometimes bad brokering is related to accidents / bugs / bad network etc, not always malice

### Watchers model (random query)
- Already planned in network team: Push receipt signing into network -> add investigators / bad brokers to find them
- first approach maybe to randomly ping nodes
- If I'm a broker in the network and a neighbor is not giving me the data, they are putting me at risk, so I want to report them (Broken links of messages are a risk to brokers)
- Potentially queue of flagged brokers (hints) for watchers to audit
- Could provide hints/flags to the watchers to try and get a node audited (to reduce overhead)
- Sponsor of bounty could receive voting power (maybe also on network layer)
- if sponsor nodes have trust in other nodes in a specific stream they could be allowed to select neighbours -> problem with voting power is that even if I have interest in the topology I have no insights into interactions in topology at other parts of the network, so I can never know for sure if they sent the messages to each other, unless the cheating node is directly my neighbour)
- **Problems**:
- "Malicious" seeming brokers might only have network issues
- Even if I can connect directly to target node they might collude to force me out
- no insights into interactions in topology at other parts, can never know for sure if they sent the messages to each other, unless cheating node is directly my neighbour
- hard to make substantial proofs about anything, but can work with receipts and query/response
- if you can't choose your neighbours the ability to cheat is harder
- Before there was a tracker that assigns who to ping -> can be gamed by reporting to tracker that you didn't reach the assigned one so you get new one's assigned until you find someone you can collude with (new system is without tracker)
- Messages are only one-directional, so in a scenario where a node is closer to the msg source, that node might only ever send but not receive msgs to specific neighbours; Broker is not malicious in that case but might seem like it
- Certain case where someone gets the message before you and only sends it to you

## Kick Out Voting Due Diligence
- Link to document: https://hackmd.io/4Fj3AcwMROGqgdMbZeGBAw?view#Kick-Out-Voting-Due-Diligence
- Could potentially compare brokers to ETH validators or the thegraph indexer
- However: Brokers choose which bounty to join so collusion is easier than random allocation for validators
- Comments:
- Solving for free riders might make greedy brokers worse or vice versa
- Controlling should probably be done by other entities than brokers (such as in data unions)

### Performance measurement / Receipts:
- Q: Does a broker transmit stream data directly to the user or between other brokers or both?
- A: All nodes tend to propagate msgs to other nodes (except for proxy nodes, which are a way to get a client-server model)
- There's no real way to prove anything for certain right now
- Network team has tested: Every now and then a node can sign a receipt and send to others to sign off on it too. This can later be used to attest performance if suspicions arise
- Prototype: Send N messages, sign receipt that N messages were received: Receipts can defend against greedy broker problem
- ask neighbors for whether work has been done -> Broker could collude with neighbours or neighbours can work against you
- time varying issue: Topology can constantly change (In a static network asking neighbors for receipts might work, but since network changes at all times this is not easily possible due to churn / constant neighbour change)
- Query request: Every node can respond to request for receipt of "i have sent you this" right now
- only brokers are actively requesting receipts, but any node should be queryable for these requests
- can be abused by spawning new nodes and colluding
- broker could collect signed receipts to prove against fraud accusations, but again gameable
- Random neighbors, topology doesn't change -> works reasonably well, but is not a final solution
- Network is essentially a random graph
- Nodes could connect directly browser to browser
- Usually 4 neighbours per stream, but this is a parameter that can be changed
- Q: Multiple brokers work for same stream, could they have to talk to each other?
- Broker nodes can be programmed to sign each others receipts (overhead though)
- Could have someone subscribe just to measure performance (sponsor -> watcher -> broker)
- Investigating everyone gets too expensive very fast -> have to have reasonable cause for investigation -> ask neighbours potentially
- Join bounty -> sign others and get signed
- Property of receipts: windowed according to timestamps of actual messages
- Sponsor could target suspects directly
- Actual nodes often don't just send data, route data through the network
- Could be connected as a broker and be routing to other brokers
- For routing you could ask a neighbor if they got it, but this could also be faked
- Spawn node and other nodes that are neighbors and collude is an attack vector
- Broker could also get signed receipts from neighbors

### Payments:
- Current implementation is stake-weighted revenue sharing
- Good actors: Needed to support the network, beyond receiving compensation their incentive is to keep the network running
- Pick policy / slashing policy: brokers: There's a minimum time you need to be staked (eg. 2weeks), only after that time can you leave again without slashing
- no timeweighting logic in allocation policy currently but would be possible, (bountys could be: Only stake weighted, only time weighted, both)

### Stream payments:
- Sponsors add money as long as they perceive the stream as useful
- Smart contract could top up bountys
- Data union/smart contract could also top up bounty, Could be automatic and come from payments on data unions