Is your feature request related to a problem? Please describe.
Current implementation of sharing chats would require the recipient to be logged in, thus making it difficult to share to non-users on-the-fly.
I had considered reporting this as a bug due to #2664 seeming to suggest that this feature was once available, but perhaps due to the implementation of single-user vs multi-user implementation, it might have forced API to be redirected /auth any time an unauthorized user accesses the service.
I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.
Describe the solution you'd like
The shared bubble would show a toggle of whether the chat link is to be public. If it is, it doesn't require any authentication to look at the chat.
Describe alternatives you've considered
Create a user account just to view the shared chat, but since role implementation are not granular (model whitelisting only affects users, and no separate roles just for viewers, or budget restrictions for each user, etc.), this is currently not viable.
Originally created by @Syakyr on GitHub (Jun 7, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/2904
**Is your feature request related to a problem? Please describe.**
Current implementation of sharing chats would require the recipient to be logged in, thus making it difficult to share to non-users on-the-fly.
I had considered reporting this as a bug due to #2664 seeming to suggest that this feature was once available, but perhaps due to the implementation of single-user vs multi-user implementation, it might have forced API to be redirected `/auth` any time an unauthorized user accesses the service.
I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.
**Describe the solution you'd like**
The shared bubble would show a toggle of whether the chat link is to be public. If it is, it doesn't require any authentication to look at the chat.
**Describe alternatives you've considered**
Create a user account just to view the shared chat, but since role implementation are not granular (model whitelisting only affects users, and no separate roles just for viewers, or budget restrictions for each user, etc.), this is currently not viable.
I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.
Related - #2890 (Public Access Option), but I believe your request should remain open along side it.
<!-- gh-comment-id:2154232547 -->
@silentoplayz commented on GitHub (Jun 7, 2024):
> I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.
Related - #2890 (Public Access Option), but I believe your request should remain open along side it.
I've read #2890 (didn't catch the issue as I was searching for "chats" for duplicates before opening this issue), and I hope that we eventually have those features. I suppose what I'm proposing here is of a smaller scale since just to casually share the results to other people. I suppose something to add to this feature is an expiry date to the links just in case one doesn't intend to share the page indefinitely.
<!-- gh-comment-id:2154376239 -->
@Syakyr commented on GitHub (Jun 7, 2024):
I've read #2890 (didn't catch the issue as I was searching for "chats" for duplicates before opening this issue), and I hope that we eventually have those features. I suppose what I'm proposing here is of a smaller scale since just to casually share the results to other people. I suppose something to add to this feature is an expiry date to the links just in case one doesn't intend to share the page indefinitely.
<!-- gh-comment-id:2289400694 -->
@RexWzh commented on GitHub (Aug 14, 2024):
A temperate solution, if you wish to share few chats with others. A dummy way.
1. Visit your shared link.
2. In your browser, press `Ctrl + S` to save the HTML file.
3. Upload the saved HTML file to the server, for example, to `/var/www/shared_chats`.
4. `chmod 755 -R /var/www/shared_chats` to avoid permissions issue.
Configure your Nginx server as follows:
```bash
server {
listen 443 ssl;
server_name {your-shared-url};
ssl_certificate /etc/letsencrypt/live/{your-shared-url}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/{your-shared-url}/privkey.pem;
root /var/www/shared_chats;
}
server {
listen 80;
server_name {your-shared-url};
rewrite ^(.*)$ https://$host$1 permanent;
}
```
An example chat:
[https://shared-chats.cubenlp.com/gpt4o.html](https://shared-chats.cubenlp.com/gpt4o.html)
@CallumCarmicheal commented on GitHub (Jan 31, 2025):
Is there any progress being made on this issue? Currently there is a way to publically share the chat conversation with the public through Open-WebUI's community website although this still involves uploading chat context and data to an external service that is not controlled by the hosted instance. The solution proposed by @RexWzh only works for simple prompts where multiple choices / generations are not present. Neither are attachments accessible through a saved page.
Is there any further interest in this for privacy concerns or is this issue now being ignored because the save to community feature exists?
<!-- gh-comment-id:2627452974 -->
@CallumCarmicheal commented on GitHub (Jan 31, 2025):
Is there any progress being made on this issue? Currently there is a way to publically share the chat conversation with the public through Open-WebUI's community website although this still involves uploading chat context and data to an external service that is not controlled by the hosted instance. The solution proposed by @RexWzh only works for simple prompts where multiple choices / generations are not present. Neither are attachments accessible through a saved page.
Is there any further interest in this for privacy concerns or is this issue now being ignored because the save to community feature exists?
Can agree with others above. For me personally it makes no sense to use community sharing. I need sharing which is available on my instance so I can:
Control when to stop sharing it from the chat itself (like it's implemented now, but doesn't work yet without authentication)
Use it in the LAN (for my home installation) or in the network which accessible only via VPN (for my work installation)
Asking people to register isn't too convenient too since:
It's a bit much to ask
In some cases registration is just disabled
<!-- gh-comment-id:2764572915 -->
@skobkin commented on GitHub (Mar 30, 2025):
Can agree with others above. For me personally it makes no sense to use community sharing. I need sharing which is available on my instance so I can:
- Control when to stop sharing it from the chat itself (like it's implemented now, but doesn't work *yet* without authentication)
- Use it in the LAN (for my home installation) or in the network which accessible only via VPN (for my work installation)
Asking people to register isn't too convenient too since:
- It's a bit much to ask
- In some cases registration is just disabled
Need this feature. We may think of implementing it with below features
Option to share with temporary password
Option to share with an expiry date
Option to share it without password
Option to revoke the shared chat
Option to restrict usage of LLM models on shared chats
<!-- gh-comment-id:2823684407 -->
@navilg commented on GitHub (Apr 23, 2025):
Need this feature. We may think of implementing it with below features
1. Option to share with temporary password
2. Option to share with an expiry date
3. Option to share it without password
4. Option to revoke the shared chat
5. Option to restrict usage of LLM models on shared chats
Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to Read access would prevent users from cloning the chat when viewing it via the shared link, while Write access would allow them to clone the chat into their own chats list.
It's a +1 from me for being able (in the future of course) to share chats without requiring someone to sign up to view it.
<!-- gh-comment-id:2952506191 -->
@silentoplayz commented on GitHub (Jun 7, 2025):
Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to `Read` access would prevent users from cloning the chat when viewing it via the shared link, while `Write` access would allow them to clone the chat into their own chats list.
It's a +1 from me for being able (in the future of course) to share chats without requiring someone to sign up to view it.
Need this feature. We may think of implementing it with below features
1. Option to share with temporary password
2. Option to share with an expiry date
3. Option to share it without password
4. Option to revoke the shared chat
5. Option to restrict usage of LLM models on shared chats
By the way, if you weren't aware, there's an option to revoke the shared chat URL within the Share modal of a chat. This option becomes available if you revisit the Share modal of the chat after initially generating the share link.
<!-- gh-comment-id:2952517481 -->
@silentoplayz commented on GitHub (Jun 7, 2025):
> Need this feature. We may think of implementing it with below features
>
> 1. Option to share with temporary password
>
> 2. Option to share with an expiry date
>
> 3. Option to share it without password
>
> 4. Option to revoke the shared chat
>
> 5. Option to restrict usage of LLM models on shared chats
By the way, if you weren't aware, there's an option to revoke the shared chat URL within the `Share` modal of a chat. This option becomes available if you revisit the `Share` modal of the chat after initially generating the share link.
This feature is something I urgently need. It would greatly improve my experience. Please consider prioritizing its development.
<!-- gh-comment-id:2983871002 -->
@xindoo commented on GitHub (Jun 18, 2025):
This feature is something I urgently need. It would greatly improve my experience. Please consider prioritizing its development.
Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to Read access would prevent users from cloning the chat when viewing it via the shared link, while Write access would allow them to clone the chat into their own chats list.
I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to read it.
<!-- gh-comment-id:3144235053 -->
@skobkin commented on GitHub (Aug 1, 2025):
> Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to `Read` access would prevent users from cloning the chat when viewing it via the shared link, while `Write` access would allow them to clone the chat into their own chats list.
I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to **read** it.
I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to read it.
Never did I mention that cloning a chat should require "write" permission on the chat. It'd be an optional permission. Perhaps my original message didn't get the point across as clearly as I would've hoped, so I will try to break things down for easier digestion. Say for example, I generated a share link for a chat I want to share with a friend that has an account on my Open WebUI instance. I could be given the option to keep the chat permission with read+write access, or adjust it to have only read access before (or even after) generating the chat link for sharing.
Read+write access = Default behavior and the same behavior we already see displayed for shared chats in Open WebUI.
For example, if my friend visits the URL for the shared chat, they will be able to read the chat, but also see a Clone button at the bottom center of the page to clone the chat into their own chats sidebar on their own account.
Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them. It doesn't exist on the shared chat's page for anybody and keeps the chat from being spread around like a virus.
I hope this clears up any cloudy vision of what I am hoping to see come to Open WebUI for shared chats!
<!-- gh-comment-id:3150235807 -->
@silentoplayz commented on GitHub (Aug 4, 2025):
> I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
> Cloning is basically creating a copy which belongs to you. To copy something you need to be able to **read** it.
Never did I mention that cloning a chat **should require** "write" permission on the chat. It'd be an optional permission. Perhaps my original message didn't get the point across as clearly as I would've hoped, so I will try to break things down for easier digestion. Say for example, I generated a share link for a chat I want to share with a friend that has an account on my Open WebUI instance. I could be given the option to keep the chat permission with read+write access, or adjust it to have only read access before (or even after) generating the chat link for sharing.
Read+write access = Default behavior and the same behavior we already see displayed for shared chats in Open WebUI.
For example, if my friend visits the URL for the shared chat, they will be able to read the chat, but also see a `Clone` button at the bottom center of the page to clone the chat into their own chats sidebar on their own account.
Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them. It doesn't exist on the shared chat's page for anybody and keeps the chat from being spread around like a virus.
I hope this clears up any cloudy vision of what I am hoping to see come to Open WebUI for shared chats!
@silentoplayz I'm sorry, but it still doesn't make any sense to me.
The first part of your message contradicts with the second from my PoV.
First:
Never did I mention that cloning a chat should require "write" permission on the chat
Second:
Read+write access = <...> they will be able to read the chat, but also see a Clone button at the bottom center of the page to clone the chat
Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them
The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.
What am I missing?
<!-- gh-comment-id:3150271522 -->
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz I'm sorry, but it still doesn't make any sense to me.
The first part of your message contradicts with the second from my PoV.
First:
> Never did I mention that cloning a chat should require "write" permission on the chat
Second:
> Read+write access = <...> they will be able to read the chat, but **also see a Clone button** at the bottom center of the page to clone the chat
> Only "read" access = That button to clone the chat into my friend's own account **becomes unavailable** for them
So, in summary:
`Read` + `Write`: "Clone" button available.
`Read`: "Clone" button unavailable.
The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.
What am I missing?
The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.
What am I missing?
I think you're seeing this all too pedantically. Read+Write access = You have read access to read the contents of the shared chat, but you can also clone said chat into your own account. Read access = The "clone" button on any shared chat's page disappears, leaving users the ability to still READ the contents of the chat (view it with their eyeballs), but creating a copy/clone of this chat into your own account is not an option anymore. This is as simple as it can get. And if you think anything else while hearing this come from me and still decide to contradict my words, then you're tripping over a log you laid out before yourself; not me.
<!-- gh-comment-id:3150298213 -->
@silentoplayz commented on GitHub (Aug 4, 2025):
> The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.
>
> What am I missing?
I think you're seeing this all too pedantically. Read+Write access = You have read access to read the contents of the shared chat, but you can also clone said chat into your own account. Read access = The "clone" button on any shared chat's page disappears, leaving users the ability to still READ the contents of the chat (view it with their eyeballs), but creating a copy/clone of this chat into your own account is not an option anymore. This is as simple as it can get. And if you think anything else while hearing this come from me and still decide to contradict my words, then you're tripping over a log you laid out before yourself; not me.
@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.
"read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.
"write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.
I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user expects from it. If you make it do unexpected things, it'll become unfriendly.
If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.
<!-- gh-comment-id:3150390242 -->
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.
- "read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.
- "write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.
- I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user **expects** from it. If you make it do unexpected things, it'll become unfriendly.
If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.
@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.
"read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.
"write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.
I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user expects from it. If you make it do unexpected things, it'll become unfriendly.
If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.
Fair enough. I can see both sides of the argument and I wasn't thinking logically about the whole issue. I do apologize for the tone I gave towards the end of my previous response to you. My reasoning was sound to me with my way of thinking, but may not be sound in your books. That's okay. I still have much to learn and you've taught me something today.
<!-- gh-comment-id:3150450085 -->
@silentoplayz commented on GitHub (Aug 4, 2025):
> @silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.
>
> - "read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.
> - "write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.
> - I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user **expects** from it. If you make it do unexpected things, it'll become unfriendly.
>
> If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.
Fair enough. I can see both sides of the argument and I wasn't thinking logically about the whole issue. I do apologize for the tone I gave towards the end of my previous response to you. My reasoning was sound to me with my way of thinking, but may not be sound in your books. That's okay. I still have much to learn and you've taught me something today.
@silentoplayz No offence taken. I'm glad that I was able to explain how did I come to that conclusion 🤝 .
<!-- gh-comment-id:3150496112 -->
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz No offence taken. I'm glad that I was able to explain how did I come to that conclusion 🤝 .
more granular sharing permissions were added recently, only thing missing now would be truly public sharing
<!-- gh-comment-id:4471779290 -->
@Classic298 commented on GitHub (May 17, 2026):
more granular sharing permissions were added recently, only thing missing now would be truly public sharing
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Syakyr on GitHub (Jun 7, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/2904
Is your feature request related to a problem? Please describe.
Current implementation of sharing chats would require the recipient to be logged in, thus making it difficult to share to non-users on-the-fly.
I had considered reporting this as a bug due to #2664 seeming to suggest that this feature was once available, but perhaps due to the implementation of single-user vs multi-user implementation, it might have forced API to be redirected
/authany time an unauthorized user accesses the service.I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.
Describe the solution you'd like
The shared bubble would show a toggle of whether the chat link is to be public. If it is, it doesn't require any authentication to look at the chat.
Describe alternatives you've considered
Create a user account just to view the shared chat, but since role implementation are not granular (model whitelisting only affects users, and no separate roles just for viewers, or budget restrictions for each user, etc.), this is currently not viable.
@silentoplayz commented on GitHub (Jun 7, 2024):
Related - #2890 (Public Access Option), but I believe your request should remain open along side it.
@Syakyr commented on GitHub (Jun 7, 2024):
I've read #2890 (didn't catch the issue as I was searching for "chats" for duplicates before opening this issue), and I hope that we eventually have those features. I suppose what I'm proposing here is of a smaller scale since just to casually share the results to other people. I suppose something to add to this feature is an expiry date to the links just in case one doesn't intend to share the page indefinitely.
@RexWzh commented on GitHub (Aug 14, 2024):
A temperate solution, if you wish to share few chats with others. A dummy way.
Ctrl + Sto save the HTML file./var/www/shared_chats.chmod 755 -R /var/www/shared_chatsto avoid permissions issue.Configure your Nginx server as follows:
An example chat:
https://shared-chats.cubenlp.com/gpt4o.html
@CallumCarmicheal commented on GitHub (Jan 31, 2025):
Is there any progress being made on this issue? Currently there is a way to publically share the chat conversation with the public through Open-WebUI's community website although this still involves uploading chat context and data to an external service that is not controlled by the hosted instance. The solution proposed by @RexWzh only works for simple prompts where multiple choices / generations are not present. Neither are attachments accessible through a saved page.
Is there any further interest in this for privacy concerns or is this issue now being ignored because the save to community feature exists?
@ddkedr commented on GitHub (Mar 28, 2025):
Up! Really need this
@skobkin commented on GitHub (Mar 30, 2025):
Can agree with others above. For me personally it makes no sense to use community sharing. I need sharing which is available on my instance so I can:
Asking people to register isn't too convenient too since:
@navilg commented on GitHub (Apr 23, 2025):
Need this feature. We may think of implementing it with below features
@janaki-sasidhar commented on GitHub (Jun 6, 2025):
Need this feature
@silentoplayz commented on GitHub (Jun 7, 2025):
Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to
Readaccess would prevent users from cloning the chat when viewing it via the shared link, whileWriteaccess would allow them to clone the chat into their own chats list.It's a +1 from me for being able (in the future of course) to share chats without requiring someone to sign up to view it.
@silentoplayz commented on GitHub (Jun 7, 2025):
By the way, if you weren't aware, there's an option to revoke the shared chat URL within the
Sharemodal of a chat. This option becomes available if you revisit theSharemodal of the chat after initially generating the share link.@xindoo commented on GitHub (Jun 18, 2025):
This feature is something I urgently need. It would greatly improve my experience. Please consider prioritizing its development.
@QriDoki commented on GitHub (Jul 23, 2025):
Need this feature
@jasverma-hub commented on GitHub (Jul 23, 2025):
Is there any progress on this feature?
@latel commented on GitHub (Aug 1, 2025):
Is there any progress on this feature?
@skobkin commented on GitHub (Aug 1, 2025):
I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to read it.
@silentoplayz commented on GitHub (Aug 4, 2025):
Never did I mention that cloning a chat should require "write" permission on the chat. It'd be an optional permission. Perhaps my original message didn't get the point across as clearly as I would've hoped, so I will try to break things down for easier digestion. Say for example, I generated a share link for a chat I want to share with a friend that has an account on my Open WebUI instance. I could be given the option to keep the chat permission with read+write access, or adjust it to have only read access before (or even after) generating the chat link for sharing.
Read+write access = Default behavior and the same behavior we already see displayed for shared chats in Open WebUI.
For example, if my friend visits the URL for the shared chat, they will be able to read the chat, but also see a
Clonebutton at the bottom center of the page to clone the chat into their own chats sidebar on their own account.Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them. It doesn't exist on the shared chat's page for anybody and keeps the chat from being spread around like a virus.
I hope this clears up any cloudy vision of what I am hoping to see come to Open WebUI for shared chats!
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz I'm sorry, but it still doesn't make any sense to me.
The first part of your message contradicts with the second from my PoV.
First:
Second:
So, in summary:
Read+Write: "Clone" button available.Read: "Clone" button unavailable.The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.
What am I missing?
@silentoplayz commented on GitHub (Aug 4, 2025):
I think you're seeing this all too pedantically. Read+Write access = You have read access to read the contents of the shared chat, but you can also clone said chat into your own account. Read access = The "clone" button on any shared chat's page disappears, leaving users the ability to still READ the contents of the chat (view it with their eyeballs), but creating a copy/clone of this chat into your own account is not an option anymore. This is as simple as it can get. And if you think anything else while hearing this come from me and still decide to contradict my words, then you're tripping over a log you laid out before yourself; not me.
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.
If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.
@silentoplayz commented on GitHub (Aug 4, 2025):
Fair enough. I can see both sides of the argument and I wasn't thinking logically about the whole issue. I do apologize for the tone I gave towards the end of my previous response to you. My reasoning was sound to me with my way of thinking, but may not be sound in your books. That's okay. I still have much to learn and you've taught me something today.
@skobkin commented on GitHub (Aug 4, 2025):
@silentoplayz No offence taken. I'm glad that I was able to explain how did I come to that conclusion 🤝 .
@silentoplayz commented on GitHub (Aug 13, 2025):
https://github.com/open-webui/open-webui/pull/16367
@Classic298 commented on GitHub (May 17, 2026):
more granular sharing permissions were added recently, only thing missing now would be truly public sharing