Avatar Sharing via upload token (via onetime/limited time account locked use)
MissStabby
one thing would be nice is to provide a "upload token"
so instead of a shared (this is a massive security risk) account login, a receiver can go to the vrc website, log-in and generate a upload token.
(to generate it would need to get the sender's account embedded in the token's authorization and it being a onetime/oneday use item)
And then in chat relaying the token.
Then when its time to upload instead of "Build and publish for windows"
it has a "send avatar to friend" [PASTE TOKEN HERE]
Step1: users agree to get avatar
Step2: receiver goes to vrc.com logs in and navigates to avatar page
step3: receiver goes to "receive avatar from friend"
step4: friend in list is picked out [KUNG VR]
step5: website goes: We have generated a single use upload token, send this to [KUNG VR]
(on a sidenote, this could also cause a flag on KUNG VR's account (web or sdk) so the upload dialog will go "Stabby has sent you a upload token, click here to use it" )
Step6: Sender goes to upload page on SDK and sees a button "Send avatar to friend"
Step7: Sender pastes token (or this is handled internally so the user selects the token in SDK GUI)
Step8: Normal upload process resumes
Log In
Flir
I think this is a great idea, since a lot of users rely on others to customize their avatars. The people doing the customization work are well versed with Unity, but a regular user may not be, and the amount of time it takes to become well versed enough is a substantial barrier-to-entry. So those users either do without (and just go with free avatars from avatar worlds, which may not reflect their personal identity), or they have to give someone doing that for them their login credentials (a risk, and a violation of the TOS).
I think that this needs to be more fleshed out beyond a simple one-use/fixed duration token system. There needs to be the following enhancements to really make this worthwhile:
1) The ability to restrict who can use the token
2) The ability to restrict what can be done with the token
3) The ability to control how long the token is valid
4) The ability to revoke the token at any time
5) The ability to report abuse of the token
Before going in more details, I'll define a couple terms
Consumer - the account generating the token, which grants an upload privilege to their account.
Developer - The account consuming the token, ie the user who is uploading an avatar/world to the consumer's account.
1) The ability to restrict who can use the token -- you should have the ability to select a specific VRC user who can use the token -- the SDK should still require them to log in with their to perform the upload anyways, so this shouldn't be a problem.
2) The ability to restrict what can be done with the token. The basic idea is to upload an avatar (or a world*), but granting only the ability to upload a new asset is really limited. What if the consumer wants changes after it's been uploaded? Sure, the consumer can delete the avatar and have the developer upload a new one, but it would be better to be able to grant the authority to update an avatar (since they all have unique UUIDs) The consumer should have the option to choose between upload only, update (and specify an existing avatar associated with the consumer's account via its UUID), etc, as there won't be a one-size-fits all solution to this.
3) The ability to control how long the token is valid. The consumer may choose the grant the developer an unlimited time to make updates to the avatar/world associated with the token, if they trust the developer enough for that. Or they may want to place a number of uploads or a time limit. There should be an ability to extend the duration, or resume an token which became invalidated by exceeding the upload #/time limit.
4) The ability to revoke the token at any time. Once a job is done, the consumer may wish to end the token before the duration defined in #3 is over, simply because the job is done and no further access is needed. Of course, the consumer may wish to terminate the token for any other reason. This should be easy to do.
5) The ability to report abuse of the token. Abuses will always happen. This should be reportable, and there should be some kind incident management that is fair and equitable for both the consumer and developer (because this ability can be abused too.)
* - of course, the ability to upload worlds like this requires some thought on how culpability is shared between the consumer and developer, for TOS violations, DMCA violations, etc.