User UID length

[Minas Mina]

I would like to know what is the maximum length for the user's UID.

This is because I will be storing it in a relational database, and I must specify a length.

I have seen through the console that generated IDs are 29 ASCII characters long.

• Is 29 a documented value that I can rely on? Can it change in the future?
• If the length might increase, what is a good value that I can use so that it will always be enough for the UID?

Thanks.

[Samuel Stern]

Hi Minas,

I would not rely on a constant length for the UIDs forever.  We chose the current value because it provides a big enough ID space while still being under the 36-character limit for Firebase Analytics user properties.

- Sam

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/ebb07f5b-48c4-45cd-a528-7f7ebedc690e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Minas Mina]

Thanks for your answer.
I will go for varchar(48) - I believe it will be sufficient for the next few (or more) years.

[Nikos Katsikanis]

It's convenient when doing conversations to concatenate both uid's together.

Then making security rule:

"conversations": {
"$conversationId": {
".read": "$conversationId.contains(auth.uid)",
".write": "$conversationId.contains(auth.uid)"
}
},

Is that future proof? ^

 Then you can easily retrieve the conversation for either user by splitting the string by 29. what would be a better way to do it?

We also pull out the uid when the conversation in created and store it in an index. 

export const conversationOnCreate = functions.database
.ref("conversations/{conversationId}")
.onCreate(async (snapshot, context) => {
try {
const {conversationId} = context.params.conversationId
const uid1 = conversationId.substring(0,29)
const uid2 = conversationId.substring(29,58)

[Kato Richardson]

Hello Nikos,

No, you can't rely on any undocumented implementation details of the API; we don't provide any guidance on length or format of uids.

A better approach, and also a good way to future-proof your code for schema changes, as well as making the data queryable and reportable, would be to list the chat members either in the conversation or a separate path like this.

☼, Kato

--

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/8ed46579-feb1-447d-8e72-acbb4bd88395n%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Nikos Katsikanis]

Nice one Kato, we also are thinking of doing end to end encryption with user message (key stored locally on each users computer), has anyone shared a pattern for that before?

[Nikos Katsikanis]

perfect thanks

On Friday, October 16, 2020 at 11:37:28 PM UTC+2 Kato Richardson wrote:

[Kato Richardson]

Everything but the client computer portion is already encrypted (data is encrypted at rest at the servers and in transit), if that helps. But I haven't seen any samples of doing the client-side encrypting; not even sure how valuable that is since access to the client could likely undo the encryption anyway.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e402401b-67e6-4ef7-abc0-665abb244c5bn%40googlegroups.com.

[Nikos Katsikanis]

For many applications in EU GDPR and medical data, its required to store customers data so that not even admins of the system can read, think whatsapp/telegram

[Kato Richardson]

That's not inherently built into Firebase nor are there any particular caveats to doing so. The normal encryption strategies should work here.

Note that we believe Firebase meets the requirements as a data processor per EU GDPR, so it's unclear why this would be necessary for that requirement. Healthcare is a different story and has all its own compliances.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/f26eed2a-c0c3-4c06-a339-b3254af21688n%40googlegroups.com.

[Nikos Katsikanis]

Well if I am hacked or make a mistake in the application, an intruder would only have access to encrypted data in firebase. the only way they could read would be to obtain users login credentials

[Nikos Katsikanis]

I was thinking , storing each conversations private key in local storage

the key would be shared with all users in a conversation and is only useful for that conversation

and i suppose the public key is stored with the conversation