Room Persistence

Mixed Reality Hubs
#1

I wanted to create a thread to discuss concepts and implementation ideas around room persistence. Currently, if/when your client disconnects, you lose all objects you’ve spawned in the room. Up until now, this hasn’t been very consequential since you’re losing some ducks :slight_smile: But now there will be a variety of scenarios where spawning useful, unique objects are possible, such as photos, videos, models, sounds, and drawings, and so it seems desirable to form a point of view around room state persistence in Hubs.

We have two competing things that we need to balance:

  • The more persistence we have of room state, the less likely it is that someone’s creative work will be lost, and the wider utility of the creative work they put into a room. For example, if I create a simple art gallery in Hubs by spawning images, the general utility of this goes up a lot as it becomes persistent and shareable with others through time.

  • Introducing persistence reduces the ephemeral nature of the interactions in Hubs. This has a variety of potential pitfalls: it could undermine the perception of Hubs primarily as a communications tool (vs a worldbuilding tool or metaverse), introducing privacy risks (for example, personal photos may need to be stored on our servers), or could turn interactions in Hubs to feeling more “high stakes”, which could result in less fluid, natural communication between people in a room.

It’s important we’re careful about how persistence is introduced, so its done in a way to balance these two concerns. The ideal scenario is one where we introduce persistence in natural, unsurprising ways that increase the value of room state and reduce loss of valuable data, while not confusing users, inadvertently violating their privacy, or changing the low-stakes nature of how it feels to communicate in Hubs.

Here are some of the questions we’ll need to answer for a given proposal:

  • What state is persisted?
  • What are the benefits of persisting that state? What use-cases does it enable? What problems does it solve?
  • What are the use-cases that are not solved by this? What problems does this potentially introduce?
  • Where is that state stored?
  • How and when is that state made available to others?
  • What level of access do we, the hosting provider, have to that state?
  • How and when is that state removed?
  • How future-proofed is this solution?
  • How durable is this state? What guarantees around durability can we give users?
  • What effect does this have on user experience?
  • What is the mental model we expect users to have around this state?
  • What effect does this have on privacy?
  • What are potential abuse vectors?
  • What resource limitations are relevant for storing this state?
  • What effect does this have on content rights? (IP, copyright, attribution, etc.)
#2

"Creator co-presence as key" (CCK) model:

In this model, objects that someone spawns in a room are permanently available, stored remotely, but only exist when that person is in the room. Ownership transfer doesn’t alter who these objects are bound to: it is the creator who matters. Since we don’t have accounts, this means “if I create an object in a room on device X, if I join the room in the future on device X or any device that is connected to device X via linking, those objects become visible again.” It is dependent upon local storage keys for unlocking this state, so if using a private tab or cookies are cleared, access will be lost.

  • What state is persisted?

All spawned entities (other than avatar) and uploaded files required to support those entities.

  • What are the benefits of persisting that state? What use-cases does it enable? What problems does it solve?

This makes it so as long as I retain at least one copy of my local storage keys, things I create in Hubs won’t be lost. This makes it so if I disconnect incidentally, it won’t go away. I can also lay out some objects in a space by myself, leave, and later share the link to show someone what I’ve done, as long as I join them in the room. It is also a seemingly consistent model that can be applied across various contexts (uploaded files, entity state, etc) and is fairly intuitive and privacy preserving since co-presence in the room is one-to-one with full cognitive awareness that your content is being made available to others.

  • What are the use-cases that are not solved by this? What problems does this potentially introduce?

In spaces where there is any kind of collaborative object spawning, full re-creation of that state will require all participants to re-join. In spaces where there is some kind of shared content that should be “room owned” (like a video everyone is watching), it is somewhat problematic that if the creator of that object leaves or drops out the video goes away (however, if they rejoin, it will pick up where it left off.)

It also can be a bit unintuitive in certain cases who is the creator of an object if that object transfers ownership throughout the session. (For example, I may spawn an object for someone else to use, if it’s just easier for me to do the spawning, but in practice that other user is the one who does the actual creative work on the object.)

Finally, this locks this state to a specific room. If I want to re-use creative work I’ve done in room A and bring it to room B, I’m unable to do so. (For example, I want to take an art gallery I’ve put together and make a new room with the same objects, to make it easier to share with a new group of people or to change it for a new purpose.)

(Edit: This point above is actually not true, we could build mechanisms to let you create a copy of a room that you’re in, and all the objects you’ve spawned, obviously.)

  • Where is that state stored?

The state would be stored on our servers, encrypted in a way to prevent access unless that person is connected to the system.

  • How and when is that state made available to others?

When a person joins a room, all the relevant objects they had created in previous sessions will spawn.

  • What level of access do we, the hosting provider, have to that state?

We will only have access to this state when the user is connected, and when those keys are not available in memory to the server they will effective lock out access to the state from everyone but the creator. The keys to decrypt the state will be privately shared with the server while that person is connected.

  • How and when is that state removed?

The state will be removed when the user deletes the objects from the space, and potentially will expire on some long TTL.

  • How future-proofed is this solution?

Entity state storage will require some formal schema to ensure future proofing. (Perhaps this should be stored as GLTF under our scene schema.)

  • How durable is this state? What guarantees around durability can we give users?

This will be highly durable state since it will be server side storage. However, it can be “lost” if the user ends up clearing their cookies from all the relevant devices they’ve used from Hubs.

  • What effect does this have on user experience?

The “stakes” factor should remain the same since the user never leaves anything “behind” in the room, it goes with them. However, users will likely start to see Hubs as at least in part a creative tool since they can create and “carry” sets of objects with them across sessions to show others.

  • What is the mental model we expect users to have around this state?

“I take the objects I create with me when I leave, and bring them back when I re-join that room.”

  • What effect does this have on privacy?

Private information is potentially exposed to other users when the creator is co-present. Beyond that, information is sealed off, provided we do not have any mechanism in our servers or logging which would store the shared key. However, If someone creates and object, but another user imparts some kind of private information onto that object, that private information is under the control of the object creator, not the person who imparted it. (For example, if someone spawns a couple of line drawings and then I re-position them to spell out some private information, that information will be stored with the creator’s key not me.)

  • What are potential abuse vectors?

Any vector which tricks a person to impart state an object that was created by someone else could potentially allow the creator to have permanent access to that state.

Since this will result in hosted storage, there are abuse vectors around excessive use of that storage for bad/illegal purposes, like copyrighted file hosting, etc.

  • What resource limitations are relevant for storing this state?

We’ll be storing all state so it will require we have some kind of limits or expiration policy. (Or perhaps paid hosting plans.)

  • What effect does this have on content rights? (IP, copyright, attribution, etc.)

We’ll have to have DMCA takedown channels and proper attribution for spawned content.

#3

Room Snapshot Model (RS)

In this model, any participant in the room has the ability to take a “snapshot” of the room. This snapshot captures the entire state necessary to re-create the relevant objects (besides avatars) at a later time or in a different room. The snapshot can be stored in a variety of ways: server-side, as a local file, in local storage, or remoteStorage.io. Snapshots may be available as first-order objects in the UI for restoration.

  • What state is persisted?

All entity state and durable links to necessary content to those entities.

  • What are the benefits of persisting that state? What use-cases does it enable? What problems does it solve?

This allows the creation of point-in-time snapshots of a room, regardless of context about who created, owns, or manipulated what objects. This is an extremely versatile way to re-create the state of a room at a later time.

  • What are the use-cases that are not solved by this? What problems does this potentially introduce?

When a snapshot is “restored” by a user, they will re-spawn all the objects in a room. So, those objects will disappear when that user leaves (though they can be re-spawned from another snapshot from anyone, including that user.) So this does not solve use cases where there are “room owned” objects like shared video screens, etc, that should exist regardless of who is in the room.

A major concern with this model is one around privacy: taking a snapshot lets you grab everything in the room, regardless of who created it. So, if someone has imparted some kind of private information into the room state, that will be captured in the snapshot.

  • Where is that state stored?

The snapshots may be stored either locally or remotely. If locally, likely as files you download due to their size.

  • How and when is that state made available to others?

Snapshots are explicitly restored by a participant, and that person re-creates all the objects in the room.

  • What level of access do we, the hosting provider, have to that state?

If stored locally, we have no access. If stored on our servers, we could encrypt things so we would not have access unless the user who created the snapshot is connected and shares the key to unlock the data.

  • How and when is that state removed?

If stored locally the user would be responsible for the data. If hosted, we would likely have a way to delete snapshots and also would have a retention policy around them.

  • How future-proofed is this solution?

Entity state storage will require some formal schema to ensure future proofing. (Perhaps this should be stored as GLTF under our scene schema.) Most likely we would export all content, including hosted images, etc, so this is particularly future-proofed since the entire state is snapshotted.

  • How durable is this state? What guarantees around durability can we give users?

Snapshots could be made highly durable if hosted, if locally stored then its dependent upon the user’s management of the files.

  • What effect does this have on user experience?

Users co-present in a room would need to internalize that anyone in the room could replicate what they’ve created at any time, for better or worse.

  • What is the mental model we expect users to have around this state?

“A room I’m in can be snapshotted by anyone, and restored by anyone”

  • What effect does this have on privacy?

Users who post private information or content would effectively be granting others full access to that data to do as they see fit.

  • What are potential abuse vectors?

Since this would facilitate an easy way to capture data from others in the room, there are a variety of ways an abuser could try to get someone in the room to share something they didn’t realize was going to be saved by the attacker.

  • What resource limitations are relevant for storing this state?

If locally stored, we’d have to use files instead of local storage if we want the snapshot to include uploaded content or copies of 3rd party URLs. If hosted, We’ll be storing all state so it will require we have some kind of limits or expiration policy. (Or perhaps paid hosting plans.)

  • What effect does this have on content rights? (IP, copyright, attribution, etc.)

Any content in the room can be saved and copied at any time, so including attribution metadata so that when snapshots are restored it can be made clear who created and owns the original content seems important

#4

"Room creator as key" (RCK) model

In this model, the user who created the room has a special role – when they are present, the room state is mutable, and the room creator is the only one who has the ability to introduce persistence of it over time. When the room creator is not present, it is not possible to spawn or manipulate objects. The room creator both automatically restores room state when they join, and also can snapshot the room and create copies of it into new rooms.

This model is kind of a hybrid of CCK and RS above – the privacy concerns of RS are still present but only wrt the trust of participants with the room creator. Beyond that, the room creator is the key that “unlocks” content in the room. I’ll write out the answers to the questions if anyone thinks this is a good model to explore further :slight_smile:

#5

"Opt-in Pinned Objects" (ORO) model

In this model, objects are by-default ephemeral, but users can opt-in to have them become “pinned” (terminology may change), which makes them persistent across sessions for everyone in the room. Once an object is pinned, its state and content is persisted on our servers regardless of who created it or manipulated it. It also should be easy to “copy” a room to another room, which will take all of the pinned objects in that room and bring them into the newly created room.

  • What state is persisted?

On an object-by-object basis, entities state will be stored on the server. This state will be unencrypted since anyone who comes into the room will be able to see it.

  • What are the benefits of persisting that state? What use-cases does it enable? What problems does it solve?

This makes it possible to “leave behind” objects in a room that have been created by participants. This solves cases like “a shared movie screen” that should be in the room no matter who is there, and also allows single-user or collaborative-user laid out objects to persist and be shared across sessions.

A model like this one (or the APO model below) are unique in that there is no reliance upon the presence of a specific person to create the prior state of a room. This obviously is potentially a huge deal for certain use-cases. For example, I could create a “museum” of content in a room and it will exist “forever” at that link, regardless of if I am there. Under these models, room state becomes much more universally shareable since it is decoupled from the original creators of that state.

  • What are the use-cases that are not solved by this? What problems does this potentially introduce?

This model introduces a significant amount of complexity in the mental model for users: objects can be in one of two states (ephemeral or persistent), and there will be controls needed to opt-in or opt-out easily both for individual objects and for a series of objects. (For example, we probably don’t want you to have to opt-in for each object you spawn because you may inadvertently forget and lose state you intended to persist.)

  • Where is that state stored?

This would be stored server-side, unencrypted.

  • How and when is that state made available to others?

Room state is shared with someone when they join the room.

  • What level of access do we, the hosting provider, have to that state?

We would have full access to it.

  • How and when is that state removed?

We could have an expiration policy. Also, we could allow anyone in the room to remove these objects.

  • How future-proofed is this solution?

Entity state storage will require some formal schema to ensure future proofing. (Perhaps this should be stored as GLTF under our scene schema.)

  • How durable is this state? What guarantees around durability can we give users?

We can make this state highly durable.

  • What effect does this have on user experience?

Users will need to understand that some objects are ephemeral and some are not. Making objects permanent is an action that is explicit, so users should be able to understand that they are exposing that information across sessions when doing so.

  • What is the mental model we expect users to have around this state?

“Objects I create can be ‘pinned’ to a room so they stick around if I leave. I can pin individual objects or make all objects I create pinned.”

  • What effect does this have on privacy?

If a user does not understand that when they make an object room-owned it is stored on the server, they could leave behind personal information they didn’t intend. Also, since this data would necessarily need to be unencrypted to support the case of anyone entering the room, this data would be sitting on our servers and would be accessible to us and anyone who managed to access our servers.

  • What are potential abuse vectors?

Attackers could get users to pin objects they did not intend to. Pinned objects can also be used as a way to cheaply “host” content, so we would have to have some kind of limits. This model is fairly unique in the fact that there’s no “owner” of the state, so no way to lock it down from access if someone manages to access our servers.

  • What resource limitations are relevant for storing this state?

This could become a significant amount of resource usage if we are storing the original assets for pinned objects,

  • What effect does this have on content rights? (IP, copyright, attribution, etc.)

Same as above wrt hosted content, etc.

#6

"Always Pinned Objects" (APO) model

Similar model above, but where objects are always implicitly persistent and pinned, and must be manually deleted to be removed from room state. A variant of this would be one where objects are pinned by default but can become un-pinned so they are removed on disconnect.

We probably won’t do this because this makes Hubs very “high-stakes”, but I can write answers to the questions if we decide this is a good idea.

#7

(comments to the above in this message; alternative ideas in another)

In the first message you said:

Introducing persistence reduces the ephemeral nature of the interactions in Hubs

This feels to me like a critical point, and hard to get around. As soon as you introduce persistence on our servers we open up to a lot of “why can’t I do this?” “can’t you enhance it a bit to do that?”

I will say up front that, after reading all the above, I am strongly biased against of hosting / storing any persistent data. It seems like it should be possible to require that every piece of content that is added to a room have a URL that is accessible to all participants, and that (therefore) the hosting by us of content isn’t required.

If people want to use hubs to host data that is private, they just need to use URLs that they all have access to (e.g., on an intranet). Perhaps we can detect when content needs a password (because the server asks) and prompt for those id/passwords? So, I could put all the content in a pw protected place, and give my friends the pw, and we could each authenticate directly.

That said, here’s my thoughts on these.

"Creator co-presence as key" (CCK) model

This seems like it would be hard to understand, and be frustrating. “Why can’t I just mark things as being there when I’m not?” If I looked at that I would think this was weird. The automated nature of this (it’s gone when I’m gone, back when I return) just feels odd to me.

Snapshot Model (RS)

My one question here is “Why make the links durable?” Why not a snapshot that just uses the links that were used during creation? While this raises the likelihood of broken links, it also gives the people sharing the content a measure of responsibility and control: I can put a file in dropbox or on github, and then use the URL, and if I no longer want it to be there, I delete the file and the URL becomes invalid. This is a feature not a bug.

I also very much like the idea of the snapshots being stored locally (or in a 3rd party repository like APainter does), not on our servers.

And, finally, I like the idea that these snapshots would be stored in a format that would allow them to become the starting point for a room (e.g., I can append ?state=url or whatever to a hubs URL and it will preload that content as the base room, for everyone, without it being duplicated or respawned or “owned” by anyone)

Users would be responsible for putting the “saved state files” somewhere accessible. Since the original URLs are used for content, on the state file matters?

"Room creator as key" (RCK) model

Meh. :slight_smile:

"Opt-in Pinned Objects" (ORO) model

Again from above: why not have this model without us saving the content? Just “pin” the URL links?

"Always Pinned Objects" (APO) model

I agree this is a bad idea.

#8

This all seems very complicated. Why not something simpler like:

"External room description file with controlled save" (FILE) model

Each hubs room has a “startup” file that is loaded from a URL, that loads a bunch of state. This may be in addition to the “base” room model, or more likely needs to specify what the initial room model is that this room was using (since content is relative to it). The creator of the room has the rights to set or change this URL.

These files can be generated by hitting “save” from a hubs room, which pops up a dialog listing all the current content elements in the room. You check / uncheck the ones you want in the save file.

The file is saved to uploadcare or similar, and you are given a URL. You are free to leave the file there, or download and save it somewhere else.

Content files (images, models, videos, etc) are not copied; the URLs are saved. If those originals go away, the content is gone. We may want to be able to see/edit the URL of items in a room (e.g., I want to move a picture, so I edit the url in the room instead of having to drop and reposition it … or, I have a edit mode where I can just drop a new URL on a thing, and it just replaces it without losing the position/orientation/scale).

This imposes some work onto users (they have to manage/persist content) but feels much more in line with hubs long term trajectory. And it means things can be shared, or even edited by hand to fix/merge/change them, OR even have them generated on the fly (I specify the “content” URL to point at a service I host myself).

I don’t mind losing the guarantee that content persists (i.e., if the files move, the content links break) since that feels like the nature of the web to me: I put all my “Blair” pictures in a room, and then change my mind, I can just remove the source files and the saved snapshots break. Or I can update the pictures and they get updated in the snapshots. This is “kinda the way the web works”.

#9

Yup, this sounds like the snapshot model, no?

I think the privacy concerns are valid in the variant you mention of the snapshot model: even if you are saving URLs, you are saving links to potentially uploaded files like photos. So it may be surprising to people that if they spawn a photo of their kid by uploading the file to us, that someone in the room can create a copy of the room with the same photo easily. By changing this dynamic, the “feel” of Hubs may become more “high stakes” since you know others can “take copies” of the content you spawn.

Other models, like “co-presence as key”, make this kind of thing something someone would have to go out of their way (write a custom client, etc) to be able to do.

#10

Sorry missed your earlier reply, I’m a discourse noob.

I think the use-case that cuts across everything you mention is the one where users upload content to us to spawn in the room. My expectation is that this is going to be a major use case for Hubs. For example, I am in a room on my Oculus Go, and want to quickly spawn 3 or 4 photos off of my phone. Or I have my slides as a PDF on my computer, and I want to show them in the room. Or someone writes a blender plugin, and I’m riffing on a model by hitting the “update in Hubs” button. For these cases the easiest thing for a user is going to be to upload them in the same place they go to paste URLs, as an alternative way to add content to the room. The alternative, where they have to track down a hosting provider in each case, adds a lot of friction – probably enough friction that your average person just won’t be able to do the thing they want (show everyone a photo on their phone, etc.) So we’ll need a sane story about how this data is stored, retained, encrypted, etc – ideally one that aligns with our overall story around entity persistence. Or, we can just not do it (as I think it sounds like you’d prefer :)) but I think we’d be leaving a lot of utility on the table for users – especially because I think we can do it in a privacy preserving way. (Encrypted at rest, expiring after a short TTL, etc.)

The snapshot model I wrote above doesn’t prescribe specifically if we include the source assets as part of the snapshot (though I alluded to the fact this might be best) – we could just burn in URLs, but we’d still need a story around the way those URLs expire if they point to uploaded content. The nice thing about the CCK model is that it applies a universal model to both uploaded files and spawned objects: you hold the key to the stuff you upload, and nobody (not even us) can read it unless you share it with us. If we go with the snapshot model, I could imagine one where you get the full original assets for the objects you spawned and uploaded yourself, and the remainder are URLs. This way you don’t end up having to worry about your content “disappearing” if you restore the snapshot, but we don’t end up including 3rd party content in snapshots. I’m assuming that our TTL on uploaded files will be very aggressive (hours or days, not weeks or months) so broken links for uploaded content to Hubs will be “by design” for long lived references.

#11

Oh one more thing worth mentioning – people are going to be able to draw and sculpt stuff strictly as game entities in Hubs, without any URLs being involved. So even if we decide that URLs are the way to reference external content like images and models, our persistence method still includes the stuff you “make” while in Hubs. So that data would need to live somewhere, either being burned into the snapshots as raw serialized objects or hosted on our servers.

#12

In that case, also a way to export them in the future?

#13

I feel like anything that is uploaded is game for folks to copy using web tools; so nothing is “private” to anyone in the room.

I think it’s easy to explain “if you drop a URL in here, anyone in the room can save a copy of the URL or a copy of the room” but all the other stuff seems harder.

#14

Perhaps – that’s basically what we need to figure out. Exporting someone else’s work could be problematic, the various models above highlight the tradeoffs in how and where we allow long-term persistence of room state.

#15

I think it comes down to design questions and what our design encourages. Indeed, everything on the web is inherently copyable, because your computer needs to download it. But the design and “happy path” of the app dictates the culture and use of that content, encouraging it to be used in certain ways and discouraging it from being used in other ways. If we make it “hard” to copy a photo that someone else uploads, then people will feel a certain way about sharing personal content in Hubs. As a hypothetical counter-example, if every piece of content someone uploads to a room gets stored in a personal “stash” for everyone else to use later, however they want (this is something we’ve discussed) then people are going to be highly discouraged from uploading personal content. In both cases, nothing changes about the inherent access to the information, but the affordances matter in terms of how people feel during their communication within the virtual space.

#16

In case it wasn’t obvious, it’s super important to me that it’s easy, natural, and “low-stakes” for people to share personal content like photos, videos, and documents in Hubs. I think this use-case in particular is one that the low friction of the web will enable in a way other platforms cannot, and also could be a killer use of social VR.

Of course, this is tough to balance with the fact that we also want to make it possible to share, archive, or re-use bits of room state. So hence this thread :slight_smile:

#17

I guess I could imagine something like:

  • We implement CCK first, which can be distilled down to “auto-save”, so that if your client disconnects you don’t lose what you’ve created. Anything beyond that boils down to just increasing TTL on the data. Culturally, people will probably create “persistent rooms” by just keeping a client connected at all times. (People did this in Rec Room.) Could be a mix of local storage (for entities) and hosted storage (for uploads) or entirely hosted. Whatever we do for uploads would be easy to re-purpose to include entity data, and seems like it wouldn’t require accounts since the data is effectively useless blobs sitting on disk, and will get nuked on some TTL.

  • Once that works, we add the ability to “pin” objects as a v2. (This could align nicely with the Phoenix Channels support for durable room state in ~Q4.) This is the first time we have state on our servers that doesn’t require a specific user be connected for anyone to access it. Once pinned we’d end up decrypting any hosted content and removing the TTL, since we’d need to serve it even if the person isn’t in the room. Pinning might need to be tied to an account so we can have a method for people to expunge the data we store for pinned objects, since we don’t expire it anymore. Can’t get around this even if we punt on uploaded files, because people could be drawing stuff they want us to remove too.

  • Once that works, we add the ability to export/snapshot all the pinned objects in a room for re-use. By this point we probably will have a clearer picture of how to do this in a way that is privacy preserving, etc.

#18

I suspect you’ve all talked about this internally in the group, but I still have a hard time seeing why we want to save anything right now.

Even with the ability to author content in the hub, it seems like the “things” people author could still be sent out of the system, as gltf’s or similar.

I get the “friction” thing: for people who don’t have “web accounts somewhere” needing to store on the web is hard. But, there are so many options for web storage (e.g., all the “big 5” offer free services, as do dropbox/etc, plus temporary services like uploadcare and so on) that it feels like that would be a good “first step”. We could conceive of hosting content later, possibly as a paid service to make it sustainable, if/when we see the friction become real.

The reasons I’m so keen on keeping it external are

  • Simplicity
  • Sidestepping all the issues with hosting (privacy, liability, performance, etc)
  • When people have the files, they can do with them as they will. Opens up the door to interesting external tools and mashups
  • If we can save authored content as things like gltf’s, perhaps people will be able to leverage tools like Blender (on a hypothetical online gltf editor) to clean up or improve their assets. This reduces the pressure for us to make the editor full featured
  • User expectation: hubs is still “ephemeral”. We have the ability to create state that you can re-activate when you go back, but the state is up to you, not us.

I guess I’m struggling to see any real win in having us save content.

#19

I don’t think this risk is related to the Room Snapshot Model. I can already capture everything in the room (including voice data) using OBS. As in any multi-user app, the people on the other end can create copies of anything you send them without telling you. E.g. Snapchat informs you if someone used his phone’s screenshot tool to save a copy of your snap, but nothing informs you if he took a photo of his screen with a separate camera.

#20

Consider the use case of uploading a photo from your phone. Relatively few (edit: rephrased :)) are going to intuit that they have to upload the photo to a hosting provider and get the URL in order to share it in the space. They will expect to be in the app, hit a “+” button, and pick the photo from a photo picker. The underlying incidental nature of where and how that file is hosted is secondary to the mental model of “I want to bring stuff into the space, give me the tools I need to get it in easily.”