20: Ethereum Direct Message with Waku v2 #365

D4nte · 2021-05-03T23:55:38Z

Introduces 20: ETH-DM, the Ethereum Direct Message protocol which enables a peer to send a direct message to another peer using the Waku v2 network, and the peer's Ethereum Address.

Related to #72.

oskarth · 2021-05-04T04:26:22Z

content/docs/rfcs/19/README.md

+contributors:
+---
+
+This specification explains the Waku v2 Direct Message protocol which enables a peer to send a direct message to another peer using the Waku v2 network.


I'd probably making this into something more Ethereum specific

Happy to do so and not fall in the "generalised too early" trap. Interestingly enough, only the derivation is Ethereum (actually ecdsa) specific.

Well, as anywhere else "Ethereum" is mentioned and not the actual key scheme used, the same could be should be done here. Or the other way around and remove Ethereum everywhere.

true, ECDSA messaging? :D

oskarth · 2021-05-04T04:26:41Z

content/docs/rfcs/19/README.md

@@ -0,0 +1,101 @@
+---
+slug: 19


19 is taken, https://github.com/vacp2p/rfc/tree/master/content/docs/rfcs/19

oskarth · 2021-05-04T04:28:49Z

content/docs/rfcs/19/README.md

@@ -0,0 +1,101 @@
+---
+slug: 19
+title: 19/WAKU2-DIRECT-MESSAGE


Hm, I wonder how we want to distinguish between more application layer and Waku v2 protocols here. For EIPs, there is a different track for ERC, but might be too complex. In any case, I'd put something Ethereum specific here probably? Also feel free to acronym this stuff because it might get too long otherwise (20/WAKU2-APP-ETH-DIRECT-MESSAGE -> WAETHDM? :D probably better ones...)

cc @jm-clius @staheri14 re app/waku v2 level distinction

I agree that we need to make explicit the semantic difference between the Waku v2 suite of protocols and any application built on top of it.
To my mind this is ETH-DIRECT-MESSAGE (EDM 😎) protocol over Waku v2. Perhaps the spec title can then even omit WAKU2 and just state its relation to WAKU2 as part of the spec body? If we want to be more explicit, all such WAKU2-APP protocols can be prefixed and referred to as something like W2A protocols. Theoretically, chat2 is already a W2A protocol as it operates on a higher layer than WAKU2.

Oh, I like EDM (well, not the music, too commercial)

I went for "ETH-DM" for now. Reasoning:

Removed WAKU2 as suggested, keeping this for waku protocol level specs only

"DM" is a common acronym for "Direct Message",

"ETH" is a common acronym for "Ethereum".

While in most cases, one who reads "EDM" would need to be explained that it stands for "Ethereum Direct Message". However, I believe that one that reads "ETH-DM" can more easily understand its meaning without being told that it stands for "EThereum Direct Message".
I may be wrong of course :)

ETH is typically used to refer to the actual coin, Ether. Eth to refer to Ethereum (see for example usage of Eth1 and Eth2). So in that sence, perhaps EDM was a better choice :)

oskarth · 2021-05-04T04:29:46Z

PR description can probably be more accurate too to make it a spec/protocol level concern

staheri14

Nice, clear and organized description!
I have left some comments re privacy.

staheri14 · 2021-05-04T22:48:33Z

content/docs/rfcs/19/README.md

+   `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,
+   with `Bw` in hex format (`0xAb1..`),
+6. Alice publishes `Mw` via [11/WAKU2-RELAY](/spec/11),
+7. Bob captures messages received messages via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,


Suggested change

7. Bob captures messages received messages via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,

7. Bob captures messages received via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,

staheri14 · 2021-05-04T22:53:18Z

content/docs/rfcs/19/README.md

+4. Alice encrypts `M'` using `Bw`, resulting in `m'`, TODO: define encryption method,
+5. Alice creates waku message `Mw` with
+   `payload` `m'` and
+   `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,


Not sure if it would be a concern now or not, but note that the inclusion of Bw will break anonymity and unlinkability of the recipient of the message i.e., Bob in here.

Yes it is a concern. I initially marked this concern as "out of scope" but the wording I used seemed confusing. I'll re introduce the scoping with improved wording.

staheri14 · 2021-05-04T22:59:37Z

content/docs/rfcs/19/README.md

+
+## Steps
+
+1. Alice MUST derive Bob's waku public Key `Bw` from `B`,


Wondering why such a derivation is needed? i.e., from B to Bw?

My understanding is that it is hard to compute B from Bw. Which means that just by observing the waku traffic, one cannot deduce which Ethereum addresses are receiving message.

However, we know that as highlighted in #365 (comment) if one knows B, it is easy to know whether Bob is receiving messages.

I also expect that as we evolve the protocol, we use new ways to derive keys from B to allow unlinkability.

What do you think?

If the derivation is based on a deterministic function F i.e., F always output the same Bw when receiving B, then anonymity is still at risk. This is regardless of the derivation function F being unlinkable/one-way (one-way: computing B from Bw is hard).
The anonymity is compromised since all the network messages are linkable to their receiver by only looking at the embedded pk i.e., Bw.
@D4nte

staheri14 · 2021-05-04T23:00:46Z

content/docs/rfcs/19/README.md

+
+### Reply
+
+To ascertain the fact that Alice receives Bob's reply, she could include connection details such as her peer id and multiaddress in the message.


Ditto, inclusion of peerId is against anonymity and reveals both ends of communication

staheri14 · 2021-05-04T23:02:59Z

content/docs/rfcs/19/README.md

+### Reply
+
+To ascertain the fact that Alice receives Bob's reply, she could include connection details such as her peer id and multiaddress in the message.
+However, this leads to privacy concerns if she does not use an anonymizing network such as tor.


If she attempts to include her PeerId in the message, using Tor will not help in preserving anonymity (unless there is another level of encryption/randomization)

Can you please clarify what information would be revealed that doesn't preserve anonimity?

PeerId is unique for each user, when PeerID of Alice e.g., PA is included in her replies, combined with Bw, which is also part of the reply, one can learn how many messages are transmitted between these two parties i.e., between PA and Bw. This leaks the network communication graph which would ultimately break anonymity and allows deidentification of the users i.e., Alice and Bob. Can't exactly say how fast such inference can be, but certainly opens up the hole for that.

I assumed that PA would be encrypted with Bw as part of the payload so that only Bob would learn PA.

kdeme

Just curious as I've not been following this development, but what is the context related to this direct messaging specifically based on Ethereum Keys?

The name "Direct" is rather confusing here to me, as it is not actual direct messaging and still goes over the relay/store. When I first read the title I thought it was about adding a direct request/response mechanism for messaging in Waku v2. Instead it is a layer on top of relay/store on how to use a specific Key scheme to communicate.

Also, privacy concerns as already mentioned by @staheri14 . Additional to that, I don't know the context here, but there is a reason why the status app uses different addresses for wallet and Waku communication.

kdeme · 2021-05-05T09:58:37Z

content/docs/rfcs/19/README.md

+contributors:
+---
+
+This specification explains the Waku v2 Direct Message protocol which enables a peer to send a direct message to another peer using the Waku v2 network.


Well, as anywhere else "Ethereum" is mentioned and not the actual key scheme used, the same could be should be done here. Or the other way around and remove Ethereum everywhere.

oskarth · 2021-05-06T03:35:21Z

The origin of this idea was thinking about how to do an application layer protocol for messaging to Ethereum public keys that don't use Waku yet, as part of the general Ethereum Dapp roadmap. You are right that it might not be Ethereum specific, at least not in its current form.

This is using Ethereum dapps as consumers, as opposed to just thinking about Status wallet. From a user POV, Metamask is a vastly bigger target. Of course, the key structure should be reusable and compatible, etc.

@D4nte Since this is a raw spec, I suggest making the minimal necessary changes (name, id etc) and then address the things you can think of now, then add the other comments/concern as either TODO in-line or as follow up issues. Then we can merge this as in progress, and revisit it once it becomes more priority/we push it to draft.

D4nte · 2021-05-06T04:54:56Z

I usually avoid push forcing on documentation PRs, however as my master was not up to date (spec 19 already exists) I believe a push force is best in this case.

D4nte · 2021-05-06T05:07:47Z

@D4nte Since this is a raw spec, I suggest making the minimal necessary changes (name, id etc) and then address the things you can think of now, then add the other comments/concern as either TODO in-line or as follow up issues. Then we can merge this as in progress, and revisit it once it becomes more priority/we push it to draft.

Sounds good. Now ready for re-review.

D4nte · 2021-05-06T05:12:54Z

@oskarth already replied but I thought I'd provide some details.

Just curious as I've not been following this development, but what is the context related to this direct messaging specifically based on Ethereum Keys?

The idea of this protocol is to allow one party to reach another party, only knowing their Ethereum address. E.g., Alice could want to reach Bob to privately buy a NFT they hold.

The name "Direct" is rather confusing here to me, as it is not actual direct messaging and still goes over the relay/store. When I first read the title I thought it was about adding a direct request/response mechanism for messaging in Waku v2. Instead it is a layer on top of relay/store on how to use a specific Key scheme to communicate.

I think your comment is similar to #365 (comment). I addressed it by changing the protocol name. Let me know what you think.

Also, privacy concerns as already mentioned by @staheri14 . Additional to that, I don't know the context here, but there is a reason why the status app uses different addresses for wallet and Waku communication.

Yes, in this instance Alice wants to specifically reach Bob only knowing his Ethereum Address. This is not a case of Alice and Bob know each other and want to use waku to talk to each other (in this instance, we should propose a protocol where they generate brand new keys unrelated to their Ethereum keys).

oskarth · 2021-05-06T07:15:21Z

I usually avoid push forcing on documentation PRs, however as my master was not up to date (spec 19 already exists) I believe a push force is best in this case.

We will squash it anyway so not an issue I think

oskarth

Good enough for raw, can iterate later, thanks!

oskarth · 2021-05-06T07:15:53Z

content/docs/rfcs/20/README.md

@@ -0,0 +1,113 @@
+---
+slug: 20


Add to menu as well so it shows up in preview https://github.com/vacp2p/rfc/blob/master/content/menu/index.md

kdeme · 2021-05-06T12:11:57Z

The idea of this protocol is to allow one party to reach another party, only knowing their Ethereum address. E.g., Alice could want to reach Bob to privately buy a NFT they hold.

OK, thanks for the context, makes sense. I was thinking in that direction, but rather of a use case where one wants to for example proof the holding of an NFT or some other asset by sending a message under the key that holds it. Similar use cases.

Yes, in this instance Alice wants to specifically reach Bob only knowing his Ethereum Address. This is not a case of Alice and Bob know each other and want to use waku to talk to each other (in this instance, we should propose a protocol where they generate brand new keys unrelated to their Ethereum keys).

Thanks, that's clear. It is messaging related specifically to potential information linked with the Eth account. It doesn't mean however that we shouldn't be wary of any metadata leaking outside of the Alice - Bob link.

kdeme · 2021-05-06T12:13:26Z

content/docs/rfcs/20/README.md

+4. Alice encrypts `M'` using `Bw`, resulting in `m'`,
+5. Alice creates waku message `Mw` with
+   `payload` `m'` and
+   `contentTopic` `/waku/2/eth-dm/child-pubkey/Bw/proto`,


Not sure I fully understand here having child-pubkey and Bw in this topic. Aren't they the same?
(same remark for all contentTopics below.

child-pubkey is literally the string child-pubkey. The aim is to qualify the data used here, ie, what is Bw.

We know that by having Bw there, we are breaking unlinkability so maybe in the future we may use a different data type instead of Bw, let's say foo that permits unlinkability. In this case, the contentTopic would then become /waku/2/eth-dm/qualifier-for-foo/foo.

Please let me know if you have an idea on how I could make this clearer.

D4nte mentioned this pull request May 3, 2021

Document usecase to integrate js-waku with ethers.js waku-org/js-waku#111

Closed

D4nte requested review from oskarth and staheri14 May 3, 2021 23:56

oskarth reviewed May 4, 2021

View reviewed changes

oskarth requested review from jm-clius and EbubeUd May 4, 2021 04:29

staheri14 reviewed May 4, 2021

View reviewed changes

oskarth changed the title ~~Document usecase to integrate js-waku with ethers.js~~ 20: Ethereum Direct Messaging with Waku v2 May 5, 2021

kdeme reviewed May 5, 2021

View reviewed changes

D4nte changed the title ~~20: Ethereum Direct Messaging with Waku v2~~ 20: Ethereum Direct Message with Waku v2 May 6, 2021

Introduce 20: Ethereum Direct Messaging

5f50cf0

D4nte force-pushed the 72-direct-message branch from 713d937 to 5f50cf0 Compare May 6, 2021 04:54

D4nte added 5 commits May 6, 2021 14:56

GitHub Markdown only accept digits for numbered lists

3d2796c

Fix section titles and first section

605cb17

Add section for encryption, move todo

f95b1d6

Fix reference numbers

aa9557c

Update content topics with new proposed name

33e7fbd

oskarth approved these changes May 6, 2021

View reviewed changes

kdeme reviewed May 6, 2021

View reviewed changes

Add 20/ETH-DM to menu

eb0acf0

D4nte merged commit d278fb4 into master May 7, 2021

D4nte deleted the 72-direct-message branch May 7, 2021 00:43

kdeme mentioned this pull request Jun 29, 2021

Do not derive Eth-DM Key from Ethereum Key #411

Closed

	7. Bob captures messages received messages via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,
	7. Bob captures messages received via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/direct-message/eth-pubkey/Bw/proto`,


		## Steps

		1. Alice MUST derive Bob's waku public Key `Bw` from `B`,


		### Reply

		To ascertain the fact that Alice receives Bob's reply, she could include connection details such as her peer id and multiaddress in the message.

		@@ -0,0 +1,101 @@
		---
		slug: 19

		@@ -0,0 +1,113 @@
		---
		slug: 20

20: Ethereum Direct Message with Waku v2 #365

20: Ethereum Direct Message with Waku v2 #365

Conversation

D4nte commented May 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

D4nte May 6, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth commented May 4, 2021

staheri14 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 May 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 May 5, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdeme left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth commented May 6, 2021

D4nte commented May 6, 2021

D4nte commented May 6, 2021

D4nte commented May 6, 2021

oskarth commented May 6, 2021

oskarth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdeme commented May 6, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

D4nte commented May 3, 2021 •

edited

Loading

D4nte May 6, 2021 •

edited

Loading

staheri14 May 13, 2021 •

edited

Loading

staheri14 May 5, 2021 •

edited

Loading

kdeme left a comment •

edited

Loading