NotifIC - A Decentralized Notifications Inbox

[Hazel]

Hey all!

We just launched Notific a decentralized notifications inbox. Our goal here is to build a robust Web3 notifications inbox. We’re hoping Notific carves out a little place for itself in the IC Infrastructure Ecosystem. We produced this in an internal hackathon, so as you can imagine, things are pretty basic right now.

The success of this project requires projects come and integrate. So…

If you’re interested in building in compatibility, If you need additional features, or you find bugs… let us know!

In the meantime, we’d appreciate your retweets on our announcement.

[levi]

Awesome!!! I’m looking forward for the documentation!

[Gekctek]

I’m sure technical/api docs will come eventually but can you explain at a high level the current functionally of the protocol/api and where you guys are going with it?

[bytesun]

very interested in integrating, any docs?

[Hazel]

@Gekctek

I’m sure technical/api docs will come eventually but can you explain at a high level the current functionally of the protocol/api and where you guys are going with it?

Going to give you a bit more than what you asked for since I was just thinking about it. Hope that’s okay!

For now the protocol is incredibly simple but actually quite robust.

Let’s define some terms real quick just because…

Inbox - An inbox identifier by an UUID16 identifier.
Integrators - Apps who want to send notifications.
Users - People with a Notific Inbox who use other Apps.

High Level Architecture

Today, we’re running a single canister which is acting as a Multi-Tenant host for everyones Inboxes. Notifications and Inboxes are stored in stable memory as JSON bytes; this has a slight overhead cycles cost. But, its negligible in the scheme of things. Moreover, this assures…

1. We fail gracefully if we somehow explode in popularity (i.e no risk to heap).
2. In the event of a Catastrophe, disaster recovery is as simple as possible; It’s just JSON.
3. We have a clear path forward when its time to break these things out into personal canisters.
4. Upgrades are effortless and we can safely update our underlaying data structures.

Inbox

Inboxes are identified by a UUID16 String. Every inbox has a list of Integrators which are allowed to publish notifications. So, unlike an SMS or Email Inbox, applications must ask permission to send you things. This allows users to actually be in control of what they’re receiving. And, Integrators can be removed with one click.

Inboxes can have multiple controllers. Meaning, they can be shared . We don’t have any permission control yet. But, if someone needs this they can just use… Subscriptions and create a little DAO canister.

Each Inbox also let’s users manage a list of Subscribers which are forwarded every notification. We don’t have any retrying logic built in here yet but we don’t anticipate this being an issue for awhile to come.

Integrators

Integrators are just services that want to send notifications. Distrikt and DSCVR could be integrators. But, really any canister could be an Integrator. Once an Integrator is added to an Inbox they get permission to send notifications. Integrators can also declare a list of “Callbacks”. Which, I’ll elaborate a bit more on next.

Notifications

Notifications end up in a users Inbox after being created by an integrator. The most simple Notifications are just text. Maybe a link. Maybe some images. But, because of how we’re structured the App. They better be useful, or a user is just going to revoke an Integrators permission to send them.

type CreateNotificationRequest = record {
    user_id : text;  // Who is this going to.
    subject : text;  
    body : text;
    level : NotificationLevel;
    callback_actions : vec CallbackActions; // Hmm, what are these?
};

Notifications don’t have to be simple though… We’re working on the ability to embed CallbackActions. Which, would allow the user to make canister calls directly from the notification ! I’m really excited about this feature, I think it would truly supercharge Notific making it almost a low-code platform for developers.

[bytesun]

@Hazel

CreateNotificationRequest

we have a requirement to notify multiple users with the same message(e.g. users subscribe a calendar) at same time, not sure if it is also in your design?

[Hazel]

Just PR’d this in :). This is a general purpose solution. But, I believe it fits most of your requirements. You can create a batch of notifications over the wire using this with a single call; as opposed to making 1000 calls and racking up all those intercanister call costs

type CreateNotificationRequest = record {
    user_id : text;
    subject : text;
    body : text;
    level : NotificationLevel;
    callback_actions : vec CallbackActions;
};

type CreateNotificationResponse = variant {
    Ok : NotificationWithId;
    Err : CreateNotificationError;
};


// Batch types
type BatchCreateNotificationRequest = record {
    notifications : vec CreateNotificationRequest;
};

type BatchCreateNotificationResponse = record {
    results : vec CreateNotificationResponse; // Maintains order of `BatchCreateNotificationRequest::notifications`
};

service : {
  create_notification_batch: (BatchCreateNotificationRequest) -> (BatchCreateNotificationResponse);
}

[Gekctek]

Very cool, thank you.
I think this type of thing is very much needed in the ecosystem. I was looking into doing some sort of content feed/modern rss feed system but had other priorities that came up. High level overview of a subscription protocol proposal

Long term, do you see this as a mix of all notifications like: email, social media notifications, content feed, etc… or just focusing on a few.
Also do you have plans/ideas for extendibility on the protocol? like specifying a certain notification type and data around that specific type?
Just trying to get an idea of the direction

[Hazel]

Long term, do you see this as a mix of all notifications like: email, social media notifications, content feed, etc… or just focusing on a few.

Long term, our goal is to consolidate all of the high value notifications into one place. Partly, we’re hoping the opt-in pattern will help drive that. My personal hope is that If you have a notification in Notific it should always be something worth checking out; a lofty goal lol.

Also do you have plans/ideas for extendibility on the protocol? like specifying a certain notification type and data around that specific type?

We have a few ideas. For starters, we’re working on building in notification callbacks. For v1 these are just going to be buttons. For instance, say you can an alarm notification from a PagerDuty like service. One of the buttons might be “acknowledge alarm”. Looking past that we’re hoping we can embed simple forms. We actually have levels of notifications already, but do you have something more specific that you’re thinking of?

Also, we have some early docs ready. If anyone is willing to take an early shot at integrating we created an OC group chat where we can help you get started!

OpenChat

[Gekctek]

Just thinking about different notification types and the data associated. Instead of just text, some things might be links or have structured meta data. Like ActivityStreams in activitypub Activity Streams 2.0
Little different than just an inbox. I had just been thinking about things like this and just curious how others are tackling long term protocol extendibility.
Just curiosity, not trying to push any changes on you guys