Telegram DM Rewards

[0x4007]

Perhaps its more convenient for a Telegram bot to message the rewards. This module can come with a registration command¹ and then direct message the reward link.

This could be more convenient to some users until we finish the database side and collect all the unclaimed rewards for the contributors.

Footnotes

1. /telegram pavlovcik ↩

[0x4007]

@Keyrxng so you think this would be easy? We can look for new comments posted and check if it's the rewards and forward it or something? Alternatively we can bake it inside of the rewards generation logic in some config.

[Keyrxng]

Perhaps its more convenient for a Telegram bot to message the rewards.

Yeah this is a great idea, it's easy to lose permits I think lmao.

so you think this would be easy?

It's easy if we are using Supabase, otherwise JSON storage implementation required. Since we're pushing for that I'll think in those terms.

Ideally we migrate the current userDB into a streamlined version so we can easily map telegram accounts to Github accounts.

Then we ensure it cannot be written to by anyone other than the bot.

---

It should be two-way like so:

GitHub Slash Command: /telegram keyrxng registers my Telegram account against my GitHub account
Telegram Slash Command: /github keyrxng registers my GitHub against my Telegram account

The commands would need a pseudo 2FA process like:

• attempts to register via GH /telegram keyrxng
• We gather GH user info and then we message that telegram account and have them perform an action with the bot to confirm ownership of that telegram account.

similarly

• attempts to register via TG /github keyrxng
• We gather TG user info and have them perform an action GitHub side, unsure what exactly.

Or we build an actual OAuth flow that allows login-with-github and /telegram keyrxng becomes a one-sided TG slash command with a different syntax.

We could do it without this 2FA I guess... JSON storage won't be required to have unique IDS etc so it's possible for a bad actor to insert entries that map to incorrect accounts. They can't do anything with the reward URLs anyway so it's not a real issue in that sense, but it's easy to bot TG (pun intended) and I could see our JSON storage being spammed to the point it's unusable or needs split across a few instances.

But I expect that we'll have other features down the line that would benefit from account validation so I'd build with that in mind.

---

Yeah there a few options I guess

• listen for the comment and extract usernames and map them to previously registered sets of GhUser:TgUser
• listen for workflows and read the outputs of conversation-rewards:compute.yml and we can build a summary of the permits generated, or output a file which we can parse.
• DM from the permit-generation package with a repo_dispatch and custom event like dm_telegram_permit and a flag. Then whichever plugins are using the package can have a config item dmRewards

[0x4007]

Honestly, I think just opting in on the Telegram side is sufficient. Lets just do that.

For example, I tell the bot to forward me all permits generated for @0x4007

Technically I can subscribe to get all @Keyrxng permits forwarded as well, it doesn't matter. I get no value from it so I won't. But who knows, maybe it could be useful to keep an eye on specific contributors.

[gentlementlegen]

I think this plugin can be made more generic to be able to register a telegram account and listen to multiple events, then forward that to the telegram account. We could have this as its own plugin, that could be added to plugin chains, which could allow any plugin to send their payloads and notifications, that would be forwarded.

Example:
/telegram register @mentlegen
/telegram subscribe "reward,unassign,reminder"

And then I would receive on telegram notifications when I get a reward, when I am un-assigned or when I get a reminder on some task.

[0x4007]

I think thats a really cool idea. Isn't that complicated to set up from an architecture standpoint? RFC @gentlementlegen @Keyrxng

[Keyrxng]

I think this plugin can be made more generic to be able to register a telegram account and listen to multiple events, then forward that to the telegram account.

So this is a GitHub-side pairing of accounts and we already have spoken about a Telegram sided pairing event, both right now are intended solely for personalised notifications.

Why don't we build a plugin which is just for these types of personalized/individual notifications, which can be extended to cover almost anything within reason.

1. We need a username mapping. Everything right now is still Supabase reliant but we are moving away from it? So we need a GitHub storage solution. We run a script exporting our SB users into something like this.

type UserStorage = {
   githubUsername: string; // redundancy against the occasional mismatch between login and name mentlegen knows
   githubId: number;
   telegramUsername: string;
   telegramId: number;
   wallet: string;
   notifyOn: {
     rewards: Optional<boolean>;
     reminders: Optional<boolean>;
     unassignment: Optional<boolean>;
     ...
}

2. We build a /register command into the telegram bot. Fetch via username, confirm it's the correct GH account, store both ID and Username (saves fetching it whenever needed) as well as store the details of the sender on TG. This "command" can look like anything, we can present tick boxes for each option and have guided steps or it can simply be /register keyrxng > confirm Keyrxng is the account > done /subscribe "manuallyListedEvents" > done.
3. The notifications plugin then simply runs on the events needed to support the conditions for messaging such as: unassigned we listen for issues.unassigned, check the payload for who got unassigned, do they exist in our storage and want notified?
4. Because we are handling direct messaging, I think we need to dispatch a workflow to telegram-bot and let the MTProto API deal with it I don't think bots can DM unless someone starts a chat with them but I'm not 100% sure on that.

Most we could probably do through comment parsing but it seems fragile since those change often, but with the comment metadata read/write standardized maybe this is a good approach for those that can support it?

All-in-all. We need storage first. Then a way to register (not tied to any specific plugin as a lot of telegram features need this info). Then for each intended notification, decide how to collect that event as typically we'll want the output of the plugin, not the event which starts it.

e.g reward, we'd need to either parse the workflow or parse the comments. We'd need to collect each reward, find out if they want notified then build the string to message for each, send the object to telegram-bot which for simplicity just receives {ghUser:message, ...} and it loops the object sending the string to the ghUser mapped to their telegramUsername.

---

We could add logic to be able to watch other user events but I think we should focus on just your own personalized notifications for now.

[0x4007]

Just opt on telegram side no auth needed don't need to make it more complicated than it needs to be.

You can set up your own Supabase and use it for storage. I imagine a plugin author can have a single Supabase instance with multiple tables for multiple plugins

[gentlementlegen]

I think that the plugin could have its own DB (doesn't matter supabase github wherever that can store data) and I think all it would need is to link a GitHub account with a telegram + events. The risk I see is that you could link any telegram handle so maybe we should add a verification somethow (imagine I register to all the events but I put your handle so you get spam for no reason).

[Keyrxng]

I imagine a plugin author can have a single Supabase instance with multiple tables for multiple plugins

Since we are going to be providing official plugins then does this apply to us also? Where we'd have a singular or multiple dedicated plugin DBs?

A lot of the telegram features are going to need to use this user mapping that we are creating so we should think in terms of it being accessible by more than just this plugin imo.

The risk I see is that you could link any telegram handle so maybe we should add a verification somethow (imagine I register to all the events but I put your handle so you get spam for no reason).

If we use the TG id as the primary then a user could receive any number of GH handle updates but they cannot be registered to receive spam like in your example. /register <github login> > we fetch and confirm the details > store. I'd like to confirm because mentlegen for example if you search by display name you get a different GH account.

[0x4007]

Where we'd have a singular or multiple dedicated plugin DBs?

When things are totally stable we can manage a migration to a "Ubiquity Official" Supabase instance. That is a much lower priority because it just slows down development vs developers having their own instances I think.

However, as I keep going on about, the optimal storage solution is git based. Then every developer has immediate access to the "database"

I'd like to confirm because mentlegen for example if you search by display name you get a different GH account.

Upon entering the slash command to the Telegram bot, consider doing a GitHub user id lookup and save that instead.

[Keyrxng]

@0x4007 Are you happy to close this?

[0x4007]

@0x4007 Are you happy to close this?

Why would we close this?

[Keyrxng]

I've built /register & /subscribe & people receive the claim url in their TG DMs.

1. Is this feature to replace the GitHub payout comment for said user completely?
2. What's missing for how things are now because I understand the feature to be built?

[0x4007]

1. No
2. Okay, you should link the relevant pull here.

[Keyrxng]

Resolved in ubiquity-os-marketplace/ubiquity-os-kernel-telegram#3