feat: Link Sharing for Models #5256

New Issue

Closed

opened 2025-11-11 16:15:43 -06:00 by GiteaMirror · 9 comments

GiteaMirror commented 2025-11-11 16:15:43 -06:00

Owner

Copy Link

Originally created by @ricdikulous on GitHub (May 21, 2025).

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

• I have searched the existing issues and discussions.

Problem Description

Custom models made via the workspace UI can currently be:

• Private + Groups – visible to predefined groups.
  Pain point: users can’t create or manage groups themselves (needs an admin)
• Public – visible to everyone.
  Pain point: every public model is auto-added to every user’s model-picker, cluttering the UI.

There is no way for a user to share a model with a handful of colleagues or testers without involving an admin or polluting everyone else’s dropdown.

Desired Solution you'd like

Add a “Share via Link” option alongside the current Public / Private settings.

• Access by URL - Anyone with the unique link can interact with the model
• No UI clutter - The model remains hidden from all users’ dropdowns unless they are interacting with the model.
• Easy sharing - A Copy Link button (or read-only field with one-click copy) lives in the model settings panel.

Alternatives Considered

Create the model via the API, with the permissions set to public making sure to add in the "hidden":true field (which is not available in the UI for models created via the workspace UI).

Then construct a link leveraging the ?model=hidden-model-id param to give access to the mode.

While this works, it's not a great experience for the users

Additional Context

Very similar to what ChatGPT have for their customGPTs

Originally created by @ricdikulous on GitHub (May 21, 2025). Originally assigned to: @tjbck on GitHub. ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Custom models made via the workspace UI can currently be: * **Private + Groups** – visible to predefined groups. *Pain point*: users can’t create or manage groups themselves (needs an admin) * **Public** – visible to everyone. *Pain point*: every public model is auto-added to every user’s model-picker, cluttering the UI. There is **no way** for a user to share a model with a handful of colleagues or testers **without** involving an admin **or** polluting everyone else’s dropdown. ### Desired Solution you'd like Add a **“Share via Link”** option alongside the current Public / Private settings. * **Access by URL** - Anyone with the unique link can interact with the model * **No UI clutter** - The model remains hidden from all users’ dropdowns unless they are interacting with the model. * **Easy sharing** - A **Copy Link** button (or read-only field with one-click copy) lives in the model settings panel. ### Alternatives Considered Create the model via the API, with the permissions set to public making sure to add in the `"hidden":true` field (which is not available in the UI for models created via the workspace UI). Then construct a link leveraging the `?model=hidden-model-id` param to give access to the mode. While this works, it's not a great experience for the users ### Additional Context Very similar to what ChatGPT have for their customGPTs <img width="1276" alt="Image" src="https://github.com/user-attachments/assets/2065316b-31d0-4314-8564-cce43b9320bb" />

GiteaMirror closed this issue 2025-11-11 16:15:43 -06:00

GiteaMirror commented 2025-11-11 16:15:44 -06:00

Author

Owner

Copy Link

@Ithanil commented on GitHub (May 23, 2025):

Would be a nice feature! While it's no substitute for proper user-managed groups, it would still be useful if these were a thing.

@Ithanil commented on GitHub (May 23, 2025): Would be a nice feature! While it's no substitute for proper user-managed groups, it would still be useful if these were a thing.

GiteaMirror commented 2025-11-11 16:15:44 -06:00

Author

Owner

Copy Link

@ricdikulous commented on GitHub (May 25, 2025):

Agreed @Ithanil, the ability for users to create/manage their own groups and apply more granular access controls would be incredible. I’m imagining something similar to Google Docs style permissions, where the author specifies the users/groups that have access and on top of that, the access level (view / edit / owner etc.). However realise the implementation effort here is likely quite high.

From my perspective, if we take what Open WebUI currently offers and add just two things, we could cover a huge number of use-cases:

1. Link sharing of models

I suggest this because, in organisations today, I see people using exactly this pattern with their own ChatGPT subscriptions and it’s very effective.

They create private Custom GPTs for day to day tasks and if they think it will be useful for others they generate a share link and post it in Teams/Slack.

And this works.

2. Add an “Allow sharing models with groups” permission (disabled for most users)

Being able to turn off group sharing matters because many groups will contain hundreds of people and you’d quickly hit the same problem as public models - dropdown pollution and clutter.

---

Model Discoverability (opt-in access)

One other piece that comes to mind when discussing this is discoverability. Right now, any model a user can access is pushed straight into the recipient’s model dropdown. That’s fine for base models, but in a large org it clutters the UI and forces everyone to “opt-in by default.”

A middle ground would be to mark models as discoverable (to specific groups, individuals, or everyone) without immediately adding them to dropdowns:

• Add a "Discoverable” flag to the model settings, with a scope selector (Public / Groups / Individuals).
• Repurpose the workspace page:
  • My models – items I created.
  • Models shared with me – discoverable items I could add.
  • Users click “Add to My Models” to bring one into their dropdown.

This lets users share models org-wide without disrupting everyone’s experience. Admin controls could require approval before a model appears in the discoverable list and allow revocation of problematic items.

In the meantime you could mimic this with link sharing and a central wiki page that lists all the models that you want to be discoverable but that would be a far more disjointed experience.

@ricdikulous commented on GitHub (May 25, 2025): Agreed @Ithanil, the ability for users to create/manage their own groups and apply more granular access controls would be incredible. I’m imagining something similar to Google Docs style permissions, where the author specifies the users/groups that have access and on top of that, the access level (view / edit / owner etc.). However realise the implementation effort here is likely quite high. From my perspective, if we take what Open WebUI currently offers and add just **two** things, we could cover a huge number of use-cases: #### 1. Link sharing of models I suggest this because, in organisations today, I see people using exactly this pattern with their own ChatGPT subscriptions and it’s very effective. They create private Custom GPTs for day to day tasks and if they think it will be useful for others they generate a share link and post it in Teams/Slack. And this works. #### 2. Add an **“Allow sharing models with groups”** permission (disabled for most users) Being able to turn off *group sharing* matters because many groups will contain hundreds of people and you’d quickly hit the same problem as public models - dropdown pollution and clutter. --- #### Model **Discoverability** (opt-in access) One other piece that comes to mind when discussing this is **discoverability**. Right now, any model a user can access is pushed straight into the recipient’s model dropdown. That’s fine for base models, but in a large org it clutters the UI and forces everyone to “opt-in by default.” A middle ground would be to mark models as discoverable (to specific groups, individuals, or everyone) without immediately adding them to dropdowns: * Add a "Discoverable” flag to the model settings, with a scope selector (Public / Groups / Individuals). * Repurpose the workspace page: * **My models** – items I created. * **Models shared with me** – discoverable items I *could* add. * Users click “Add to My Models” to bring one into their dropdown. This lets users share models org-wide without disrupting everyone’s experience. Admin controls could require approval before a model appears in the discoverable list and allow revocation of problematic items. In the meantime you could mimic this with link sharing and a central wiki page that lists all the models that you want to be discoverable but that would be a far more disjointed experience.

GiteaMirror commented 2025-11-11 16:15:44 -06:00

Author

Owner

Copy Link

@Ithanil commented on GitHub (May 25, 2025):

Agreed @Ithanil, the ability for users to create/manage their own groups and apply more granular access controls would be incredible. I’m imagining something similar to Google Docs style permissions, where the author specifies the users/groups that have access and on top of that, the access level (view / edit / owner etc.). However realise the implementation effort here is likely quite high.

From my perspective, if we take what Open WebUI currently offers and add just two things, we could cover a huge number of use-cases:

1. Link sharing of models

I suggest this because, in organisations today, I see people using exactly this pattern with their own ChatGPT subscriptions and it’s very effective.

They create private Custom GPTs for day to day tasks and if they think it will be useful for others they generate a share link and post it in Teams/Slack.

And this works.

2. Add an “Allow sharing models with groups” permission (disabled for most users)

Being able to turn off group sharing matters because many groups will contain hundreds of people and you’d quickly hit the same problem as public models - dropdown pollution and clutter.

Model Discoverability (opt-in access)

One other piece that comes to mind when discussing this is discoverability. Right now, any model a user can access is pushed straight into the recipient’s model dropdown. That’s fine for base models, but in a large org it clutters the UI and forces everyone to “opt-in by default.”

A middle ground would be to mark models as discoverable (to specific groups, individuals, or everyone) without immediately adding them to dropdowns:

* Add a "Discoverable” flag to the model settings, with a scope selector (Public / Groups / Individuals).

* Repurpose the workspace page:
  
  * **My models** – items I created.
  * **Models shared with me** – discoverable items I _could_ add.
  * Users click “Add to My Models” to bring one into their dropdown.

This lets users share models org-wide without disrupting everyone’s experience. Admin controls could require approval before a model appears in the discoverable list and allow revocation of problematic items.

In the meantime you could mimic this with link sharing and a central wiki page that lists all the models that you want to be discoverable but that would be a far more disjointed experience.

Regarding the user groups feature, see my detailed proposals in this PR's discussion: https://github.com/open-webui/open-webui/pull/13685#issuecomment-2903730799 I think it would be ideal for a very large org, where it's not feasible for one or two central admins to manage the groups and resources of tens of thousands of users.

I really like your elegant sharing ideas for models, especially your "Discoverability" idea to allow public sharing without clutter.

I'm not sure though if link sharing is adequate for knowledge bases, where then access to potentially private data would be exposed through a link that could easily spread. In any case the owner would need a way to un-share with selected recipients.

@Ithanil commented on GitHub (May 25, 2025): > Agreed [@Ithanil](https://github.com/Ithanil), the ability for users to create/manage their own groups and apply more granular access controls would be incredible. I’m imagining something similar to Google Docs style permissions, where the author specifies the users/groups that have access and on top of that, the access level (view / edit / owner etc.). However realise the implementation effort here is likely quite high. > > From my perspective, if we take what Open WebUI currently offers and add just **two** things, we could cover a huge number of use-cases: > #### 1. Link sharing of models > > I suggest this because, in organisations today, I see people using exactly this pattern with their own ChatGPT subscriptions and it’s very effective. > > They create private Custom GPTs for day to day tasks and if they think it will be useful for others they generate a share link and post it in Teams/Slack. > > And this works. > #### 2. Add an **“Allow sharing models with groups”** permission (disabled for most users) > > Being able to turn off _group sharing_ matters because many groups will contain hundreds of people and you’d quickly hit the same problem as public models - dropdown pollution and clutter. > #### Model **Discoverability** (opt-in access) > > One other piece that comes to mind when discussing this is **discoverability**. Right now, any model a user can access is pushed straight into the recipient’s model dropdown. That’s fine for base models, but in a large org it clutters the UI and forces everyone to “opt-in by default.” > > A middle ground would be to mark models as discoverable (to specific groups, individuals, or everyone) without immediately adding them to dropdowns: > > * Add a "Discoverable” flag to the model settings, with a scope selector (Public / Groups / Individuals). > > * Repurpose the workspace page: > > * **My models** – items I created. > * **Models shared with me** – discoverable items I _could_ add. > * Users click “Add to My Models” to bring one into their dropdown. > > > This lets users share models org-wide without disrupting everyone’s experience. Admin controls could require approval before a model appears in the discoverable list and allow revocation of problematic items. > > In the meantime you could mimic this with link sharing and a central wiki page that lists all the models that you want to be discoverable but that would be a far more disjointed experience. Regarding the user groups feature, see my detailed proposals in this PR's discussion: https://github.com/open-webui/open-webui/pull/13685#issuecomment-2903730799 I think it would be ideal for a very large org, where it's not feasible for one or two central admins to manage the groups and resources of tens of thousands of users. I really like your elegant sharing ideas for *models*, especially your "Discoverability" idea to allow public sharing without clutter. I'm not sure though if link sharing is adequate for knowledge bases, where then access to potentially private data would be exposed through a link that could easily spread. In any case the owner would need a way to un-share with selected recipients.

GiteaMirror commented 2025-11-11 16:15:44 -06:00

Author

Owner

Copy Link

@tjbck commented on GitHub (May 26, 2025):

Added to dev with 9a5febc2d1

@tjbck commented on GitHub (May 26, 2025): Added to dev with 9a5febc2d168531196458563515226056e6a37c9 

GiteaMirror commented 2025-11-11 16:15:44 -06:00

Author

Owner

Copy Link

@Ithanil commented on GitHub (May 26, 2025):

Added to dev with 9a5febc

But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request.

@Ithanil commented on GitHub (May 26, 2025): > Added to dev with [9a5febc](https://github.com/open-webui/open-webui/commit/9a5febc2d168531196458563515226056e6a37c9) > >  But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request.

GiteaMirror commented 2025-11-11 16:15:45 -06:00

Author

Owner

Copy Link

@tjbck commented on GitHub (May 26, 2025):

@Ithanil yes, and you can hide the model.

@tjbck commented on GitHub (May 26, 2025): @Ithanil yes, and you can hide the model.

GiteaMirror commented 2025-11-11 16:15:45 -06:00

Author

Owner

Copy Link

@ricdikulous commented on GitHub (May 26, 2025):

Awesome!

Yes, this addresses the original request: adding a couple of UI elements so that what’s already possible through the API is also possible in the UI.

I’d love to see the other ideas we discussed in this thread implemented (i.e. dedicated link-sharing, better discoverability, limits on which groups a user can share to, more granular access controls, and user-managed groups) but I admit those are larger, more impactful changes that probably need more discussion.

Added to dev with 9a5febc

But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request.

If the model is public and hidden then it won't show in anyone's model dropdown (unless they are using it) however anyone with the link can use it, which is the same behaviour as a dedicated link sharing option, just with a couple more steps.

@ricdikulous commented on GitHub (May 26, 2025): Awesome! Yes, this addresses the original request: adding a couple of UI elements so that what’s already possible through the API is also possible in the UI. I’d love to see the other ideas we discussed in this thread implemented (i.e. dedicated link-sharing, better discoverability, limits on which groups a user can share to, more granular access controls, and user-managed groups) but I admit those are larger, more impactful changes that probably need more discussion. > > Added to dev with [9a5febc](https://github.com/open-webui/open-webui/commit/9a5febc2d168531196458563515226056e6a37c9) > >  > > But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request. If the model is public and hidden then it won't show in anyone's model dropdown (unless they are using it) however anyone with the link can use it, which is the same behaviour as a dedicated link sharing option, just with a couple more steps.

GiteaMirror commented 2025-11-11 16:15:45 -06:00

Author

Owner

Copy Link

@Ithanil commented on GitHub (May 27, 2025):

Awesome!

Yes, this addresses the original request: adding a couple of UI elements so that what’s already possible through the API is also possible in the UI.

I’d love to see the other ideas we discussed in this thread implemented (i.e. dedicated link-sharing, better discoverability, limits on which groups a user can share to, more granular access controls, and user-managed groups) but I admit those are larger, more impactful changes that probably need more discussion.

Added to dev with 9a5febc

But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request.

If the model is public and hidden then it won't show in anyone's model dropdown (unless they are using it) however anyone with the link can use it, which is the same behaviour as a dedicated link sharing option, just with a couple more steps.

Yes, understood. I thought it didn't exactly address the issue because the user still has to actively hide it for the desired effect of the admin. Or in other words, user still needs the permission to clutter the public space.

@Ithanil commented on GitHub (May 27, 2025): > Awesome! > > Yes, this addresses the original request: adding a couple of UI elements so that what’s already possible through the API is also possible in the UI. > > I’d love to see the other ideas we discussed in this thread implemented (i.e. dedicated link-sharing, better discoverability, limits on which groups a user can share to, more granular access controls, and user-managed groups) but I admit those are larger, more impactful changes that probably need more discussion. > > > > Added to dev with [9a5febc](https://github.com/open-webui/open-webui/commit/9a5febc2d168531196458563515226056e6a37c9) > > >  > > > > > > But this will only work, if the model is already shared publicly or to the recipients group, right? I don't think that was the idea of this request. > > If the model is public and hidden then it won't show in anyone's model dropdown (unless they are using it) however anyone with the link can use it, which is the same behaviour as a dedicated link sharing option, just with a couple more steps. Yes, understood. I thought it didn't exactly address the issue because the *user* still has to actively hide it for the desired effect of the *admin*. Or in other words, user still needs the permission to clutter the public space.

GiteaMirror commented 2025-11-11 16:15:45 -06:00

Author

Owner

Copy Link

@taylorwilsdon commented on GitHub (May 27, 2025):

Just throwing it out there that I still think this is an elegant implementation from a UX perspective haha I've been running it in my build since last year, so you can share straight from the dropdown rather than having to navigate into the models list directly

from https://github.com/open-webui/open-webui/pull/9186

Glad to see we've at least got the option now though! Saw this in the release notes and got excited for a second thinking that an old PR of mine had been merged and I could remove a divergence in my internal codebase 😂 I'm stoked about the underlying capability here though, being able to share work in progress with a single person via link is huge from a usability standpoint.

@taylorwilsdon commented on GitHub (May 27, 2025): Just throwing it out there that I still think this is an elegant implementation from a UX perspective haha I've been running it in my build since last year, so you can share straight from the dropdown rather than having to navigate into the models list directly  from https://github.com/open-webui/open-webui/pull/9186 Glad to see we've at least got the option now though! Saw this in the release notes and got excited for a second thinking that an old PR of mine had been merged and I could remove a divergence in my internal codebase 😂 I'm stoked about the underlying capability here though, being able to share work in progress with a single person via link is huge from a usability standpoint.

GiteaMirror referenced this issue 2025-11-11 17:56:57 -06:00

[PR #5256] [MERGED] feat: More options for AUTOMATIC1111 #8448

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

backend-outlet

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#5256