-
-
Save belisarius222/7c36c61ed7455c5056ef114daa062d1f to your computer and use it in GitHub Desktop.
| |% | |
| :: $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) | |
| -- |
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.
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-helpFurthermore, 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 };
}
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.
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-numor/~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]?
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?
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.
I think that we shouldn't use path here, as it's too general. Instead, I think we should use
The
mopconstructor is also in zuse now, so notifications should be a mop, not a tree.