Open anoadragon453 opened 6 years ago
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)
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 :)
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:
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.
ZeroMail can send notifications using @Imachug 's BackgroundProccessing plugin. https://github.com/HelloZeroNet/ZeroNet/pull/1451
@DaniellMesquita How are these notifications sent? I chose the web-based notification APIs as they work on all OS's, mobile and over proxies.
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.
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.
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
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.
@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.
It's not in short term plans and unlikely that it will happen before py2 -> py3 move
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 :)
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
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?
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)
Right, makes sense. Perhaps it would make sure to have a user-configurable timer for checking every x minutes for external notifications?
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?