Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct notifications from apps to omi with mentor example #1560

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

tiagoefreitas
Copy link

@tiagoefreitas tiagoefreitas commented Dec 19, 2024

Implements #1434

The example in the mentor app sends a reminder to the user 1 minute after the last mentor notification saying "Hey! How's it going with my previous suggestion? Have you had a chance to try it out?".

This could be improved further by merging PR #1440 , that way the app could save the last notification sent and create a personalized message reminding the user about the previous suggestion and asking how its going.

For authentication:
We send the app if to the app transcriptions webhook, the app should save the id.

When the apps call the /notification webhook on the omi api, they need to provide the app base url (same as configure in the webhook) as the http referrer.
And they need to send the uid and the aid (app id).
If the app is not installed on that user or the url doesn't match, the request fails.

We could implement more robust api key authentication, but it would make it more complex for the developers, and this is secure now because only the app can receive the app id from the backend. Effectively the app id serves as api key, that can be revoked by just uninstalling the app.

@tiagoefreitas
Copy link
Author

tiagoefreitas commented Dec 19, 2024

One improvement that can be made is making an Omi SDK for the backend, currently there is one implemented as class FriendClient in plugins/example/zapier/client.py but it should be moved to /plugins and renamed to OmiClient or OmiSDK so apps can use all available backend functions, and add more like getting user facts etc.

Also the auth needs to be implemented like I did in this PR, the current FriendClient SDK for Zapier uses a hardcoded WORKFLOW_API_KEY in the backed, so it cannot be used by app developers like I did in this PR.

I suggest a bounty to make a proper Omi SDK for a wider backed API, using my auth method or an API key generator.

@mdmohsin7
Copy link
Collaborator

Hi @tiagoefreitas, can we pls have your notification logic as a completely different endpoint and function instead of mixing it in send_notification_to_user. Current endpoint is being used in our admin dashboard for specific communications to the user. I guess keeping both separate will make more sense and also easy to understand

@tiagoefreitas
Copy link
Author

@mdmohsin7 I moved it to /v1//integrations/notifications because integrations has other public apis used by the zapier app.
I still think we should create an Omi SDK for apps to use instead of calling the endpoints directly so that we can handle auth in the SDK and change it later if needed, and make it easier for app developers to see all available public APIs they can use.

@kodjima33 if you want me to do the SDK, please create a separate issue

Also should I add the ability to use prompt templates in the direct notifications? Right now it only supports direct messages, which gives more control to devs, but prompts with the args may be easier for simpler apps.

@tiagoefreitas
Copy link
Author

@mdmohsin7 @kodjima33 congrats on the new launch I get you are busy, can you review this PR and let me know?
Also this was a request from @kodjima33 with a bounty, waiting for a reply on that.

@tiagoefreitas
Copy link
Author

@kodjima33 any news on this? thanks

@beastoin
Copy link
Collaborator

man, @tiagoefreitas , you can do it better, please take a look:

1/ app_id is not strong enough for the authentication. suggest the new term: app's secret. we need to let dev create/revoke their app's secret from omi app.

2/ did you implement the rate limit for POST /v1/integrations/notification ? sry i can not see that piece of code, feel free to lmk.

/ draft

@beastoin beastoin marked this pull request as draft February 12, 2025 08:36
@tiagoefreitas
Copy link
Author

@beastoin ok will implement that this week

@tiagoefreitas
Copy link
Author

@beastoin I implemented your suggestions and tested, can you review? thanks

@tiagoefreitas tiagoefreitas marked this pull request as ready for review February 22, 2025 17:06
@beastoin
Copy link
Collaborator

beastoin commented Mar 3, 2025

Cool man / @tiagoefreitas

1/ the back-end should not store the apps secret key, {hashed + label) is the way. could you improve it ?
2/ we didn't need burst yet, keep it simple.
3/ could you share a demo video ?

@tiagoefreitas
Copy link
Author

tiagoefreitas commented Mar 3, 2025

@beastoin by label you mean support for multiple keys with user label? one key should be enough because its per app.
if single key, why is label needed?

ok will remove burst protection. it was meant to prevent developers from sending too many notifications to users, not for security.

will make the demo video after these clarifications

@beastoin
Copy link
Collaborator

beastoin commented Mar 4, 2025

1/ label - sk-...NlQA, 1-1 for now. the why? developers can have multiple apps and key's label will help them take the action without further concerns.

looking forward for the demo.

@tiagoefreitas

@tiagoefreitas
Copy link
Author

tiagoefreitas commented Mar 4, 2025 via email

@beastoin
Copy link
Collaborator

beastoin commented Mar 5, 2025

ok but the key shows inside the app config. should the label be set by the user or just the app name? currently I create the key when the app is created if it has notifications and can be revoked, but if we have manual label will have to be created manually

On Tue, 4 Mar 2025 at 02:29, Thinh @.> wrote: 1/ label - sk-...NlQA, 1-1 for now. the why? developers can have multiple apps and key's label will help them take the action without further concerns. looking forward for the demo. @tiagoefreitas https://github.com/tiagoefreitas — Reply to this email directly, view it on GitHub <#1560 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXJNRVBHYYQJEIY5MR7HW32SUFYFAVCNFSM6AAAAABT5RDFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGAYTSNZYGQ . You are receiving this because you were mentioned.Message ID: @.> [image: beastoin]beastoin left a comment (BasedHardware/omi#1560) <#1560 (comment)> 1/ label - sk-...NlQA, 1-1 for now. the why? developers can have multiple apps and key's label will help them take the action without further concerns. looking forward for the demo. @tiagoefreitas https://github.com/tiagoefreitas — Reply to this email directly, view it on GitHub <#1560 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXJNRVBHYYQJEIY5MR7HW32SUFYFAVCNFSM6AAAAABT5RDFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGAYTSNZYGQ . You are receiving this because you were mentioned.Message ID: @.***>

showing sk-...NlQA is good enough, create the label automatically.

@tiagoefreitas
Copy link
Author

@beastoin
Copy link
Collaborator

beastoin commented Mar 9, 2025

1/ man, i have a gift for you, the apps api key(multiple keys) is ready on the main https://github.com/BasedHardware/omi/blob/main/backend/routers/apps.py#L822-L874 , please re-base your code with the main; you could also use this for your ticket / related doc https://docs.omi.me/docs/developer/apps/IntegrationActions

2/ ok

3/ ok

looking forward to your changes. lets get this ticket done asap.

@tiagoefreitas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants