[SDK] Permission system

design/permissions.md

@@ -0,0 +1,55 @@
+Permissions API
+=================
+
+To be a responsible member of the Social MR ecosystem, the MRE SDK has to prioritize the safety of its residents over
+the power of this SDK. As such, I propose the addition of a permissions API, so MREs can have more "invasive" features
+without compromising user safety and agency.
+
+
+Features requiring user permission
+------------------------------------
+
+* Large assets - If an MRE wants to load more than some large amount of assets into memory (30MB worth of memory? TBD),
+	the client must first approve. This permission might automatically be approved/denied by clients on behalf of users
+	based on device capabilities.
+* Attachments - As of 0.19 these are unpermissioned, but we get reports of MRE developers trolling AltspaceVR users
+	with them, so I think this is needed.
+* Movement (hypothetical) - The ability to forcibly move a user's avatar and point of view, either smoothly
+	or teleported.
+* Microphone input (hypothetical) - The ability for users to stream their microphone input into an MRE, for voice
+	commands, synthesizers, chat bots, or anything else.
+
+
+Methods for acquiring permission
+----------------------------------
+
+1. **Request permission for a feature the first time it is used**
+	1. The application code makes an async call to an API that requires user permission.
+	2. The SDK detects that this is the first time that API is used for this user, so it saves the API call request
+		internally and sends a permission request to the user.
+	3. The user's client will reply	with an approved or denied message. If approved, the original API call is executed.
+		If not, handle the rejection.
+2. **Request permission for a set of features explicitly**
+	1. The application code uses a permissions API to set the permission requirements for the app.
+	2. All current and late-joining users are sent a message asking for any permissions not already granted or denied.
+	3. Each user will reply with an approved or denied message. If approved, the approval is saved, and all future API
+		requests that require that permission will be processed for this user. If denied, handle the rejection.
+3. **Establish permissions during initialization**
+	1. Provide a list of permissions required by an app during app setup.
+	2. During connection handshake, the list of required permissions will be sent to the client.
+	3. If the client approves, initialization proceeds like normal. If not, handle the rejection.
+
+
+Methods for handling permission rejection
+-------------------------------------------
+
+1. Revoke access to the denied APIs for the set of denying users.
+2. All users must approve of all permissions; users that do not approve immediately leave the MRE.
+3. All clients must approve of all permissions; clients that do not approve immediately disconnect from the MRE server.
+
+
+Methods for presenting permission requests to users
+-----------------------------------------------------
+
+1. Dialogs
+2. Settings menu