Warning: These are just rough notes. We are in the early stages of our discussions with ops, so this will definitely change.

Description

different domain for profile server to scale it out differently
some kind of data storage (MySQL, but with generic key/value schema)
profile data will be key-wrapped
from an ops point of view, it's better to spend lots of CPU optimizing images at upload time then to serve unoptimized images

Things to avoid

don't want to be a CDN for images (to prevent abuse -- "persona profile filesystem")
we probably don't want to store arbitrary key-value store for users
planning on moving very quickly from labs to prod: it will take about a quarter to move once we say we're ready

What is the maximum amount of data that can be stored per user?
- TBC: depends on number of emails and max size for pictures
Are we storing arbitrary keys or are only well defined keys going to be allowed?
- No
How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?)
How are we handing back the data?

What does the API look like?
If we launch as an alpha service, how do we handle migration from alpha to beta to release?
- Not a problem as long as we consult with ops while designing the labs prototype.

Can other services be attached to this DB?
- Not for now (even though it looks like the schema might be similar to contacts)
What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production?
- 2012Q1 ;)
What is the data SLA? Where does data need to be backed up?

What happens when the profile server is down? Does BrowserID sign-in depend on it?
- You can still login but there's some kind fallback design/graphics for the "moocards".
Can we push image resizing / optimizing to the client?
- Not all of it (we'll probably be runing optipng/advpng/jpegoptim/pngcrush), but hopefully some of it.

Look at lloyd's scaling to 1M page and do something similar (assume everybody is uploading huge pictures we have to resize)
Talk to security folks, what needs to happen in what order?
Talk to David Ascher and user data group to find out about data collection implications.
- We need to discuss our plans on dev-identity to sollicit differing opinions
- Write up a document similar to https://da.etherpad.mozilla.org/kpi-backend
Find out max and average number of emails per user [petef]
Decide on a maximum image size [skinny]
Run the moocard idea past skinny [shane]