Skip to content

Instantly share code, notes, and snippets.

@belisarius222
Last active Aug 24, 2020
Embed
What would you like to do?
hark: notification types
|%
:: $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)
--
@tacryt-socryp
Copy link

tacryt-socryp commented Aug 11, 2020

I think that we shouldn't use path here, as it's too general. Instead, I think we should use

$%  [%clay =beam]
    [%resource =resource]
==

The mop constructor is also in zuse now, so notifications should be a mop, not a tree.

@belisarius222
Copy link
Author

belisarius222 commented Aug 11, 2020

Updated the mop bit, thanks.

Just $resource doesn't let you link to a particular chat channel or chat message, though, just an application. A notification should provide enough information that you can jump to a particular chat message, calendar invite, etc. [resource path] might be enough, or $beam, which is intended for essentially this purpose.

I think this should be fully general, though, at least for now. This is a new feature, and we don't know exactly how we'll use it yet. It's easy enough to encode a beam, or a resource and path, or any other arrangement. I'd rather us discover a year from now that all uses of a notification stream use the same structure that fits into a more hard-coded type than discover that programmers are squeezing data into fields where it doesn't really belong, just to get it to fit into a type that isn't quite general enough. Consider how the "desk" field is sometimes used in scry paths; it's a bit of a hack, and there are plenty of worse examples of this failure mode in the wild.

@liam-fitzgerald
Copy link

liam-fitzgerald commented Aug 12, 2020

I think this should be fully general, though, at least for now. This is a new feature, and we don't know exactly how we'll use it yet. It's easy enough to encode a beam, or a resource and path, or any other arrangement. I'd rather us discover a year from now that all uses of a notification stream use the same structure that fits into a more hard-coded type than discover that programmers are squeezing data into fields where it doesn't really belong, just to get it to fit into a type that isn't quite general enough. Consider how the "desk" field is sometimes used in scry paths; it's a bit of a hack, and there are plenty of worse examples of this failure mode in the wild.

Agreed, but I think it would be nice to standardise on a beam format for referring to resources e.g.

(en-beam:resource %chat-store now [~dopzod %urbit-help])
> /~hastuc-dibtux/chat-store/~2020.08.11/resource/ship/~dopzod/urbit-help

Furthermore, it'd be nice to ape the scry paths as much as we possibly can. Would be kinda useful in FE

interface Notification {
  title: string;
  body: string;
  link: Beam;
}

type Notifiable = Message | PublishComment | LinksComment;

async getNotificationPreview(not: Notification) {
 
  const preview = await api.scry<Notifiable>(not.beam);
  return { title: not.title, body: not.body, preview };
}

@belisarius222
Copy link
Author

belisarius222 commented Aug 12, 2020

There's a somewhat deep problem with using a beam to point to a piece of static userspace data: you can't scry into an app at an old date. So there's no way to have a static scry request that's guaranteed to always resolve to the same piece of data.

The symptom of this issue that arises if we encode userspace links as beams is that it won't be bijective: we can't use the date in the scry request as part of a unique key. I think the best we could do would be to ignore the beam's date, and when constructing a beam, bunt the date.

That would be a little gross, so for now I think we might be better off coming up with a different path format for landscape data that looks more like /~zod/chat/foo-channel/message-num or /~zod/publish/bar-notebook/post-slug/comment-num. This is very similar to [resource path], just not hard-coded to exactly that.

@joemfb recently asked me to think more deeply about userspace scrying, which I'm doing. This is a salient example of the limitations of the current system.

@liam-fitzgerald
Copy link

liam-fitzgerald commented Aug 17, 2020

The symptom of this issue that arises if we encode userspace links as beams is that it won't be bijective: we can't use the date in the scry request as part of a unique key. I think the best we could do would be to ignore the beam's date, and when constructing a beam, bunt the date.
That would be a little gross, so for now I think we might be better off coming up with a different path format for landscape data that looks more like /~zod/chat/foo-channel/message-num or /~zod/publish/bar-notebook/post-slug/comment-num. This is very similar to [resource path], just not hard-coded to exactly that.

Imo this begs the question of why we'd be using beams at all. We're discarding the date and the ship is not overly useful, given that the actual host is probably encoded somewhere in the beam. Why not just a [app=term =path]?

@tacryt-socryp
Copy link

tacryt-socryp commented Aug 17, 2020

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

@liam-fitzgerald
Copy link

liam-fitzgerald commented Aug 17, 2020

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.

@matildepark
Copy link

matildepark commented Aug 24, 2020

Is there any way to mark these as read?

@belisarius222
Copy link
Author

belisarius222 commented Aug 24, 2020

@tacryt-socryp
Copy link

tacryt-socryp commented Aug 24, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment