Figure out what the checker ID (phoneNo in frontend) is in new setup. Should it be Telegram ID or an actual phone number? How to get the phone number?

[madanalogy]

@bwsarge @sarge1989 what is the motivation behind needing a phone number? If the purpose is for user verification, we could build in an OTP flow as part of the onboarding. Telegram doesn't provide user phone number so we will need to get that ourselves if necessary https://core.telegram.org/bots/webapps#webappinitdata

Schema wise, it might be more future proof to use our own internal unique id to represent a checker. This method of identity management would make it more flexible for users to update their details such as phone number or if they change telegram IDs in future. Let me know what you think as well @TY0018 @lowzk

[sarge1989]

Agree to use internal unique ID or the SGID OpenID to represent a checker, which I guess makes sense if we want to onboard everyone using Singpass / SGID.

I felt one benefit of getting their phone number is that we could allow checkers to switch between whatsapp/telegram if they wanted. It also provides a method of identity linking for stuff like surveys/forms. Was actually thinking of using whatsapp to send OTP (I can work on this part) if we do an OTP flow.

[madanalogy]

Okay sounds good let's go with our own internal id. This can be associated with a checker's phone number or openId. Helps to make the backend data schema more easily adaptable to possible future changes

[madanalogy]

I'll work on the data schema migration fyi @btjl in case it clashes with your onboarding migration work in #226

EDIT: Actually maybe I'll wait for the onboarding migration to finish first, since it might change the flow. Will work on other bugs in the meantime

[sarge1989]

Am proposing this new schema:

factChecker {
    string id PK "unique ID, assigned by firestore"
    string type "human or ai"
    string name
    boolean isActive
    boolean isOnboardingComplete
    string singpassOpenId "Singpass Open ID"
    string telegramId "telegram ID"
    string whatsappId "whatsapp phone number"
    number level "Not used for now"
    number experience "Not used for now"
    number numVoted
    number numCorrectVotes "Not used for now"
    number numVerifiedLinks "Not used for now"
    string preferredPlatform "whatsapp/telegram/null, only whatsapp used for now" [Should all be telegram after change, null for AI checkers]
    string getNameMessageId "ID of the message sent to prompt factChecker for their name. Used to track reply." [Can Remove with new onboarding]
    timestamp lastVotedTimestamp
}

• Reason is, we wanna implement gen-ai factcheckers also (so added a type field)
• We can authenticate them using telegramId field instead of id field.

[btjl]

Agree to have a type to discern A.I and Humans! 😎🤖

In that case what are your thoughts on type field as isHuman: Boolean

Can I also check what is the purpose of preferredPlatform field?

[sarge1989]

for type, thought to keep it flexible in case in future we have diff types of AI checkers (or even human checkers)

preferredPlatform more to capture whether checkers wld wanna do the fact checking on Tele or WhatsApp. Parts of the app already check for this actually. Rn, we don't intend to support both, so this field isn't very important. But just thinking that we might wanna support both in future