Provide a setting for public spaces to hide the Files tab
Is your feature request related to a problem? Please describe.Since our company has patent-pending process patents, we don’t want the code in our app made public. We have implemented the suggested public → private space approach using Gradio.load in the public space. While it works in certain circumstances in 3.50.2, it’s now broken in 4.1.1. There are other limitations, especially when using auth=, since the username doesn’t get passed to the private space. We have also seen that the a .load in the private space throws an error. Overall, using this approach to keep files hidden really complicates the setup and stability of the app on HF.Describe the solution you’d likeI would suggest that the Space → Settings have a switch (similar to Public/Private switch) that turns off the “Files” tab in the UI. That way we could have a Public space, with auth= turned on, but not expose our code to the general public. It should also not be possible to duplicate the space or clone the repo.
2023-11-08T10:17:53Z
hey! we’ve thought about it in the past, but haven’t had that many requests for this until now.cc’ing@abidlabsand team for visibility
2024-02-02T02:25:02Z
I agree, I could also use this feature greatly.
2024-02-10T02:05:38Z
I really appreciateHuggingface.cofor its loving sharing ideas and codes samples (its how I learned so much to use advanced Python and more deeply especially Gradio framework. (I’m a web developer in PHP… so… I don’t frequently use python for such many things out ofHuggingface.co.).I think it will be a very bad feature if people would had a Files tab switcher for disable the readability code for spaces. It certainly will have a solid and strong impact on creativity and improvements of existing spaces or new spaces.Anyway, I can understand the needs of a such feature for hiding sensitive code would involving private data.Then, I suggest a such disruptive feature is only for paid account and not for free account plan.Otherwise, people will be able to limit the amount of creativity to run inHuggingface.copublic services.Again, the real power ofHuggingface.co(from my own viewpoint) is its sharing love to open-source code.Please don’t forget to share knowledge.I develop currently a space (for the moment it is in private access), but once it got done, I will switch it to public access for everyone can improves the code).Please don’t kill the creativity.So, then, everyones will enjoy a great time onHuggingface.co, and learning much more better by studying existing code.
2024-02-10T02:41:54Z
Perhaps Hugging Face could put it to a vote?
2024-02-10T05:20:00Z
I think it’s a good suggestion that this option would only be available to paid accounts. My company is working on creating a commercially distributed app, so we are fine with paying a fee, but we can’t justify the cost of building an app and then allowing anyone to copy the source code. It’s kind of a choice for Hugging Face. Do they want to be a platform for B2B/B2C apps, or just an experimental/hobbyist environment? Not a bad choice either way, but having talked with the VP of Enterprise Bus. Dev, I don’t see why an Enterprise would be $1,000s of dollars a year for support/advice while exposing their code to the world to be copied by anyone…