Allow users to share app + settings via a URL

[pngwn]

• [x] I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.
People are manually sharing prompts + settings for stable diffusion

Describe the solution you'd like
A way for users to easily share settings just by sharing a URL.

Some options
We could use query params to do this for the most part. Each component has a unique id so it would be easy to map the values contained within url/?1=hi&2=hi2 to the correct settings for components. The only thing we really need to think about it URL length limits which are different for different browsers but are something like 2000+ at minimum. We are unlikely to hit this for most standard inputs but anything involving media or longform text could cause issues.

We would probably need to omit media and long text from this implementation.

There other alternative is to store them in a database and generate a unique short url, we could then look up the config in the DB and send that down for a given URL, this is more complex and less responsive but we would be able to cache the whole state of the page (including media + outputs). Query params can update without reloading the page and in realtime if needed (as those inputs are changed), shorturls would need to be sent off for processing.

Concerns Query params should be pretty safe but I don't know if adding subpaths to Gradio apps would cause any issues for users, if so we could add this functionality under a shareable_links=Bool flag that be get passed to .launch()

[freddyaboulton]

I wonder if we can use datasets on the hub as the "Database" for this. Regardless of the implementation, we should consolidate this issue with #1452, no?

[abidlabs]

Yes let me close #1452 as this issue is more descriptive and suggests some possible approaches

[abidlabs]

I wonder if we can use datasets on the hub as the "Database" for this

That would be pretty cool, and we have most of the logic already in place via the HuggingFaceDatasetSaver class.

[abidlabs]

So what about the following UX:

• If you create an Interface running on Spaces, a "Share" button appears under the output component (where the Flag button normally appears -- note that this button does not automatically appear)
• When you click on the "Share" button, a link is generated to the specific input and output that you have passed in, and is copied to your clipboard
• When you share the Share link, both the input and output are already preloaded

DX:

• If you are creating a gr.Interface() you don't have to do anything except pass in your HF token (optionally, a dataset name, etc.)
• If you are creating a gr.Blocks(), we provide a Share button abstraction that can select specific inputs and outputs to save
• Behind the scenes, we create a private dataset to save this info

[pngwn]

Coming back to this, using a database seem like a lot of effort. You would need to pass a token, so it would basically not be available on many interfaces, the user would have to go through a number of steps in order to actually share their parameters, further cluttering the UI. It is also gives us more to maintain + an external service as a dependency which we will need to keep track of (we currently have no testing in place to notify us when external services change).

Using the url would just be a simple copy/ paste, doesn't require permissions/ a token, is faster because there are no network requests involved and is simpler because the url would just be waiting to be copied with no additional steps for the user. Plus the maintenance benefits noted above.

We could allow the author of the space to fine tune what gets saved by adding save=True|False to each component, but if they default to True sharing params will be easier and more common.

[abidlabs]

If it's using a HF Dataset as the backend, the user of the app wouldn't have to pass in a token. Only the developer of the app would have to pass in an HF token so that a HF Dataset can be created from the Space. It wouldn't change the UI at all. I like the URL approach too for its simplicity, but the only problem is that it wouldn't work for images or any media component as you discussed above

[flozi00]

The database approach needs the users trust for the developer for sensible data. For example private images which get stored on third party storages. An made by mistake public, HF dataset could share private data without agreement by data owner. Example in mind: "Hey mom, check what this AI made with our family picture"

[sashavor]

This would be super cool for our Stable Diffusion bias Spaces, where we would like to share Spaces with people saying something like: check out this cool result with these values and they would have the Space show those, instead of the default ones

[abidlabs]

@sashavor in your case, do you need to share images/audio/etc or just numerical parameters that could be encoded into a URL?

[sashavor]

Just the numerical parameters!

[pngwn]

2654 has some implications on this and is a pre-requisite