Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External Notifications API #1215

Open
anoadragon453 opened this issue Dec 21, 2017 · 16 comments
Open

External Notifications API #1215

anoadragon453 opened this issue Dec 21, 2017 · 16 comments

Comments

@anoadragon453
Copy link
Contributor

anoadragon453 commented Dec 21, 2017

Something that would be really nice is a way to send notifications from a zite once something updates to the current user, either when a new blog post was released, a new comment or a new video.

This could be implemented through the existing Web Notifications API globally for ZeroNet with a ZeroFrame API allowing zites to register for notifications, and a settings menu for granular control on which zites are allowed to send notifications. Or just have it all done through the existing information stream that ZeroHello generates.

This would allow for real-time chat where one wouldn't have to manually check for new updates, and could hook into zites like ZeroHello that could notify you whenever a new item was dropped into the Following feed.

What do you think, is it possible?

@HelloZeroNet
Copy link
Owner

The newsfeed feature is something like this, but there is lots of space to extend it's possibilities. Eg. by adding JS logic support for more complex notifications (to make ZeroMail support possible)

@anoadragon453
Copy link
Contributor Author

I was just sitting in my bed, decided to check ZeroHello and realized I got a response to a comment I made 30m ago which I missed. It would be nice to have some sort of push notifications system is all :)

@anoadragon453
Copy link
Contributor Author

Post

I think it's time to revisit this as the Web Notifications API is now supported on all major browsers.

My vision for this is quite simple:

  1. Ability for zites with 'admin' privileges to send web notifications that appear outside the browser.
  2. ZeroHello (or any other replacement notification aggregate) makes use of this new ZeroFrame API endpoint.
  3. ZeroHello occasionally checks for new notifications. When a new one comes in, it sends a web notification, and the users comes back to ZeroNet to see what's new.

Notifications have to be sent from a ServiceWorker, so ZeroFrame will spin one up when registering for notifications.

We should thus have two new api calls.

  • WrapperNotificationsRegister, returns "ok" if successful, otherwise the error message. This endpoint takes no arguments. Will start up a ServiceWorker on the current tab that can be used to send notifications.
  • WrapperNotificationSend, returns "ok" if the notification was successfully shown, otherwise the error message. Provided to this will be an array of three strings, "title", "body" and "icon", as those are the fields allowed by the Notifications API.

We can also handle events such as the user clicking vs. dismissing a notification, but this is out of the scope for just now.

The only downside to this is that the user has to keep ZeroHello as a tab open. There are a couple options for this. For instance, we could use a SharedWorker, which would be a ServiceWorker that could be accessed by any ZeroNet-based tab. This would mean that notifications would be shown as long as I had one ZeroNet zite open.

Additionally, we can also show notifications without any ZeroNet tabs open by instead using the Web Push API, however this requires an external server to send those Push notifications. While I think this could be achieved by the Python daemon, I don't understand enough yet to say that for certain. Additionally, the Push API is not yet supported by all browsers.

Thus I believe we should simply start with the Web Notifications API and work from there. The front-facing ZeroFrame API endpoints to zites should not change assuming a transition from say, ServiceWorkers to SharedWorkers.

What are your thoughts on this design, @HelloZeroNet? I think notifications is a big step for increasing user engagement with ZeroNet.

@danimesq
Copy link
Contributor

danimesq commented Sep 27, 2018

ZeroMail can send notifications using @Imachug 's BackgroundProccessing plugin.
#1451

@anoadragon453
Copy link
Contributor Author

@DaniellMesquita How are these notifications sent? I chose the web-based notification APIs as they work on all OS's, mobile and over proxies.

@danimesq
Copy link
Contributor

danimesq commented Sep 27, 2018

ZeroMail didn't implemented notifications yet.
But if implement, it will need BackgroundProccessing plugin merged into ZeroNet.

If ZeroMail implements notifications, it sends to ZeroHello that resends as Web Notifications. No need to use admin mode for just handling a simple API.

@anoadragon453
Copy link
Contributor Author

Yeah, hoping BackgroundProcessing and PeerMessage both get merged, but as I understand it, at least the first one needs some more security auditing and study before it's shipped out to everyone.

As for the admin API requirement, that needs some dicussion. ZeroHello would be the only site that needs to have admin privileges, as it would be the only site sending external notifications. ZeroMail would just send the usual in-ZeroNet notifications and then ZeroHello would notify the outside world about it.

Then again, we could just allow any site to send their own external notifications and not rely on ZeroHello, simply through the user's permission. ZeroHello would just automatically be granted this permission as it's an admin site.

The only reason I see for not allowing this would be some sites would stop going through the consolidated notifications feed, only doing their own notifications. But some users may block external notifications, only wanting to see them on ZeroHello, and therefore miss things as those sites aren't sending through ZeroHello. And thus we've ended up with fragmentation.

So that's my reasoning for having it as an "admin" site only feature.

@Thunder33345
Copy link
Contributor

i mean why not another flag called "notify" which then sites could do their own notification implementation

also what if someone dont want to use zerohello, lets say i have my own zerohello clone call it zerohome which then sites should be able to seamlessly implement it for any kind of "homepage" sites so long they follow some sort of standardized API structure

there's also the Built in notification idea, idea is notifications would be send in a built in OS method(fallback to web notification if it isnt supported/possible) OS would be windows 10+ and 10-, linux, android support
which yeah built in will take more work to taylor for all types of OS

and also note i dont want everything on my zerohello notify me so some fine grained control will be needed

@anoadragon453
Copy link
Contributor Author

i mean why not another flag called "notify" which then sites could do their own notification implementation

I'm not sure what you mean by this? Another flag to the existing way to notify? I could see this being used as a "don't pop up a web notification, this notification isn't important enough. But then, why send a notification in the first place? :P

also what if someone dont want to use zerohello

Mark ZeroHome as an admin site.

there's also the Built in notification idea, idea is notifications would be send in a built in OS method(fallback to web notification if it isnt supported/possible)

Browsers do use the system's notification scheme under the hood. I'm not sure what benefit this would have other than maybe customized notifications with buttons? What extra functionality would we need though?

windows 10+ and 10-

?

and also note i dont want everything on my zerohello notify me so some fine grained control will be needed

Yes, if we could put zites into "groups" and then mute specific groups that would be ideal, but I believe out of the scope of the initial implementation for now.

@anoadragon453
Copy link
Contributor Author

@HelloZeroNet could I get your thoughts on these plans, please? I'd like to work on this sooner rather than later if you like them.

@HelloZeroNet
Copy link
Owner

It's not in short term plans and unlikely that it will happen before py2 -> py3 move

@anoadragon453
Copy link
Contributor Author

Ah ok, I understand you probably want to get that done before implementing any big new features.

I'm going to try working on this in a separate branch though just as a PoC, and then once you're ready to accept new features again then we can see if it'd work out :)

@Thunder33345
Copy link
Contributor

i am going to purpose it to be made in a way that plugins can also watch for notifications
so that if someone wants they could easily make a plugin to rebroadcast these notification onto native notification

@anoadragon453
Copy link
Contributor Author

I'm not familiar enough with how ZeroNet plugins work to be able to say whether it would be possible for a plugin to intercept an existing call from a website to ZeroFrame, or otherwise hook into when ZeroHello checks for new updates. @imachug ?

@HelloZeroNet Does ZeroHello just check in followed sites when you load/look at the page, rather than every so often?

@HelloZeroNet
Copy link
Owner

Listing the newsfeed is pretty IO/CPU sensitive, so to reduce the load ZeroHello only checks it if you look at the page (activate the tab)

@anoadragon453
Copy link
Contributor Author

Right, makes sense. Perhaps it would make sure to have a user-configurable timer for checking every x minutes for external notifications?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants