DEV Community: Push Protocol

Getting Started With PUSH SDK uiweb API

Push Protocol — Wed, 22 Feb 2023 06:28:11 +0000

The @pushprotocol/uiweb package is a collection of React components for building dapps that interact with the Push Protocol, web3's communication protocol. It includes components for rendering notifications, spam notifications, and forms for subscribing and unsubscribing to spam notification channels.

In this blog post, we'll take a closer look at the components included in the @pushprotocol/uiweb package and how you can use them in your dapp.

Components

NotificationItem

This component displays a single notification item. It takes the following props:

notificationTitle (string): The title of the notification.
notificationBody (string): The body of the notification.
app (string): The name of the app that sent the notification.
icon (string): The URL of an icon to display next to the notification title.
image (string): The URL of an image to display in the notification.
url (string): The URL to open when the notification is clicked.
theme (string): The theme to use for the notification. Possible values are 'light' and 'dark'.
chainName (string): The name of the blockchain the notification was sent on. Possible values are "ETH_TEST_GOERLI", "POLYGON_TEST_MUMBAI”.
isSpam (boolean, optional): Set to true if the notification is spam.
subscribeFn (function, optional): A function to call when the user clicks the "Opt-in" button on a spam notification.
isSubscribedFN (function, optional): A function that returns a boolean indicating whether the user is subscribed to the spam notification's channel.

Example:

import { NotificationItem } from "@pushprotocol/uiweb";

function MydApp() {
  const notifications = [
    {
      title: "Notification 1",
      message: "This is the first notification",
      app: "My App",
      icon: "https://my-app.com/icon.png",
      image: "https://my-app.com/image.png",
      url: "https://my-app.com/notification-1",
      blockchain: "ETH_TEST_GOERLI"
    },
    {
      title: "Notification 2",
      message: "This is the second notification",
      app: "My App",
      icon: "https://my-app.com/icon.png",
      image: "https://my-app.com/image.png",
      url: "https://my-app.com/notification-2",
      blockchain: "ETH_TEST_GOERLI"
    }
  ];

  return (
    <div>
      {notifications.map((notification, i) => (
        <NotificationItem
          key={i}
          notificationTitle={notification.title}
          notificationBody={notification.message}
          app={notification.app}
          icon={notification.icon}
          image={notification.image}
          url={notification.url}
          theme={{ background: "blue", color: "white" }}
          chainName={notification.blockchain}
        />
      ))}
    </div>
  );
}

The Notification Item component can also be used to render spam notifications. To get the spam data, you can use the PushAPI.user.getFeeds() method with the spam parameter set to true.

The NotificationItem component is a general-purpose component that can be used to render any type of notification item, including spam notifications. It accepts props such as notificationTitle, notificationBody, cta, app, icon, image, and url to customize the appearance and behavior of the component.

The Spam component is a specialized variant of the NotificationItem component that is specifically designed for rendering spam notifications. It includes additional props such as isSpam, subscribeFn, and isSubscribedFn that allow the user to interact with the spam notification channel. It also includes an unsubscribe form that is displayed if the user is subscribed to the spam notification channel.

You can use the PushAPI.user.getFeeds() method with the spam parameter set to true to get the spam data. Here's an example of how you can use it:

const spams = await PushAPI.user.getFeeds({
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  spam: true,
  env: 'staging'
});

To render the Notification Item component for each spam notification, you'll need to pass in the additional props isSpam, subscribeFn, and isSubscribedFn.

isSpam: A boolean value indicating whether the notification is a spam notification
subscribeFn: A function that opts the user in to the spam notification's channel
isSubscribedFn: A function that returns a boolean value indicating whether the user is subscribed to the spam notification's channel

Here’s an example of how you can render the Notification Item component for each spam notification:

{spams.map((oneNotification, i) => {
  const { 
    cta,
    title,
    message,
    app,
    icon,
    image,
    url,
    blockchain,
    secret,
    notification
  } = oneNotification;

return (
    <NotificationItem
      key={`spam-${i}`}
      notificationTitle={title}
      notificationBody={message}
      cta={cta}
      app={app}
      icon={icon}
      image={image}
      url={url}
      theme={theme}
      chainName={blockchain}
      isSpam={true}
      subscribeFn={subscribeFn}
      isSubscribedFn={isSubscribedFn}
    />
  );
})}

To implement the subscribeFn and isSubscribedFn functions, you can use the PushAPI.channel.subscribe() and PushAPI.channel.subscriptions() methods from @pushprotocol/restapi package, respectively.

Here’s an example of how you can implement these functions:

await PushAPI.channels.subscribe({
  signer: _signer,
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
    env: 'staging'
});

const subscriptions = await PushAPI.user.getSubscriptions({
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  env: 'staging'
});

Putting it all together

Here is an example using subscribeFn that demonstrates the uiweb components used together.

import React, { useState, useEffect } from "react";
import { NotificationItem, chainNameType } from "@pushprotocol/uiweb";

function MydApp() {
  const [notifications, setNotifications] = useState([]);
  useEffect(() => {
    const fetchNotifications = async () => {
      // fetch user notifications using the PushAPI
      const notifications = await PushAPI.user.getFeeds({
        user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', // user address in CAIP
        env: 'staging'
      });
      setNotifications(notifications);
    };
    fetchNotifications();
  }, []);
  return (
    <div>
      <h1>MydApp</h1>
      <h2>Notifications</h2>
      {notifications.map((notification, i) => {
        const {
          title,
          message,
          app,
          icon,
          image,
          url,
          blockchain
        } = notification;
        return (
          <NotificationItem
            key={i}
            notificationTitle={title}
            notificationBody={message}
            app={app}
            icon={icon}
            image={image}
            url={url}
            theme={theme}
            chainName={blockchain as chainNameType}
          />
        );
      })}
    </div>
  );
}

MydApp is a component that renders a list of notifications and spam notifications, as well as a form for subscribing to or unsubscribing from spam notifications. It uses the following components from the @pushprotocol/uiweb package:

NotificationItem: A React component for rendering a single notification item.
Spam: A React component for rendering a single spam notification item, with options for subscribing or unsubscribing to the spam notification channel.
Subscribe: A React component for rendering a form for subscribing to a spam notification channel.
Unsubscribe: A React component for rendering a form for unsubscribing from a spam notification channel.

MydApp uses the useState and useEffect Hooks to fetch and display the user's notifications and spam notifications using the PushAPI. It also defines event handlers for subscribing to and unsubscribing from spam notifications.

MydApp returns a JSX element that contains the following elements:

A div element with a h1 element for the title of the application and a h2 element for the section heading for the notifications.
A loop that renders a NotificationItem component for each notification in the notifications array.
A h2 element for the section heading for the spam notifications.
A loop that renders a Spam component for each spam notification in the spamNotifications array.
A h2 element for the section heading for the subscription form.
An Unsubscribe component if the user is subscribed to spam notifications, or a Subscribe component if the user is not subscribed to spam notifications.

There are of course other React components that you can to compliment the uiweb API. For instance: the Feed component is a container for displaying a list of notifications in a UI. It takes the following props:

notifications (array of Notification objects): An array of notifications to be displayed in the feed. Each Notification object should have the following shape:
cta (string): The call-to-action text for the notification.
title (string): The title of the notification.
message (string): The body of the notification.
app (string): The name of the app that sent the notification.
icon (string): The URL of an icon to be displayed with the notification.
image (string): The URL of an image to be displayed with the notification.
url (string): The URL to be opened when the notification is clicked.
blockchain (string): The name of the blockchain on which the notification was sent.
theme (Theme object): An object defining the colors and styles to be used in the feed. The Theme object should have the following shape:
background (string): The background color of the feed.
color (string): The text color of the feed.
chainName (string): The name of the blockchain to be displayed in the feed.

Example:

import NotificationItem from "@pushprotocol/uiweb/NotificationItem";
import Feed from "./Feed"; // User-implemented component

const notifications = [
  {
    cta: "Learn More",
    title: "Notification 1",
    message: "This is the first notification",
    app: "My App",
    icon: "<https://my-app.com/icon.png>",
    image: "<https://my-app.com/image.png>",
    url: "<https://my-app.com/notification-1>",
    blockchain: "Ethereum"
  },
  {
    cta: "Get Started",
    title: "Notification 2",
    message: "This is the second notification",
    app: "My App",
    icon: "<https://my-app.com/icon.png>",
    image: "<https://my-app.com/image.png>",
    url: "<https://my-app.com/notification-2>",
    blockchain: "Ethereum"
  }
];
function MydApp() {
  return (
    <Feed
      notifications={notifications}
      theme={{ background: "blue", color: "white" }}
      chainName="Ethereum"
    />
  );
}

That’s it! You now know how to use the components of the @pushprotocol/uiweb API to add push notification functionality to your application.

We’ll cover other parts of the Push SDK in coming posts so stay tuned!

Push Protocol SDK documentation here — if you’d like more reference material to chew on.
Push SDK on GitHub

Getting Started With Push SDK REST API

Push Protocol — Tue, 07 Feb 2023 08:41:52 +0000

The PUSH-SDK, is a growing JavaScript-based SDK that allows developers to add push notification functionality to their dapps. Using the SDK, developers can:

Build PUSH features into their dapps
Get access to Push Nodes APIs
Render Push Notifications UI

It is written in Typescript and supports React, React Native, Plain JS, and Node JS-based platforms. (We are adding support for more!) It is also built on top of standard Web3 packages like ethers, @web3-react.

If you’re looking for our full documentation on Push-SDK REST API, you can find that here.

But for now, let’s walk you through the main features of the Push-SDK REST API and how to use them in your code.

Fetching user notifications

You can use the getFeeds method to fetch a user's notifications. This method takes an options object as an argument, which allows you to specify the following parameters:

user (mandatory, string): The user’s address in CAIP format.
page (optional, number): The page index of the results. Default is 1.
limit (optional, number): The number of items per page. Default is 10.
spam (optional, boolean): Whether to fetch spam notifications. Default is false.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.
raw (optional, boolean): Whether to return the raw, unformatted API response. Default is false.

Here’s an example of how you might use the getFeeds method in your code:

const notifications = await PushAPI.user.getFeeds({
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  env: 'staging'
});

In this example, we define a user address using the CAIP format. CAIP, or Chain Agnostic Improvement Proposal, is a way to describe standards for blockchain projects that are not specific to a single chain. It was developed by the Ethereum Improvement Proposal (EIP) process and is used to identify and encode information about Ethereum addresses, contract addresses, and other crypto-assets.

It is important to note that CAIP is not a standardized way of identifying and encoding information about crypto-assets; it is under development by the Ethereum community and is not yet widely adopted in the ecosystem.

CAIP addresses are composed of three parts:

The namespace: This is a string designed to uniquely identify a blockchain ecosystem or set of ecosystems as a namespace.
The network ID: This is an integer that identifies the Ethereum network the asset belongs to. For example, 1 is the main network, 3 is the Ropsten test network, and 5 is the Goerli test network.
The address: This is the actual address of the asset, encoded as a hexadecimal string.

For instance:

eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681

In this example, the namespace is eip155 which identifies EVM chains, the network ID is 5 (Goerli test network) and the address is

0xD8634C39BBFd4033c0d3289C4515275102423681

CAIP is designed to be flexible and extensible, allowing for the inclusion of additional information as needed. It is used by the Push Protocol and other Ethereum-based projects as a standardized way of identifying and encoding information about crypto-assets, and distinguishing information from different chains.

Continuing with getFeeds, to fetch spam notifications, set the spam parameter to true:

const spams = await PushAPI.user.getFeeds({
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  spam: true,
  env: 'staging'
});

The getFeeds method returns a list of notifications for the specified user.

Fetching user subscriptions

You can use the getSubscriptions method to fetch a user's subscriptions. This method takes an options object as an argument, which allows you to specify the following parameters:

user (mandatory, string): The user’s address in CAIP format.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here’s an example of how you might use the getSubscriptions method in your code:

const subscriptions = await PushAPI.user.getSubscriptions({
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  env: 'staging'
});

The getSubscriptions method returns a list of channels [{ channel: '0xaddress', ... }] subscribed by the user.

Fetching channel details

You can use the getChannel method to fetch information about a specific channel. This method takes an options object as an argument, which allows you to specify the following parameters:

channel (mandatory, string): The channel’s address in CAIP format.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here’s an example of how you might use the getChannel method in your code:

const channelData = await PushAPI.channels.getChannel({
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  env: 'staging'
});

The getChannel method returns an object with information about the channel.

Searching for channels

You can use the search method to search for channels based on a specified query. It takes an options object as an argument, which allows you to specify the following parameters:

query (mandatory, string): The search query.
page (optional, number): The page index of the results. Default is 1.
limit (optional, number): The number of items per page. Default is 10.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here’s an example of how you might use the search method in your code:

const channelsData = await PushAPI.channels.search({
  query: 'push',
  page: 1,
  limit: 20,
  env: 'staging'
});

The search method returns a list of channels that match the search criteria.

Opting into a channel

You can use the subscribe method to allow a user to opt into a specific channel. This method takes an options object as an argument, which allows you to specify the following parameters:

signer (mandatory, object): The object that signs the subscription transaction.
user (mandatory, string): The user’s address in CAIP format.
channel (mandatory, string): The channel’s address in CAIP format.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here’s an example of how you might use the subscribe method in your code:

await PushAPI.channels.subscribe({
  signer: _signer,
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
    env: 'staging'
    });

The subscribe method returns a confirmation of the subscription.

Opting out of a channel

You can use the unsubscribe method to allow a user to opt out of a specific channel. This method takes an options object as an argument, which allows you to specify the following parameters:

signer (mandatory, object): The object that signs the unsubscription transaction.
user (mandatory, string): The user’s address in CAIP format.
channel (mandatory, string): The channel’s address in CAIP format.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here’s an example of how you might use the unsubscribe method in your code:

await PushAPI.channels.unsubscribe({
  signer: _signer,
  user: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681',
  env: 'staging'
});

The unsubscribe method returns a confirmation of the unsubscription.

Sending a notification

You can use the sendNotification method from the payloads object to send a direct payload notification to a specific recipient, group of recipients, or all recipients. This method takes an options object as an argument, which allows you to specify the following parameters:

signer (mandatory, object): The object representing the signer for the transaction.
type (mandatory, number): The type of recipient. Possible values are 1 (broadcast), 3 (single recipient), and 4 (group of recipients).
identityType (mandatory, number): The identity type of the recipient. Possible values are 2 (direct payload).
notification (mandatory, object): An object representing the notification.

title (mandatory, string): The title of the notification.
body (mandatory, string): The body of the notification.

payload (mandatory, object): An object representing the payload.

title (mandatory, string): The title of the payload. body (mandatory, string): The body of the payload.
cta (optional, string): The call-to-action of the payload.
img (optional, string): The image of the payload.

recipients (optional, string or array of strings): The recipient address(es) in CAIP format. Only required for type 3 (single recipient) or type 4 (group of recipients).
channel (mandatory, string): The channel’s address in CAIP format.
env (optional, string): The API environment to use. Possible values are ‘prod’ and ‘staging’. Default is ‘prod’.

Here are examples of how you might use the sendNotification method in your code:

Single recipient (target):

const apiResponse = await PushAPI.payloads.sendNotification({
  signer,
  type: 3, // target
  identityType: 2, // direct payload
  notification: {
    title: `[SDK-TEST] notification TITLE:`,
    body: `[sdk-test] notification BODY`
  },
  payload: {
    title: `[sdk-test] payload title`,
    body: `sample msg body`,
    cta: '',
    img: ''
  },
  recipients: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', // recipient address
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', // your channel address
  env: 'staging'
});

Group of recipients (subset):

const apiResponse = await PushAPI.payloads.sendNotification({
  signer,
  type: 4, // subset
  identityType: 2, // direct payload
  notification: {
    title: `[SDK-TEST] notification TITLE:`,
    body: `[sdk-test] notification BODY`
  },
  payload: {
    title: `[sdk-test] payload title`,
    body: `sample msg body`,
    cta: '',
    img: ''
  },
  recipients: ['eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', 'eip155:5:0xCdBE6D076e05c5875D90fa35cc85694E1EAFBBd1'], // recipients addresses
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', // your channel address
  env: 'staging'
});

All recipients (broadcast):

const apiResponse = await PushAPI.payloads.sendNotification({
  signer,
  type: 1, // broadcast
  identityType: 2, // direct payload
  notification: {
    title: `[SDK-TEST] notification TITLE:`,
    body: `[sdk-test] notification BODY`
  },
  payload: {
    title: `[sdk-test] payload title`,
    body: `sample msg body`,
    cta: '',
    img: ''
  },
  channel: 'eip155:5:0xD8634C39BBFd4033c0d3289C4515275102423681', // your channel address
  env: 'staging'
});

The sendNotification method returns a confirmation (apiResponse) of the notification being sent, with a status code of 204 indicating success.

--
That’s it! You now know how to use the main features of the Push Protocol REST API to add push notification functionality to your application!

We’ll cover other parts of the Push SDK in coming posts so stay tuned!

Push Protocol SDK documentation here — if you’d like more reference material to chew on.
Push SDK on GitHub
Our Discord — we’ve got devs ready to give your project whatever support and consultation you need.

Building a Leading Web3 Communication Layer: What’s it take?

Push Protocol — Tue, 24 Jan 2023 09:37:31 +0000

Decentralized communication is a hot topic in the web3 space as more and more developers are looking to build dapps that can function independently of any single central authority.

Though, a key component of building a successful dapp is providing a communication layer that is both decentralized and universal.

A decentralized communication layer does not rely on any central server or authority. Instead, it depends on a distributed network of nodes to handle and route data between users. This ensures communication is resistant to censorship, tampering, and other forms of interference, as well as be able to function even if some nodes go offline.

In this way, a universal communication layer is accessible to all users regardless of their device or platform. This is essential in the web3 space, as users will often have a variety of different devices and platforms that they need to interact with to access and use a dapp.

What does it take to build a web3 communication layer?

In general, to build a decentralized and universal communication layer, several vital components are required, including:

Robust Network Architecture: The network architecture of a decentralized communication layer must be designed to ensure that data can be reliably and efficiently routed between nodes, even in the event of node failures or network congestion.
Data storage: Decentralized communication systems typically rely on distributed data storage to ensure that data is stored redundantly across multiple nodes, making it less vulnerable to data loss or corruption.
Consensus: A consensus mechanism ensures that all nodes in the network agree on the system’s state. This is particularly important in decentralized systems, as there is no central authority to ensure that all nodes are in sync. Network maintainers must verify and finalize message data for a communication layer to function.
Security: Securing a decentralized communication system is a significant concern, as there are a variety of potential attack vectors that could be used to compromise the security of the system. A communication layer must consider encryption and authentication mechanisms to ensure the safety of the users’ data.
Interoperability: A universal communication layer must interact seamlessly with various devices and platforms, so a communication protocol needs to ensure that the system can handle different data formats and protocols.
Composable: A communication layer must be able to adapt to a variety of conditions and improve as required. This includes the incorporation of new technologies and web-based systems.

With these components, a web3 communication layer can offer censorship-resistant, privacy-preserving, and spam-protected communication while being chain-agnostic, gasless, and scalable.

We’re always Pushing.

Building a decentralized communication layer is a process, not a product, meaning it’s not something that can be fully achieved but rather something that requires consistent development.

The team at Push Protocol is continuously working on improving its architecture by crafting and refining the key components for building a communication layer. With a strong focus on security and performance, Push is working to bring the best decentralized communication tools possible to the web3 space.

As a result, the Push Protocol community continues to rapidly evolve and is getting closer to reaching its goal of enabling millions of users and devices to communicate simultaneously across web3. Push brings novel communication capabilities to the decentralized world with real-time messaging, efficient message dissemination, and interoperability, allowing it to become the communication standard for dapps.

If you’re interested in exploring how Push Notifications or Push Chat can boost user engagement and benefit your project, check out: Docs and visit our website https://push.org/

A deeper look into a decentralized chat -- Push Chat

Push Protocol — Wed, 21 Dec 2022 14:51:10 +0000

Push Chat is providing secure and instant communication for all by connecting users and dapps across web3.

In this article, we deep dive into how Push Chat works and its use case.

Push Chat is still in alpha and we’re gradually rolling out early access to all of you. If you want to skip the line and become one of the first builders to try out Push Chat — keep reading 👀

What Is Push Chat?

Push Chat is a secure messaging protocol built by Push Protocol. Messages are encrypted, signed, and stored on IPFS and they are sent through Push Nodes.

Note: The team is continuing to develop the Push Protocol including notification and chat for wallets regardless of any chain in web3 in a multichain, platform-agnostic, and gasless way. Push Chat is the next offering of the protocol after push notifications and is currently available on Ethereum and Polygon with other chain support to follow soon.

Why Push Chat now?

Push Chat and video were imagined by us in 2020 but we knew that before notifications become a reality, doing chat or video will just become a novelty as everything we do in our virtual lives starts out with a notification.

For example, you don’t chat on WhatsApp as much as you chat via notifications on WhatsApp, the same is the case with Facetime. Owing to this, Push created notifications for web3 first which paved the way for real-time communication mediums to become a possibility.

Push Protocol’s vision has remained to be the de-facto layer of communication for the entire web3 and Push Chat (with native push notification support) helps in wrapping another milestone to bring the UX of web3 on par with web2.

How Push Chat works?

Push Chat uses IPFS, encryption, and pinning of the messages on Push Nodes to enable a seamless, no-message drop experience for the user. Each message (and notification) carries a verification proof which the front-end can use to determine that the message content and sender are actually the ones that sent these messages out. You can read about notification verification proofs and the various supported formats here.

What are Push Nodes?

Push Nodes are a network of nodes, where each node can have a different role in the network that is responsible for validating and dispatching each notification and chat message between addresses.

Their main task is to validate that:

the payload is following the corresponding payload standard,
the sender can actually send the message, and signature validation,
if the payload is valid, the Push Nodes will store the message on IPFS and then send a notification to the receiver of the message.

Note: Push Nodes are in alpha right now and are currently run by the push protocol team with an alpha version of these nodes scheduled to come out around Q1 / Q2 of 2023.

Who is currently running Push Nodes?

The Push team currently runs the Push Nodes for Push Chat. The team is working towards decentralizing the network every day by making progress in establishing the underlying primitives for the Push Protocol. This is only until the team fully bootstraps the Push Protocol and the protocol and Push Chat are production ready.

Once the network becomes fully decentralized, Push Nodes will be incentivized to maintain the network, be readily addressable, and provide message content through $PUSH tokens which are native tokens of the protocol.

How Does a User Send a Message Using Their Account Address?

A user of Push Chat has two sections: Chats and Requests.

Users sending a message to another address for the first time will be the first subject to the Request type until the receiving address accepts the message. Then, messages and notifications from that address will appear in the receiving addresses chats section. Eventually, users will be able to block addresses. Receiving addresses aren’t notified about messages in the Request box. This prevents users from receiving messages from any random address that sends them a message and general spam.

If a message is sent to an address that hasn’t been authenticated yet on the Push Protocol, those messages will be in plain text until the receiving address authenticates itself.

Where are messages stored?

Push Nodes store all messages sent over the network. Any Push Node can expose locally stored messages to the network, which other Push Nodes can connect to and fetch. The nodes can then push these messages to a user’s public address. Each message is stored on IPFS along with its verification proof which allows the frontends to verify that the content of the message indeed originated from the sender and not from anyone else.

Are messages safe, and is the network secure?

PGP (Pretty Good Privacy) is an encryption method that provides privacy and authentication for data communication. PGP encryption keys are generated for every address on the network. Learn more about P2P encryption here.

The PGP public key is used to encrypt the content sent using asymmetric encryption. This ensures that the encrypted message payload can only be decrypted by the receiver and no other third party can decrypt or see the content of the message.

Note: The encryption method used here is future-proof, as other methods can encrypt the keys and adapt to newer cryptography.

Does this apply to notifications? How do notifications fit into all this?

Chat while an integral part of any application works best when notifications are integrated into it natively. Most of the time, whenever we are chatting either on Discord, Telegram, WhatsApp, or anywhere else, we usually don’t have the application open. Instead, we reply to a message and then go on doing other activities until the other person replies which we receive as a notification.

Push Chat uses this exact web2 UX to ensure that the web3 user finally gets the same experience as that of a web2 user by utilizing the native push notifications capabilities of Push Protocol to send a notification out to the wallet address if the wallet address has approved the request of the sender wallet.

Push Working Towards Decentralization

Applications need to protect users and their data and remove censorship. The Push team is privileged to tackle a fundamental problem in the new web (such as the poor user experience and a subliminal communication layer).

To achieve decentralization, the Push team has broken that into two phases, one is content can’t be changed and the other one is content can’t be censored.

1) Content can’t be changed

With verification proof, the immutability of the content is always ensured (1).

2) Content can’t be censored

This is achieved by developing Push Nodes that enables anyone to run the node in a permissionless way with PoS to incentivize and penalize behavior. Alpha Push Nodes are scheduled to happen somewhere between Q1 / Q2 of 2023.

Push-ing Real Solutions for Web3

Yes, the user experience in web3 needs much work, and to be frank, it is likely years out from where it should be. That is why the Push team is focusing on a protocol that tackles the problem from the ground up, a grassroots solution, and a primary reason why web3 is the next iteration of the web — improving how we interact.

When a sufficient number of dapps and services in web3 implement Push chat, it enables a new wave of use cases and scales coordination because now messaging and notifications are web-wide and not in isolation to dapps and their users.

Dapps can use event-driven computation to communicate off-chain or on-chain with one another and enable fully-scaled coordination. Dapps also don’t have to worry about maintaining the underlying infrastructure to push messages which takes the load off developers, and the network guarantees message integrity.

We mean it — let’s scale communication

We previously described how you could use Push Protocol for various use cases in web3, such as in governance. While Push allows for these great capabilities, the truth is that many web3 governance systems lack participation. Many DAOs depend on a few contributors and have a central source of truth, and there is still a disconnect between DeFi and the user. User coordination generates high-value sources of truth. We can see this with the effectiveness of crowdfunding, the pooling of knowledge, funds, and resources, novel voting methods, petitions, and even zero-knowledge primitives. An easily adaptable communication stack and an ambitious outlook are a step in the right direction.

Imagine a web-wide poll about a major topic that anyone around the world can participate in. The poll is guaranteed to be censorship-resistant and verifiable, all while properly incentivizing those who participated and curated the poll with their resources. This scratches the surface of the coordination capabilities of a web3-native messaging protocol.

Push your dapp

Your application and the users of web3 deserve robust communication. Push Chat can help. Here is a summary of its key features:

Push Chat is permissionless: the production-ready version will allow any address on any platform to use their account (address) to chat with any other account across web3. Users aren’t required to sign up anywhere.
Push Chat is forward-compatible: Push Chat can adapt to any changes made to existing platforms or new ones that arise, as the messaging functionality will not rely on the underlying platform the messages are sent and received from.
Push Chat is user-friendly: Push Chat is a friendly and familiar-facing user experience that current users appreciate.
Push Chat is developer-friendly: Using the Push chat SDK, developers can add a messaging layer to their application or service. The message type is JSON, making it easy for developers to consume and interpret. Developers can integrate push chat into the development workflow and improve their CI/CD processes. Test and deployment results can be pushed as messages to user wallets.

Pssssssst 🤫

Thanks for making it this far.

If you’re interested in exploring how Push Chat can boost user engagement and benefit your project, please join our Discord #push-chat-alpha channel, and tell us what you’re building, we’ve got devs who can help give consultation and we’ll be sharing exclusive Push Chat access to Discord members soon!

To get started building right away, head over to the Push Chat developer docs.

See you soon on Push Chat!

--
Visit Push Protocol: https://push.org/
Push GitHub: https://github.com/Push-Protocol

‘My Dapp’ Would Like to Send You Push Notifications

Push Protocol — Fri, 18 Nov 2022 08:55:06 +0000

In the modern push technology, there are primary components: an app publisher who publishes information by notifications, a client who is the receiver of notifications based on a subscription, and the push notification provider who acts as middleware between these two actors.

Middleware is software that acts as an intermediary between two applications or services. Middleware also provides services that are not present in the operating system. The push notification service provider is an example of this, known as an operating system push notification service (OSPNS). For instance, the Apple Push Notification Service (APNS) lives on iPhone devices as an OSPNS middleware software.

Taking the Push Notification Provider Away From the Notifications

Web3 moves away from the traditional client-server model and alleviates today’s power concentration over the control and truth of information and data. Web3 attempts to take service providers away from services, where middleware becomes trustless software (but can still be trustful) that offers security guarantees and robust communication through decentralization. Web3 also attempts to reconfigure how we monetize things in society and redirect incentives to where they should go, users, participants, communities, and those generating value.

Addressing the limitations of push technology while utilizing its features in the next iteration of the web requires an OSPNS-like piece of middleware. There needs to be a similar layer of abstraction and push technology primitives that allow notifications to create a web3-based OSPNS.

Enter Web3 Push Notifications

The Ethereum Push Notification Service (EPNS): a decentralized OSPNS for push notifications; the open communication layer for web3.

EPNS addresses the user experience problem in web3 by providing push notifications for wallets and dapps. EPNS allows any dapp, smart contract, backend, protocol, or, in principle, any distributed technology to send communication directly to user wallet addresses in an open, feeless, and platform-agnostic way. Being an open and permissionless protocol, anyone can create dedicated channels to distribute information directly to user wallets without needing to rely on centralized service providers. The protocol serves many communication primitives beyond simple push notifications, such as peer-to-peer chatting, communication channel creation, and on-chain governance. In addition, EPNS addresses information and content censorship as the protocol allows users and applications to control the content they’d like to push.

Web3 users:

don’t need to trust or rely on a centralized OSPNS for information.
don’t need to interact with applications unnecessarily and manually stay on stand-by for any activities they would like.
can opt-in to information and alerts they find useful.
can communicate with other accounts instead of operating in isolation.
can automate messages that users and dapps care about.
can expect a much better onboarding experience.
EPNS enables open and direct peer-to-peer communication through an incentivization scheme without compromising communication or anonymity. Instead of app-to-client messaging, EPNS allows for wallet-to-wallet or service-to-wallet messaging both for on and off-chain events. As a result, end users have end-to-end visibility of transactions and on-chain events to generate awareness while increasing trust.

For example:

Governance mechanisms in web3 often lack good user experience as users must constantly check on and off-chain activity for recent updates and proposals. Or, users depend on the news efforts from individuals on the latest governance activity.

If, for instance, a user wants to keep informed and engaged with Uniswap’s governance proposals, they have the overhead of constant engagement to not miss out on any activity.

With EPNS, that changes.

Integrating EPNS with Uniswap allows users to receive notifications directly to their wallets whenever a new governance proposal is submitted, such as the recent governance proposal to create the Uniswap Foundation, allowing users to stay up-to-date and never miss a vote.

This is what EPNS had the pleasure of doing in early 2021 — integrating with Uniswap to accelerate DeFi and the web3 experience. Learn more about the collaboration in this blog post.

The information required to notify users about different web3 events is complex and requires massive infrastructure efforts, which is another reason EPNS started. EPNS is also a demonstration of how to scale services and implement solutions in a modular way, as developers can easily build dapps with EPNS. Before diving into the communication layer itself, including how communication channels and messaging work with EPNS, how the publish/subscribe model fits into web3, and understanding EPNS under the hood, we will attempt to make the case by using web3 push notifications for different use cases and the need for a web3 communication layer in Part 2.

About Push Protocol

Push is the communication protocol of web3. Push protocol enables cross-chain notifications and messaging for dapps, wallets, and services tied to wallet addresses in an open, gasless, and platform-agnostic fashion. The open communication layer allows any crypto wallet / frontend to tap into the network and get the communication across.