Notifications

Notifications still pose a problem for decentralized applications because Google (Android) and Apple (iOS) control, limit, and charge for mobile notifications even if a user has an app installed.

ServiceWorkers can (last time we tested) do a notification up to about 15 minutes past app tab focus.

Unfortunately, email is probably the best option, but requires relay operators to opt in require('gun/lib/email').send({subject: "", text: "", from: "", to: ""}, cb) with npm install emailjs added on relay and ENV params set for process.env.EMAIL process.env.EMAIL_KEY process.env.EMAIL_HOST and (with gmail, last tried) only works with a special app key. If we get more people to opt into providing one of their emails as a proxy for sending notifications out, this could create a free notification service but MUST be limited to ~1 notification per day by default (user opt in/out frequency) that groups all notifications. Also note, that email notification seems delayed on some devices too.

It may be worth looking into operators opting into providing SMS notifications that group and link to app notifications next.

Tradeoffs

It would be useful to have a universal notification system that does not rely on a centralized gatekeeper like Google/Apple. However, this poses some problems on how to deal with spam:

1. Time rate limiting the notification batch reduces spam, but then the notification must list all the corresponding app URLs.
2. If app URLs do not need to be registered, then a malicious developer could generate thousands of app URLs to take up space inside the singular batch in a spammy way.
3. If apps are limited per domain/origin, we're just using domain registration as a proxy for gatekeeping which is still gatekeeping - it also limits a static host from being able to help distribute many different apps from potentially many developers.
4. If we then do first come first serve then its easy for malicious developers to flood a batch blocking out legit notifications. Something better may be to rate limit so all apps (good or bad) have to retry, which may more evenly disperse chances, but isn't ideal. Proof of work will certainly be gamed by malicious developers, as they're usually more experienced at spinning up parallel bot/compute networks while as legit developers are often too lazy for that or to learn how to implement the work system.
5. If the batch system were to sort the notifications in the batch by highest legitimacy, this would be ideal, but then who determines legitimacy? That becomes gatekeeping again, although could be done in a non-centralized manner, but that suddenly dramatically increases the complexity at this layer which is not ideal.
6. If the user whitelists frequency of which apps, we may need some type of app or user verification system, which increases the complexity at this layer, which is not ideal.

Any clever ideas?