I just recently developed a notification widget for a chess game, but if every dapp would want to add notifications, they would have to ask the respective gateway developers to update their widget. It would be good to provide a custom notification type.
I thought a lot about this and I think if we add a custom type to the current notification standard, then we would make it extremely easy to broadcast scams to many wallets. For a notification to be useful it should at least include an action item with a link or with a tx sign prompt. The way notifications work right now is that you can send any wallet any notification.
Possible solutions I could think of are:
make it an on-chain whitelist
We could have a whitelist of notification items stored on the social.near contract, that can be updated via DAO proposals for dapps to add them to the list. Only specific versions of widgets should be added to the whitelist.
create a new passive notified standard
Users would be able to be notified only if they actively allowed the dapp to do so by calling grant_write_permission on the social.near contract for <contractId>/index/notified. The dapp can then set this index on the user's key.
Hey, we already have many different notification types on the BOS. See a list here: https://near.social/mob.near/widget/WidgetSource?src=mob.near/widget/Notification.Item However it would be good to include a custom component type for dapps.
I just recently developed a notification widget for a chess game, but if every dapp would want to add notifications, they would have to ask the respective gateway developers to update their widget. It would be good to provide a custom notification type.
I thought a lot about this and I think if we add a
customtype to the current notification standard, then we would make it extremely easy to broadcast scams to many wallets. For a notification to be useful it should at least include an action item with a link or with a tx sign prompt. The way notifications work right now is that you can send any wallet any notification. Possible solutions I could think of are:We could have a whitelist of notification items stored on the
social.nearcontract, that can be updated via DAO proposals for dapps to add them to the list. Only specific versions of widgets should be added to the whitelist.notifiedstandardUsers would be able to be notified only if they actively allowed the dapp to do so by calling
grant_write_permissionon thesocial.nearcontract for<contractId>/index/notified. The dapp can then set this index on the user's key.