Add project subscribe button

[hojberg]

Add a new button to the project screens, allowing users to subscribe to notifications for that project.

Currently this uses an imagined API similar to that of fav'ing a project.

[netlify[bot]]

✅ Deploy Preview for unison-share-ui ready!

Name	Link
🔨 Latest commit	207ba3d1d3b8d757372df639db5f2db5043e369d
🔍 Latest deploy log	https://app.netlify.com/projects/unison-share-ui/deploys/684af571a3d39d00089ab3fd
😎 Deploy Preview	https://deploy-preview-80.staging.share.unison-lang.org
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 59 (🔴 down 11 from production) Accessibility: 93 (no change from production) Best Practices: 100 (🟢 up 8 from production) SEO: 75 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[ChrisPenner]

Hrmm, we probably should've synced up with each other before we each built our things; I may be able to map things back onto this model the backend doesn't currently work like this.

A project isn't guaranteed to have a single canonical subscription; for instance currently there's a notification subscription in Unison which listens for a contribution created event in ANY of unison's public projects;

I can certainly have the backend check if there's a subscription to the some topic-group which ALSO has a project filter for that project, but the system is more flexible than that; so I'm not sure it maps the most cleanly.

I guess that's a downside, having a more flexible system means it's not quite so clean in this situation.

Also worth noting, all the required APIs for managing subscriptions, notifications and delivery mechanisms all exist they're just relatively low-level.

E.g. to subscribe to contribution updates on a specific project right now you could do:

POST /users/unison/notifications/subscriptions

{
  "scope": "unison",
  "topics": ["project:contribution:created"],
  "filter": {"projectId": <project-id>}
}

But I can see how that's probably annoying for the frontend to construct.

I'll think on it a little, but let's sync up in our next Share meeting

[hojberg]

@ChrisPenner we had talked about this being based off of a topic group called "project activity" or something similar. This work is in anticipation of that. The details of what the actual payload is very minor for me to change, but definitely would prefer a group rather than managing individual topics on the frontend, which seems problematic as that set evolves over time.