[UC] Notifications

[csarven]

Status: Draft

As an author, Guinan wants to use an authoring tool to send an invitation to Deanna to review her article, So that Deanna can provide feedback and suggestions to improve the content before publication.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

• Actors can choose to identify themselves with the authoring tool by using their personal online identities.
• Storage and hosting are set up for actors to receive notifications in a dedicated location (such as an inbox).
• Actors are authorized to send public or private notifications to other actors or community inboxes.
• The location to send a notification to any actor can be discovered, via a follow-your-type type of exploration in various ways, e.g., by selecting a contact from the primary actor's address book or by manually entering the identifier of the target actor.

Trigger:

What (user or system) event or action initiates this use case?

Actors:

Describe the primary actor, and any other relevant actors involved in this use case

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

• https://en.wikipedia.org/wiki/Notification_system
• https://notifications.spec.whatwg.org/
• https://www.rfc-editor.org/rfc/rfc5322
• https://www.w3.org/annotation/diagrams/annotation-architecture.svg
• https://www.w3.org/TR/activitypub/
• https://www.w3.org/TR/activitystreams-vocabulary/
• https://www.w3.org/TR/ldn/
• https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Direct_Messaging

[bumblefudge]

perhaps i'm too "zoomed in" for the use case level of abstraction, but I can imagine this being implemented a couple different ways, depending on how we want to juggle "happy path" notifications (relatively standardized, clients able to navigate and understand all of them) and "fallback" or "manual override" notifications ("all i have for this user is an email, can i use mailto:alice@example.com instead of a proper URI?")...

[TallTed]

I am compelled to say that mailto:alice@example.com is a proper URI.

That said, it is sometimes worth a system restricting the URIs acceptable for some values to those in the http[s] scheme.

The challenge is how to offer extensibility by accepting other, as-yet-unknown URI schemes that support the key features of http[s] (e.g., dereferenceability, content negotiation, etc.) while unable to list those schemes.