No way to get user's UID

[varuntribe]

Hi, I am wondering if there is a way to get user's UID in V5 after getting the oauth token. We usually use it to make sure if user login with the same account, we do not connect their account twice. As username can be easily changed, we need something unique to recognise the user in our system. Any guidance here would be great. Thanks

[davidchaiken]

Thanks for the question! I'll get back to you with our thinking around UID...

[varuntribe]

Thanks for the prompt reply David. Looking forward to hear back on this.

[davidchaiken]

Hi, @varuntribe. I just realized that I answered a similar question in #issue #65...

Here's the scoop from Pinterest's API product and engineering leads... The lack of a unique id for users is an intentional difference between v3 and v5, and is part of the general direction of increasing the privacy of online services. As are many people in the industry, we're actively thinking about this area.

The best way to participate in this process would be to provide information about your use case on this feedback form. This kind of input helps us understand the interaction of privacy and developer productivity, and may help us improve our API.

If you decide to share information on the form, please post a comment on this GitHub issue so that I can ensure that the right folks have a look at your feedback.

[varuntribe]

Thanks David, I will reach out to your team using Feedback form as well.

Little context here - We are doing a piece of work on creator side for Pinterest and as part of that we need to connect creators Pinterest to our platform. Now with a lack of unique immutable identifier, it's challenging for us to identify Pinterest creators uniquely in our system. Let's take an example, user connects their Pinterest, and we use their username or email address as a unique identifier, now user goes to Pinterest profile and changes these details. As details have changed, now when user tries to reconnect their account in future for some reason, we have no way to know if this is a returning user or a new user.

Food for thoughts - I think team at Pinterest should consider having two UIDs, internal and external.

1. Internal IDs - This is ID you might have at the moment. Pinterest can keep it private and no need to expose it as part of any endpoint as this is used to identify users in your system and should be protected as part of your privacy policy.
2. Introducing External UID as part of V5 - This is only for external use, it has no purpose in your system, its only for your external partners who are utilising V5 APIs so they can uniquely identify Pinterest creators in their system.

In nutshell, we just need something that is immutable in nature so we can identify returning Pinterest creators and they don't lose their progress in our platform. I am happy to hear out any suggestion that your team have, that can solve this issue for us without having the external UID solution.

Also, a QQ, what's the lifespan left for V3 APIs and is it still getting the all the latest updates as V5?

[davidchaiken]

Great ideas, @varuntribe! I'll bring this idea to the appropriate team here at Pinterest, but this kind of architectural change tends to take a long time to work through the system. In the meantime, I'm wondering if you have a contact at Pinterest who is helping to manage the work that you're doing? If so, please ask them to reach out to me internally so that I can help connect the dots for your use case.

I don't think that we've published a timeline for V3 APIs yet. For now, we're busy ensuring that v5 has as much functionality as possible (subject to changes in the public discourse around privacy and making sure that the new API is well-designed).

[varuntribe]

@davidchaiken sounds good. We are preparing a doc with some questions that is about to go out to our contact at Pinterest. I will let them know to get in touch with you. Thank you so much for the assistance so far, we really appreciate it.

[davidchaiken]

Hi, @varuntribe. I've been noodling on an API-related idea for a long time and thought that I'd take this opportunity to ask what you think... Instead of Pinterest having a global external or internal ID, what if we allowed each application to store a small number of bytes that would be associated with one of our users? Only your app would be able to CRUD (create, read, update, delete) this data, rotating it as you see fit. You could use this data as a key to look up information about the user in your own data stores. Would this kind of feature address your use case? If so, what do you think is the smallest number of bytes that would be acceptable?

Note: I'm pretty sure that this feature is technically feasible, but have no idea whether it would make it through Pinterest's data governance process. For now, it's just an idea that I have and am wondering what feedback you (or anyone else reading this issue) might have.

[varuntribe]

Hi @davidchaiken , apologies for late reply here. This sounds promising but I have few questions -

• Is there a way we can make sure it will stay unique for each user?
• Where would it be persisted (Pinterest database or app's local database) in case of user uninstall and reinstall the app?
• Would it live only until user disconnects our app from Pinterest and what happens when they reconnect?

what do you think is the smallest number of bytes that would be acceptable? We don't have any limit on this, any number will be okay. As we support other social platforms as well, we have to keep this field flexible. I would say go with something that works for wider consumers of V5 APIs.

[davidchaiken]

Here are my thoughts. As before, I'm just brainstorming -- not committing to anything. :)

• I'm thinking that the bytes that you store would be opaque to Pinterest -- possibly even encrypted, if you want. You would therefore need to ensure that the data was unique for each user. Conceptually, you could store an encrypted version of your platform's user ID or some sort of user-specific token in this data.
• My idea is to persist the data in one of our "back end" storage systems, keyed by the user and your app ID. So, it would be technically feasible to persist across uninstall and reinstall of your app. Technically speaking, this data would only be available on API calls with an OAuth token that corresponds to the user and your app ID. I admit that I haven't yet worked out how this feature would interact with OAuth scopes, but have some ideas. In any case, storing the data in our systems is why I'm thinking about restricting this feature to a small number of bytes: the cost on our side has an upper bound of the number of users X the number of apps X the number of bytes per app X replication factor for back-up and service availability.
• There are different levels of connection and disconnection. My thinking is that the data would persist across multiple sessions (which include multiple "connections" and "disconnections" between a browser or mobile phone and Pinterest). However, I also think that it's important to give our users the ability to control this kind of data that is associated with their account. So, "disconnection" could also mean hitting the "Revoke Access" button in the "Security and logins" section of Pinterest's settings control panel. In the case when a user hits the "Revoke Access" button for your app, it seems to me that it would be appropriate to delete the data keyed by the user and your app ID.

Does all of that sound reasonable?

[davidchaiken]

I'm closing this issue for now, because we have an internal workstream going to figure out a solution. Folks at Pinterest understand this need, and we're discussing ideas like ^^ internally.

[varuntribe]

Hey @davidchaiken , apologies I lost track of this. That's good to hear. Meanwhile, we decided to use creator's Pinterest username as UID but would be great to have an actual identifier at some stage. I would appreciate if you can update this issue once the solution go live. Thanks for all the assistance so far, we greatly appreciate it.

[davidchaiken]

Will do, Varun. Thanks!