-
Notifications
You must be signed in to change notification settings - Fork 322
Identify Portal Participants #40
Comments
I really love your organized mind. |
#87 accomplishes most of what we outlined in the issue body above. 🤘 @as-cii @nathansobo: Do you think we should pursue the remaining items, or would you want to hold off on those items until we implement something like the buddy list UI we've been discussing? |
I think we may as well finish the notifications and ensure our error handling is good before proceeding. |
I think we already show an error when something goes wrong when authenticating. As for notifications, the only one we haven't implemented is:
It should be pretty straightforward to add, but I am not sure we need it since guest users knows who they are connecting to. I am open to adding it, but I think we should go ahead and staff-ship what we have currently. Thoughts? 💭 |
We discussed this on our planning call today and agreed that we should skip this ☝️ for now. With that in mind, I'm gonna close this issue. |
For the very first step on the road to authentication and presence [1] [2], we'll enhance the package to identify all participants in the portal.
Behavior
This initial staff-ship will provide the following behavior:
<guest-username>
has joined your portal" [3] (Authentication #87)<host-username>
" [3]<guest-username>
has joined the portal" [3]TODO
This is a partial task list, largely intended to help me keep track of things going on across various repositories 😄. We'll know that everything is actually done when the package provides the behavior described above. ☝️
End-to-end happy path with real-time package reading OAuth token from env var[1] Portals roadmap
[2] Buddy list exploration
[3] We'll likely tweak the copy before shipping ✨
The text was updated successfully, but these errors were encountered: