Add EIP: Notification Interface #7017

Oli-art · 2023-05-11T21:13:29Z

No description provided.

eth-bot · 2023-05-11T21:13:56Z

File `EIPS/eip-7017.md`

Requires 1 more reviewers from @axic, @Pandapip1, @SamWilsn, @xinbenlv

EIPS/eip-xxxx.md

Co-authored-by: Andrew B Coathup <[email protected]>

fonty1 · 2023-05-16T11:21:16Z

Nice proposal.. we are definitely like minded on this topic :) Streamr would be happy to help or bring exposure to this initiative if you think it can help. We are a properly decentralized pub/sub network looking to bring to life more open comms/data use cases in Web3.

Worth a look; EthWatch

Oli-art · 2023-05-16T15:47:22Z

Nice proposal.. we are definitely like minded on this topic :) Streamr would be happy to help or bring exposure to this initiative if you think it can help. We are a properly decentralized pub/sub network looking to bring to life more open comms/data use cases in Web3.

Worth a look; EthWatch

Deinetely interested in some exposure. I'm developing a chrome extension that would listen for contracts implementing EIP-7017 and notify users about the notifications of their interest. I unfortunately hit a big roadblock on that one. I'm also working on a discord BOT now. For this usecases a decentralized pub/sub network is definetely useful. I'm currently using Quicknode to get the alerts to the discord BOT service.

Obiously this is all just a proof of concept and a way to test this initiative on a real-world scenario, but I would be glad to meet if you want, as I would be happy to see more projects jump on board.

fonty1 · 2023-05-16T15:58:18Z

I'm currently using Quicknode to get the alerts to the discord BOT service.

If its just subscribing to events then your could use the EthWatch stream - it's totally free to use and works in the browser/extension environment.

Obiously this is all just a proof of concept and a way to test this initiative on a real-world scenario, but I would be glad to meet if you want, as I would be happy to see more projects jump on board.

Sure, feel welcome to book some time - Calendly / or reach out to me at [email protected]

GabrielMartinezRodriguez · 2023-05-22T14:46:35Z

A good idea could be to implement a singleton pattern, i.e. the INotification is implemented on a fixed address and all off-chain services have to query only this address.

Specify how the body of a message could be structured and add an encription option to DMs

Oli-art · 2023-06-17T03:38:13Z

A good idea could be to implement a singleton pattern, i.e. the INotification is implemented on a fixed address and all off-chain services have to query only this address.

Yes! For wallets sending the notifications, there is really only one contract implementation of the events necesary.

In the case of contracts sending the notifications, it would't work that well, as you need to know who has sent the notification in a straight forward way, and if the contract is calling another contract, then it's more complicated to see who the real sender is. Also, if the the contract has to send many notifications, I think it's cheaper to just emit an event than to call another contract that does it for you.

Pandapip1

I would recommend the following changes:

Have a sister EIP to standardize encryption methods (so that DMMs to smart contracts can be encrypted).
Require encryption. This seems like a no-brainer to me.
Taking a book out of MMS, have the actual message parameter be a URI so the message data can be stored off-chain. If on-chain storage is desired, a data: URL can be used. The message parameter type would be changed to string, and the schema would be turned into an actual JSON schema.

Additionally, the following issues MUST be addressed:

The message schema must be added to the Specification. It is only mentioned in the Rationale.

Also, improve grammar.

github-actions · 2023-06-17T23:38:32Z

The commit 8eea6ba (as a parent of 0e1a785) contains errors.
Please inspect the Run Summary for details.

Also, highlight RFC 2119 key words

Oli-art · 2023-06-18T04:41:55Z

I would recommend the following changes:

Have a sister EIP to standardize encryption methods (so that DMMs to smart contracts can be encrypted).

Require encryption. This seems like a no-brainer to me.

Taking a book out of MMS, have the actual message parameter be a URI so the message data can be stored off-chain. If on-chain storage is desired, a data: URL can be used. The message parameter type would be changed to string, and the schema would be turned into an actual JSON schema.

Additionally, the following issues MUST be addressed:

The message schema must be added to the Specification. It is only mentioned in the Rationale.

The only point that would be a bit outside my reach is the encryption method. I found that EIP-5630 addresses this problem and seems like a good match, but I wouldn't know if it is the best or even if it's an acceptable method. Also, it hasn't been approved as an EIP.

I will be in contact with it's author to see if we can have a talk. Also, any further feedback would be appreciated.

firnprotocol · 2023-06-19T15:42:46Z

EIPS/eip-7017.md

+"subject": "The subject of the message",
+"body": "The body of the message",
+"image_uri": "An image URI",
+"transaction_request": "A transaction request"


it looks like you are missing indentations here. would recommend trying to match lines 151–154, and also clarifying how indentation/spacing should be handled in the JSONs.

firnprotocol · 2023-06-19T15:52:48Z

EIPS/eip-7017.md

+emit BroadcastMsg (0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045, message);
+```
+
+This is why the message sender in the log's topic must allways be verified against the transaction "from" or transaction "to", depending on the notification type (wallet or contract respectively).


after further discussion: this "advice" is now obsolete. it is up to the client-side application to listen only to contracts which make "sensible" choices as far as the meanings of from and to. in particular, there are various patterns which it might make sense for a contract to use, depending on the circumstance. it doesn't make sense to be prescriptive here.

firnprotocol · 2023-06-19T18:26:24Z

after a conversation with Oliver, i have the following suggestions:

remove the functions walletDM, contractDM, walletBroadcast, contractBroadcast, and only keep the events DirectMsg and BroadcastMsg. it should be up to the contract to decide when, where, why and how these events get emitted; in general, the trigger need not be an explicit call by an EOA. (e.g., a message could be triggered by an auction ending or a sale finalizing, as a side effect of some other method.)
remove the requirement that from == msg.sender || from == address(this). in general, we want to allow arbitrary, more complex logic on the part of the contract, as far as controlling what from means / signifies. (for example, it could happen that a contract wants to send a message triggered by a "finalization" function, where the EOA triggering the finalization is unrelated to the sender of the message.)
consolidate DirectMsg and BroadcastMsg into one Message event, where to == 0x0000000000000000000000000000000000000000 is interpreted as as broadcast.

firnprotocol · 2023-06-19T18:39:10Z

Have a sister EIP to standardize encryption methods (so that DMMs to smart contracts can be encrypted).

Require encryption. This seems like a no-brainer to me.

@Pandapip1 EIP-5630 seems to be the appropriate standard; I will collaborating with @Oli-art to get encryption incorporated into this EIP.

Add EIP-5630 as the encryption requirement for all direct messages. Update the interface to not need the four functions and merged the two events into one common one for DMs and Broadcasts.

Oli-art · 2023-06-19T21:38:52Z

I took @firnprotocol 's suggestions into the last commit.

Senders are not required to be either the contract or the address executing it, although I'm not entierly convinced on this topic and think we would do good by hearing the opinions of people working in the wallets and dApps.

I'll ask for some meetings here and there to get more perspectives 👍

SamWilsn · 2023-09-20T18:54:46Z

EIPS/eip-7017.md

+---
+eip: 7017
+title: Notification Interface
+description: A notifications interface for a more engaging blockchain


Your description doesn't really add any additional information over the title. You should try to expand on the ideas introduced on the title.

Perhaps something like:

Suggested change

description: A notifications interface for a more engaging blockchain

description: An event signature and JSON schema for broadcast and unicast notifications.

SamWilsn · 2023-09-20T19:55:43Z

EIPS/eip-7017.md

+Some usecases include but are not limited to:
+
+- DAO governance voting anouncement
+- DEX informing an address about a certain price limit being reached, for example a stop-loss or a margin-call.
+- An NFT marketplace informing an NFT owner about an offer being made to one of it’s NFTs.
+- A metaverse informing about an important event.
+- Warning to an address about an ENS domain expiration date approaching.


These use cases should be moved to the Motivation section.

SamWilsn · 2023-09-20T19:56:15Z

EIPS/eip-7017.md

+The following standard allows addresses / smart contracts to send notifications one-to-one and one-to-many.
+
+It achieves it in a trustless and decentralized way and without requiring any on-chain interaction by the receivers.
+
+It requires a front-end implementation where the notifications are listened to, filtered and showed to the end user (address owner).


I think these should be combined into a single paragraph.

Suggested change

The following standard allows addresses / smart contracts to send notifications one-to-one and one-to-many.

It achieves it in a trustless and decentralized way and without requiring any on-chain interaction by the receivers.

It requires a front-end implementation where the notifications are listened to, filtered and showed to the end user (address owner).

The following standard allows addresses / smart contracts to send notifications one-to-one and one-to-many. It achieves it in a trustless and decentralized way and without requiring any on-chain interaction by the receivers. It requires a front-end implementation where the notifications are listened to, filtered and showed to the end user (address owner).

SamWilsn · 2023-09-20T19:56:55Z

EIPS/eip-7017.md

+It achieves it in a trustless and decentralized way and without requiring any on-chain interaction by the receivers.
+
+It requires a front-end implementation where the notifications are listened to, filtered and showed to the end user (address owner).
+


I'd like to see a bit more about how this proposal works, technically, in the abstract.

SamWilsn · 2023-09-20T20:36:35Z

EIPS/eip-7017.md

+
+## Motivation
+
+With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.


How about this wording instead:

Suggested change

With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.

As the adoption of web3 applications grows, so too does the need to be informed about certain events happening on-chain.

SamWilsn · 2023-09-20T20:37:19Z

EIPS/eip-7017.md

+
+With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.
+
+Users are used to being informed, whether it be about news or updates of their favorite applications. As we are in a time of instant data feeds on social media, instant messaging apps and notifications of events that users care about, notifications are a feature in practically every application that exists in web2. They mostly come to email inboxes, SMSs, inside the applications, or in the notification inbox in the operating system.


Suggested change

Users are used to being informed, whether it be about news or updates of their favorite applications. As we are in a time of instant data feeds on social media, instant messaging apps and notifications of events that users care about, notifications are a feature in practically every application that exists in web2. They mostly come to email inboxes, SMSs, inside the applications, or in the notification inbox in the operating system.

Users are accustomed to being informed, whether it be about news or updates of their favorite applications. As we are in a time of instant data feeds on social media, instant messaging apps and notifications of events that users care about, notifications are a feature in practically every application that exists in web2. They mostly come to email inboxes, SMSs, inside the applications, or in the notification inbox in the operating system.

SamWilsn · 2023-09-20T20:37:51Z

EIPS/eip-7017.md

+In web2, most of the user account’s are linked to an email address that is required at sign-up. This makes it easy to send notifications to specific users and requires no further complexity as an infrastructure exists to deliver a message to the user using their email address.
+
+In web3, on the other hand, there's mostly is only one inbox to send notifications to: addresses.
+Every smart contract can define its own event’s to which one can listen to, but for each of them, a change has to be done in the frontend to listen to that specific contract and event structure. This poses a problem of coordination between smart contracts and web3 applications that can notify users.


Suggested change

Every smart contract can define its own event’s to which one can listen to, but for each of them, a change has to be done in the frontend to listen to that specific contract and event structure. This poses a problem of coordination between smart contracts and web3 applications that can notify users.

Every smart contract can define its own events to which one can listen to, but for each of them, a change has to be done in the frontend to listen to that specific contract and event structure. This poses a problem of coordination between smart contracts and web3 applications that can notify users.

SamWilsn · 2023-09-20T20:40:17Z

EIPS/eip-7017.md

+
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+
+An approach that is both simple, decentralized and easy to implement is to use a notifications smart contract standard that is **event-based** to be able to emit notifications to one address or broadcast them to anyone that wants to listen. Off-chain **whitelists** would record all addresses a user wants to allow receiving messages from to avoid spam. This is useful for direct messages from one address to another. Off-chain **subscription lists** would indicate which addresses they want to listen for general broadcasts. This is useful for receiving updates on a project.


This paragraph introduces no requirements or recommendations for implementation. It should be split and moved to motivation and rationale as appropriate.

SamWilsn · 2023-09-20T20:41:29Z

EIPS/eip-7017.md

+
+An approach that is both simple, decentralized and easy to implement is to use a notifications smart contract standard that is **event-based** to be able to emit notifications to one address or broadcast them to anyone that wants to listen. Off-chain **whitelists** would record all addresses a user wants to allow receiving messages from to avoid spam. This is useful for direct messages from one address to another. Off-chain **subscription lists** would indicate which addresses they want to listen for general broadcasts. This is useful for receiving updates on a project.
+
+As a user SHALL NOT record its whitelist and subscription list on-chain, the receiver will not do any transaction.


I think this is a bit more readable:

Suggested change

As a user SHALL NOT record its whitelist and subscription list on-chain, the receiver will not do any transaction.

Notification recipients SHALL NOT be required to record a whitelist and subscription list on-chain.

SamWilsn · 2023-09-20T20:59:05Z

EIPS/eip-7017.md

+Here is an example of a malitious implementation of a BroadcastMsg event impersonating Vitalik Buterin:
+
+```solidity
+emit BroadcastMsg (0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045, message);


This event doesn't match one from the interface. Is that intentional?

SamWilsn · 2023-10-25T22:12:37Z

I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually.

As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process.

If there is relevant history here, please link to this PR from the new pull request.

On behalf of the EIP Editors, I apologize for this inconvenience.

wakqasahmed · 2024-11-25T08:16:20Z

@SamWilsn @Oli-art has this EIP moved to the next stage? how close it is to be incorporated as a standard?

Propose Notification Standard

512a1f6

Oli-art requested a review from eth-bot as a code owner May 11, 2023 21:13

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-erc labels May 11, 2023

Merge branch 'master' into notification-interface

3e19366

eth-bot changed the title ~~Propose Notification Standard~~ Add EIP: Notification Interface May 11, 2023

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels May 11, 2023

github-actions bot added the w-ci Waiting on CI to pass label May 11, 2023

abcoathup reviewed May 12, 2023

View reviewed changes

EIPS/eip-xxxx.md Outdated Show resolved Hide resolved

Oli-art and others added 2 commits May 12, 2023 00:46

Update EIPS/eip-xxxx.md

e4a5a6e

Co-authored-by: Andrew B Coathup <[email protected]>

Assign EIP number 7017

bfc55e7

github-actions bot removed the w-ci Waiting on CI to pass label May 12, 2023

Update description and discussions-to

e10327f

Update eip-7017.md

3d0f3c2

Specify how the body of a message could be structured and add an encription option to DMs

github-actions bot added the w-ci Waiting on CI to pass label May 31, 2023

Fix es-lint issue

49815cb

github-actions bot removed the w-ci Waiting on CI to pass label May 31, 2023

Add security example

450d270

Pandapip1 suggested changes Jun 17, 2023

View reviewed changes

Refactor message data

1830f55

Also, improve grammar.

github-actions bot added the w-ci Waiting on CI to pass label Jun 17, 2023

Fix lint problems

8eea6ba

Oli-art requested a review from Pandapip1 June 17, 2023 23:34

Fix Validation Error

9d2a076

Also, highlight RFC 2119 key words

github-actions bot removed the w-ci Waiting on CI to pass label Jun 17, 2023

Oli-art mentioned this pull request Jun 18, 2023

Add support for encryption MetaMask/metamask-extension#1190

Closed

firnprotocol reviewed Jun 19, 2023

View reviewed changes

Oli-art added 2 commits June 19, 2023 17:25

Add EIP-5630, Update Interface

cd3cb2b

Add EIP-5630 as the encryption requirement for all direct messages. Update the interface to not need the four functions and merged the two events into one common one for DMs and Broadcasts.

Fix Walidator Errors

94e6646

SamWilsn reviewed Sep 20, 2023

View reviewed changes

SamWilsn closed this Oct 25, 2023

wakqasahmed mentioned this pull request Feb 21, 2024

Added more use cases Oli-art/EIPs#1

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP: Notification Interface #7017

Add EIP: Notification Interface #7017

Oli-art commented May 11, 2023

eth-bot commented May 11, 2023 •

edited

Loading

fonty1 commented May 16, 2023

Oli-art commented May 16, 2023

fonty1 commented May 16, 2023

GabrielMartinezRodriguez commented May 22, 2023

Oli-art commented Jun 17, 2023

Pandapip1 left a comment

github-actions bot commented Jun 17, 2023

Oli-art commented Jun 18, 2023 •

edited

Loading

firnprotocol Jun 19, 2023

firnprotocol Jun 19, 2023 •

edited

Loading

firnprotocol commented Jun 19, 2023 •

edited

Loading

firnprotocol commented Jun 19, 2023

Oli-art commented Jun 19, 2023 •

edited

Loading

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn Sep 20, 2023

SamWilsn commented Oct 25, 2023

wakqasahmed commented Nov 25, 2024

	description: A notifications interface for a more engaging blockchain
	description: An event signature and JSON schema for broadcast and unicast notifications.

		It achieves it in a trustless and decentralized way and without requiring any on-chain interaction by the receivers.

		It requires a front-end implementation where the notifications are listened to, filtered and showed to the end user (address owner).


		## Motivation

		With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.

	With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.
	As the adoption of web3 applications grows, so too does the need to be informed about certain events happening on-chain.


		With the adoption of web3 applications, an increasing necessity arises to be informed about certain events happening on-chain.

		Users are used to being informed, whether it be about news or updates of their favorite applications. As we are in a time of instant data feeds on social media, instant messaging apps and notifications of events that users care about, notifications are a feature in practically every application that exists in web2. They mostly come to email inboxes, SMSs, inside the applications, or in the notification inbox in the operating system.

	Every smart contract can define its own event’s to which one can listen to, but for each of them, a change has to be done in the frontend to listen to that specific contract and event structure. This poses a problem of coordination between smart contracts and web3 applications that can notify users.
	Every smart contract can define its own events to which one can listen to, but for each of them, a change has to be done in the frontend to listen to that specific contract and event structure. This poses a problem of coordination between smart contracts and web3 applications that can notify users.


		The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

		An approach that is both simple, decentralized and easy to implement is to use a notifications smart contract standard that is event-based to be able to emit notifications to one address or broadcast them to anyone that wants to listen. Off-chain whitelists would record all addresses a user wants to allow receiving messages from to avoid spam. This is useful for direct messages from one address to another. Off-chain subscription lists would indicate which addresses they want to listen for general broadcasts. This is useful for receiving updates on a project.


		An approach that is both simple, decentralized and easy to implement is to use a notifications smart contract standard that is event-based to be able to emit notifications to one address or broadcast them to anyone that wants to listen. Off-chain whitelists would record all addresses a user wants to allow receiving messages from to avoid spam. This is useful for direct messages from one address to another. Off-chain subscription lists would indicate which addresses they want to listen for general broadcasts. This is useful for receiving updates on a project.

		As a user SHALL NOT record its whitelist and subscription list on-chain, the receiver will not do any transaction.

	As a user SHALL NOT record its whitelist and subscription list on-chain, the receiver will not do any transaction.
	Notification recipients SHALL NOT be required to record a whitelist and subscription list on-chain.

Add EIP: Notification Interface #7017

Add EIP: Notification Interface #7017

Conversation

Oli-art commented May 11, 2023

eth-bot commented May 11, 2023 • edited Loading

File EIPS/eip-7017.md

fonty1 commented May 16, 2023

Oli-art commented May 16, 2023

fonty1 commented May 16, 2023

GabrielMartinezRodriguez commented May 22, 2023

Oli-art commented Jun 17, 2023

Pandapip1 left a comment

Choose a reason for hiding this comment

github-actions bot commented Jun 17, 2023

Oli-art commented Jun 18, 2023 • edited Loading

Choose a reason for hiding this comment

firnprotocol Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

firnprotocol commented Jun 19, 2023 • edited Loading

firnprotocol commented Jun 19, 2023

Oli-art commented Jun 19, 2023 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamWilsn commented Oct 25, 2023

wakqasahmed commented Nov 25, 2024

eth-bot commented May 11, 2023 •

edited

Loading

File `EIPS/eip-7017.md`

Oli-art commented Jun 18, 2023 •

edited

Loading

firnprotocol Jun 19, 2023 •

edited

Loading

firnprotocol commented Jun 19, 2023 •

edited

Loading

Oli-art commented Jun 19, 2023 •

edited

Loading