hark: notification types

hark.hoon

|%
::  $hark: general-purpose notification
::
::    Arguably .link should be a $beam, not a path, but $path is a bit
::    more general and can easily encode a beam.  The idea is that each
::    notification should be able to point to the part of the system
::    that generated it, so that if the user clicks the link, they will
::    be taken to the relevant part of an application.
::
::    The link could refer to just the application that generated the
::    notification, a Clay file that this notification is intended to
::    highlight (e.g. recently added), or a particular screen or
::    datastream within an application (e.g. a chat channel).
::
+$  hark
  $:  title=@t
      body=@t
      link=path
  ==
::  $notifications: ordered-map of $hark's
::
+$  notifications  (mop @da hark)
--

I agree with Liam, but prefer the even more specific [app=term rid=resource pax=path]

I agree with Liam, but prefer the even more specific [app=term rid=resource pax=path]

I prefer [app=term =path] because it doesn't make assumptions about the structure of an apps state. Additionally, it allows us to scry for these resources without doing path mangling on the frontend.

Is there any way to mark these as read?

Hmm, no. Good point. We could add that state per-item as a boolean flag or a (unit @da) noting when it was viewed. Alternatively, we could keep each notification as an immutable data structure and separate the "viewed" state into some other data structure. I think we should try to replicate the pattern used in graph-store for marking items as read in other parts of the system. ~tacryt can correct me, but if I recall, the view app stores the set of items that have been read. — ~rovnys-ricfer https://urbit.org

…

On Mon, Aug 24 2020 at 11:13 AM, matildepark < ***@***.*** > wrote: ***@***.**** commented on this gist. Is there any way to mark these as read? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub ( https://gist.github.com/7c36c61ed7455c5056ef114daa062d1f#gistcomment-3429140 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAGVR5P2LS46637ZT2EZIX3SCJ7SXANCNFSM4P3KXXOQ ).

The view app does not store any state in graph-store. I think we should mirror the archiving pattern in graph-store and move them out of the unread list upon having been viewed. This way the “unread number” is always calculated based on the length of the unread message list.