In order to make sure we are not tight to a specific transport (currently whisper), different models of operations will be explored:
If not specified it applies to all.
The main differences and properties are:
We have a few options, some of them can be used in conjunction (i.e Donations can be always
built on top of other methods).
Removing status-run nodes on the network has certain implications, which are common
to some/all the methods listed above, so some questions needs answering:
[Oskar: I think having a list of bootstrap nodes is OK, especially if we only have few of these, and people can modify this. Similar to how BT works ~. Though you wouldn't get as 'decentralized'/coordination-less as, say, SSB.]
– [Oskar: could you elaborate?]
– [Andrea: Forwarding nodes membership is dynamic and possibly a user will have to pay, if the user is to select a forwarding node (or even if it is selected automatically), how can we have a discoverable list of nodes (with potentially pricing information)?]
– [Oskar: IMO this is solved if you have a data sync layer, as you know parent message id and can detect if messages are missing]
– [Andrea: Not really, certainly it might help, but simple case: you go online after being offline for a while, you want to catch up on chat x, you ask mailserver/peer for data in group x, they have not the most recent data. Your parentID will be from a while ago, and you won't be able to know that there's more recent data. Also looking at briar parentID is an optional field, and only used for replies.]
– [Oskar: Right, I was imagining that's an "honest" intermittent connection, i.e. that node simply happens to be less useful. In reality I imagine you'd have multiple nodes, and if someone offers newer with more proven parent ids, then that'd be de facto more useful and act as proof itself that it has more 'uptime' (=useful new info). ]
– [Oskar: would be useful to be explicit about what we mean by 'darkness' as it isn't a technical term IMO - what type of anonymity is lost and under what threat model? that said I agree]
– [Andrea: What kind of guarantees on sender & receiver anonimity (could be either or) if transactions are involved. The attacker would be anyone having access to Ethereum blockchain info, assuming we use SNT for transactions.]
– [Oskar: seems fair and like a good starting point]
Using whisper this method is complicated by the fact that every envelope is flooded to the network, so multiple paths are possible from point A to point B.
This would simplify things as a single path is actually followed, and similar strategies have been proposed https://www.freehaven.net/anonbib/cache/raykova-pet2008.pdf . It slightly complicated by cover messages, but probably just a matter of fleshing out details.
Every user will have to paid for sending and receiving messages.
This payment form could be potentially a subscription.
– [Andrea: thanks good suggestions, I Will expand both points and elaboarte on the options suggested.]
Every user will have to paid for receiving messages when offline.
This payment form could be potentially a subscription.
[Andrea: Here the assumption is that nodes are not paid to forward messages, only for storing offline messages. I need to make that clearer]
With whisper a mailserver would have to collect all the data in the network as the receiver is not known.
In this case all the offline data would be stored in a provider (a trusted node, that is aware of which messages are for you), so no darkness is provided.
A potential issue in applying only this method of incentivisation is that mix nodes would need to have other incentives to forward messages, as you can't be both a provider and a mix node.
[Oskar: In Loopix I agree; I'm not 100% sure if this definitely needs to be the case.]
[Andrea: yes, seems like something that there quite a lot of different options]
A few ways to address offline storage:
One is to keep things as they are (each mailserver has their own local copy of the data). In this case mailservers need to provide a proof that they have the data for the time span we are interested in, otherwise the user might not get all the historical data available. Some thoughts are here https://hackmd.io/s/H1ZW4MMfV.
Another possible way is use something like ipfs and filecoin, where a user would ask the mailserver to pin their envelopes and the problem shifts on how to make it indexable on ipfs. This option has some advantages, but has not been explored throughly yet.
[Oskar: I really think it's much simpler to have a chain of messages and solve this problem by looking at it like data sync, as opposed to proving uptime or something like this. Then you can be minimally useful as a Desktop node, just like in Bittorrent, because you provide data behind a hash.]
[Andrea: A chain of messages, as I understand you would like to have each message dependent on a previous message in a public chat let's say, would bring far more complications in my opinion, as you are trying to ensure strong consistency among clients, effectively forcing the users to sync the whole history before publishing any message (or at least a branch up to the root), you have side-chains, network partitions, and effectively no canonical-history (it's not like a blochain where you have consensus on a single branch, here multiple branches are ok, and a client does not necessarly know that multiple branches exists, until a message from that branch is fetched). I feel this is unnecessary for a chat application, sure makes sense for transactions or for threads in a chat application, but for every message? Briar does not use this strategy as far as I understand, or I am missing your point here?]
Pay per data (in MB). This would work well in a system where the receiver is known (loopix), as the mailserver would be inclined to serve as much data as possible. In a system where the receiver is not known (whisper), the mailserver could easily forge envelopes increasing the bill, and that's difficult to prevent as receiver anonymity is preserved.
Pay per delivery. Similarly would work well in a system where the receiver is known while it's more difficult in a system that provides darkness of the receiver, in this case the mailserver would have to trust the client to notify if any of the envelopes are for the user.
Pay per request(s), this would work in both cases, a misbehaving mailserver could potentially not serve data to the user to save bandwidth.
Pay fixed amount per time period (subscription). This would work in both cases, a misbehaving mailserver could potentially not serve data to the user to save bandwidth. Rate limiting can be in place to avoid too many requests.
[Oskar: +1 - I wonder if there's a hybrid model where subscription is how it works for user, but it is more granular for machine2machine? E.g. with a hybrid free system, so if a node is underpaying it gets less useful traffic. But this can be hidden from user, perhaps.]
[Andrea: That's interesting, good suggestion, thanks]
Bleep, a now defunct instant messaging client from bittorent, has used a similar strategy (used the DHT).
The code is not open source, but it was lacking of true offline messaging and bandwith consumption for mobiles was relatively high.
If you want to use the app, you need to be part of the network.
Nodes will be paid by advertising, either directly (the runner of the node will have to look for advertiser) or indirectly (through a contract).
Paid through a contract.
| Option | continuity | entry barrier | scalability | economically viable | permission to participate | anti-spam | SNT |
|---|---|---|---|---|---|---|---|
| 1 | yes | moderate/high | yes | yes | no | yes | yes |
| 2 | yes | moderate | yes | yes | no | no | yes |
| 3 | yes | low | yes | na | no | no | no |
| 4 | medium | low | yes | yes | possibly | no | yes |
| 5 | low | low | yes | no | no | yes | yes |
Where pay to send is applicaple (loopix, while whisper is trickier), that effectively acts as spam prevention mechanism, and is effectively identical to burn to send where the receivers are the nodes relaying the message (or the whole network in case of whisper). So most of the concerns applies here as well.
Burning funds for spam prevention can be applied to any method listed above.
As described in https://discuss.status.im/t/prbs-protocol-proposal-an-incentivized-whisper-like-protocol-for-status/849 , we could just enrich whisper envelopes with a signed proof of burning. We can allow users to buy messages in bulk, in order to make it more user-friendly (i.e 1000 messages per time period etc), and nodes will discard/refuse to forward if the limit is exceeded (it is still possible that some ms not having all the messages still forward some of those, but it's enough for spam prevention).
Preserving anonymity it's a bit of an issue as you will be able to trace sender->wallet fairly easily, unless some privacy preserving methods are used.
Another option is to have the mailserver acting as a guarantor. This way the client pays the mailserver, and the mailserver attaches the proof-of-burning to the envelope. In this case mailservers are effectively acting as a kind of mixer.
The benefits are that you will only be able to trace back the transaction to a user using that node, the drawback is that the user will need to disclose the fact that they sent that envelope to the mailserver (but not to the entire network), also given that a small amount of users using that node, it's not much privacy preserving, effectively the user choice here is to trade-off darkness/privacy for better delivery guarantees.
Having burn-to-send as a mechanism also does not necessarely implies that all messages needs to be paid. We can implement a rate limiting mechanism on nodes for messages without a proof, while allow those with a proof to be not rate capped. This can be reflected in the app by only making available features that are more bandwith intensive (multi-device, group chats) if funds have been burned.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe