The document discusses the concept of 'nōtifs', a new notification management system aiming to provide users with more control over how and when they receive notifications, particularly in the context of mobile usage. Nōtifs are characterized as one-way, solicited, time-sensitive messages that enable centralized management, spam resistance, and user-defined preferences for alerts. The system includes mechanisms for updating, deleting, and expiring notifications while promoting vendor independence and ease of integration with existing services.

1. Notification
Management:
Putting Users in
Control
Jim Fenton (@jimfenton)

2. The Nōtifs Vision
๏ Notifications are a “thing”
- Not well served by existing services,
especially email
- Growing usage, particularly mobile
๏ Looked at how we use email, SMS, etc.
- Optimize for this subset of these uses
- Runs alongside these services
๏ Applications => apps, so
Notifications => nōtifs

4. Priorities

5. Categories
Official Approval
Internet of Things Social/Advertising
…and many more

6. What is a Nōtif?
๏ One-way
๏ Solicited, Opt-in
๏ Time-sensitive
๏ Perishable
๏ Short (typically)

7. Notification
Agent
Phone
CallSMS,
App push
Growl
Management,
Authorization
Notifications
Authorization Table
Rules
Bank
Emergency
Services
Retailers
Social
Media
Approval
Requests
Calendar

9. For Notifiers:
๏ Direct feedback when nōtifs are accepted
on behalf of users
๏ No need for third-party bulk senders
๏ Spam-and phishing-resistant
- No junk mail folders to avoid
๏ Less clutter => more impact

10. For Users:
๏ Centralized management/unsubscribe
๏ Control over how (or whether) to be alerted
when nōtifs arrive
๏ Spam and phishing-resistant

11. Spam and Phishing?
๏ No widely-used addresses
๏ Notifs are signed by the notifier domain
- Protects against theft of notifier’s database
๏ No From address => nothing to spoof
- From address in authorization, not message

12. Privacy
๏ Notifiers don’t get persistent contact info
๏ Addresses are unique, opaque
- (and in the background)
user@example.com
415 555-2368
🚫
🚫

13. Alerts
๏ Users describe their push methods to
notification agent
- Cell phones (SMS), voice phones, email, app
push
๏ Rule sets decide if/how to alert the user
- Based on priority, category, notifier
- Can be time of day based

14. Opting In
Notification
Agent
User
Notifier
1. Request authorization to notify
2. Browser redirects to
Notification Agent, User
agrees
3. Notification address
sent to Notifier

15. Cutting the Clutter
๏ Less nōtif clutter: Good for everyone
- Users get relevant nōtifs
- Nōtifs have more impact
๏ 3 mechanisms:
- Update
- Deletion
- Expiration
๏ All best-effort

16. Update
๏ Notifier replaces a previous nōtif
- Tornado watch -> warning
- More info on wanted criminal
- Updated auction bid status
- Error in original nōtif

17. Delete
๏ An update that deletes the nōtif
- AMBER Alert: Child is found
- Requested approval no longer needed
- User left vicinity of location-triggered notif
- Alarm condition has been cleared
- Special offer sold out
- Voicemail has been collected

18. Expiration
๏ Timed automatic deletion
- Coupon expired
- Tornado warning expired
- Auction over
- Calendar event has passed
๏ Doesn’t require notifier activity

19. Running a Notification Agent
๏ Open-source implementations will be
available
๏ Comparable to running a website or blog
- Some will run their own
- Some will rely on commercial services
- Think Wordpress
๏ Outside commercial services can provide
support for user alerts

20. Being a Notifier
๏ Simple enough for IoT devices
- Modest persistent storage and crypto
๏ No need for special ISP arrangements like
static IP addresses
๏ Communicate with notification agents via
Web API
๏ Toolkit libraries will make this easy

21. Nōtifs Summary
๏ Something I wish I had
๏ An API purpose-built for notification
๏ Vendor-independent
๏ Not burdened by legacy protocol
requirements (like email)
๏ BUT: Deploying something new is hard