Closed madanalogy closed 5 months ago
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.
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
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
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
}
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?
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
@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