Improve Sharing Conversation: Naming, Delete, Custom Keys

[vadimkatsman]

Why
(replace this text with yours) The reason behind the request - we love it to be framed for "users will be able to do x" rather than quick-aging hype-tech-of-the-day requests

The export option includes sharing on big-agi site - as an unlisted shared url.
But when I go to import - I see only import from ChatGPT url.

Description
Clear and concise description of what you want to happen.

Ability to import from big-agi's own shared url.

Requirements
If you can, Please break-down the changes use cases, UX, technology, architecture, etc.

• ...

[vadimkatsman]

Perhaps, I don't understand what does this sharing even do.

I emailed the link to myself and opened in the browser on my home machine. I showed me absolutely nothing. OK, I thought, on my home machine big-agi is not configured with api key - maybe this is a reason.

Then I opened the link on my main machine where I use the tool since the beginning. It showed me the existence of the chat but not much more. I am attaching the screenshot.

I would expect:

• loaded my chat as I exported
• loaded on any machine - with api key or without -> this feature is very useful for sharing between different devices I have but not all devices will be configured for actual chatting (I may access the chat for generated content on my iPad but I don't plan actually interact on iPad; I may share the chat with a collegue but last thing on Earth I would want him to continue interactions in the chat using my API key ;( )
• option to delete - when seeing the online version of the uploaded chat I would expect to have a least "delete" button (I assume the delete key will be prompted to confirm deletion).
• SUGGESTION: to have 2 shared links - with ability to edit and read-only. The read-only view will not have "delete" button and the only option would be to clone into local storage if the person wants to continue with the chat
• QUESTION: I would assume:
  • if I continue chatting using the shared link, the online copy of the chat gets updated and
  • be visible whoever has this url open;
  • but it will not update any local copies and will not be stored locally UNLESS I clone to a local environment, at which point my local changes would be detached from the online version

[vadimkatsman]

Follow up question:

• If I attempt to share same local chat again, what would actually happen - it will generate a new link? will it re-use the same link with the option to upload updates? - if it reuses the same link, how will it handle independent changes between local and online version of the same chat?
• if I export a local chat which was recently shared, will a shared link be available inside the export JSON? It would be helpful if it would.

It would be helpful to track shared links - it will require less load on your servers too since it is very easy to misplace those shared links and people would generate them over and over to send to somebody else, hence it will be easier to refer to the same link rather than generate again if it is accessible (at least on JSON but would be nice if on UI as well).

[vadimkatsman]

One more follow up.

The deletion key.

Sharing links over email is easy, but keeping track of deletion keys could be a hassle. Real hassle.
Hence few suggestions:

• preserve the deletion key in the original chat's browser - as long as I am not sharing a key the link is not needed to be treated as bitcoin wallet or something national security related
• offer an option for deletion pass-phrase - in tool's preferences with an option to be adjusted while sharing
• the pass-phrase could be blank - in this case everybody with edit rights would be able to delete (but in many cases, those "everybody" is the same guy using shared link to exchange chats between machines)
• for security minded people - give them a choice between using a personal or provided pass-phrase and the key generated by the system

It is not that you offer a directory of those shared links living in the public domain. Despite shared online through your servers, shared chats are still private and accessible only through the link explicitly shared with recipients.

The private nature of the link makes those links non-public (I am now thinking from legal prospective if chat contains a conversation around patent creation and patent related information shared to the public domain invalidates all claims of the patent - so while security of the deletion key is not much of a concern, aspects private vs public information living in public domain or retaining privileged access is important legal concern).

Another remedy for super security minded individuals - adding password-protection to open shared link. It is important since emails are routinely forwarded and replied to with possibility of link getting outside of initial circle of people with privileged access, and simple password protection would eliminate random people accessing a chat even with the link.

As you noticed, I am trying not to blindly follow some "best practice approach" but to balance security and practicality. Security - when it is important, and practicality - when overzealous security does not make anything more secure but lowers effectiveness and usefulness of otherwise good feature.

[enricoros]

Hi, few things going on in this thread.

1. (Urgent) Is there a bug so you could not see the conversation? Sharing works on get.big-agi.com, but if it's not working for you please walk me through the same steps (the screenshot looks empty, which is probably a bug unless the chat was empty)

2. Deletion key: yes, we could track it on the origination browser, good point. Will probably do.

3. Branching/etc. when sharing, a copy of the chat with the same Unique ID is uploaded to the server. When "cloning", the same Chat ID is used, making it the same chat across machines. However, in case you already have that Chat on that machine, you are offered the option to Clone or Replace (see screenshot)

[vadimkatsman]

I will retry sharing and will let you know if I can reproduce – or it was a glitch on my end. From: Enrico Ros ***@***.***> Sent: Sunday, January 21, 2024 1:52 PM To: enricoros/big-AGI ***@***.***> Cc: Vadim Katsman ***@***.***>; Author ***@***.***> Subject: Re: [enricoros/big-AGI] [Roadmap] Import conversation from shared url (Issue #356) Hi, few things going on in this thread. 1. (Urgent) Is there a bug so you could not see the conversation? Sharing works on get.big-agi.com, but if it's not working for you please walk me through the same steps (the screenshot looks empty, which is probably a bug unless the chat was empty) 2. Deletion key: yes, we could track it on the origination browser, good point. Will probably do. 3. Branching/etc. when sharing, a copy of the chat with the same Unique ID is uploaded to the server. When "cloning", the same Chat ID is used, making it the same chat across machines. However, in case you already have that Chat on that machine, you are offered the option to Clone or Replace (see screenshot)Screenshot_20240121_115121_Chrome.jpg (view on web)<https://github.com/enricoros/big-AGI/assets/32999/8c2387ab-0784-4f89-969c-ebcd43bab86a> — Reply to this email directly, view it on GitHub<#356 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSW6JE44YVFBH2W6OLFI33YPVWVFAVCNFSM6AAAAABCDUT4YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSG42DEMZWGU>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[vadimkatsman]

I repeated sharing, and this time it worked as expected – I was able to open an online version on originating machine and on my home PC, and was able to clone the chat into my home PC browser. From: Enrico Ros ***@***.***> Sent: Sunday, January 21, 2024 1:52 PM To: enricoros/big-AGI ***@***.***> Cc: Vadim Katsman ***@***.***>; Author ***@***.***> Subject: Re: [enricoros/big-AGI] [Roadmap] Import conversation from shared url (Issue #356) Hi, few things going on in this thread. 1. (Urgent) Is there a bug so you could not see the conversation? Sharing works on get.big-agi.com, but if it's not working for you please walk me through the same steps (the screenshot looks empty, which is probably a bug unless the chat was empty) 2. Deletion key: yes, we could track it on the origination browser, good point. Will probably do. 3. Branching/etc. when sharing, a copy of the chat with the same Unique ID is uploaded to the server. When "cloning", the same Chat ID is used, making it the same chat across machines. However, in case you already have that Chat on that machine, you are offered the option to Clone or Replace (see screenshot)Screenshot_20240121_115121_Chrome.jpg (view on web)<https://github.com/enricoros/big-AGI/assets/32999/8c2387ab-0784-4f89-969c-ebcd43bab86a> — Reply to this email directly, view it on GitHub<#356 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSW6JE44YVFBH2W6OLFI33YPVWVFAVCNFSM6AAAAABCDUT4YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSG42DEMZWGU>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[vadimkatsman]

>> However, in case you already have that Chat on that machine, you are offered the option to Clone or Replace (see …

I would like to suggest some terminology changes. 1. When I open a link on a remote machine with no that chat prior to opening a link, the “Clone” creates a copy of the chat on a new machine locally but preserving the chat ID. 2. However, if I already have that chat ID on my local machine, the “Replace” would import an updated chat but “Clone” would create a duplicated chat with a new ID on that machine * The original meaning of “Clone” command is inherited by “Replace” command, and the meaning of “Clone” has changed * I guess, it would add “-Clone” or “-Copy” suffix to the name of the chat to avoid confusion between two chats with different ID but with the same name. * Since unique chat ID is not visible to the user, there will be no way for the user to know which chat is original and which one is a newly imported with updates. 3. Hence, suggestions: * Keep “Clone” in the same meaning and “Duplicate” and refer to a duplication of the local chat; do not refer verb “Clone” in connection with the online shared version – when we use what you refer as clone we are not cloning anything – we are not duplicating a chat online, we are importing online chat into a local environment but with the same chat ID. * For the activity of bringing the online copy to the local machine, rather use “Import”. i. Maybe even avoiding using verbs “Clone” or “Replace” whatsoever. Instead using “Import” (no local copy), “Import as New” and “Import Over” commands. 1. I assume the tool is facing the same situation with regular import (from JSON) – I can import as a copy or import over existing one (I played with exports but did not play with imports yet). 2. Still, option of import from the shared Url will be a useful shortcut (it would do importing a shared chat without manually opening the link in a different tab first). * I am referring to “Import” dialog with sources (like JSON, ChatGPT. etc.) From: Enrico Ros ***@***.***> Sent: Sunday, January 21, 2024 1:52 PM To: enricoros/big-AGI ***@***.***> Cc: Vadim Katsman ***@***.***>; Author ***@***.***> Subject: Re: [enricoros/big-AGI] [Roadmap] Import conversation from shared url (Issue #356) Hi, few things going on in this thread. 1. (Urgent) Is there a bug so you could not see the conversation? Sharing works on get.big-agi.com, but if it's not working for you please walk me through the same steps (the screenshot looks empty, which is probably a bug unless the chat was empty) 2. Deletion key: yes, we could track it on the origination browser, good point. Will probably do. 3. Branching/etc. when sharing, a copy of the chat with the same Unique ID is uploaded to the server. When "cloning", the same Chat ID is used, making it the same chat across machines. However, in case you already have that Chat on that machine, you are offered the option to Clone or Replace (see screenshot)Screenshot_20240121_115121_Chrome.jpg (view on web)<https://github.com/enricoros/big-AGI/assets/32999/8c2387ab-0784-4f89-969c-ebcd43bab86a> — Reply to this email directly, view it on GitHub<#356 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSW6JE44YVFBH2W6OLFI33YPVWVFAVCNFSM6AAAAABCDUT4YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSG42DEMZWGU>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[vadimkatsman]

Few more things related to this feature.

1. I still don't see an option to delete shared chat.

2. This one is probably a side effect but useful feature, so let me elaborate.

I have generated 2 shared chats and opened them both on the originating browser. When I open a specific link (and that link is what I see in the address bar) I see a side navigation panel called "Shared Chats" that list both of shared chats - and I can switch between them back and forth. Very useful!

But if I leave either of the shared chats and go to the main local canvas I did not find any ways to navigate back to "Shared Chats" panel - where I can see chats shared by me (let me re-phrase it - chats shared by me and opened at least once in this browser).

It means somehow my browser remembers visits to shared chats, so having go back to that panel should be possible.

[enricoros]

Requirements:

• Option to delete shared chats
• Save deletion keys in the originating browser for convenience.
• Rename operations to "Import," "Import as New," and "Import Over" for clarity (address confusion between Clone and Replace)
• Enable navigate back to the "Shared Chats" panel, if the user shared 1+ chat before
• Allow configurable deletion passphrases for shared chat

Postponed:

• Import chats from big-AGI's own shared URLs (postponed because: working solution already)
• Password protection for accessing high-security shared links (postponed because: priorities)
• Include shared links in the export JSON for easier tracking

[enricoros]

• renames

[enricoros]

Implemented most of the ideas.

In the following you can see the way to go back to shared chats, delete (from the chat, or the drawer (only in the originating browser)), the new naming, etc. Quite a lot of work and good for now. For the "import" for now, let's keep it at the bottom of the "Link" page, with the new naming.

Example:

[enricoros]

Also editing of the deletion key is supported now:

[vadimkatsman]

You rock!

[vadimkatsman]

A lowest possible priority note about "Share" button. I am sure on a mobile device it will trigger standard mechanism for bringing sharing sources. But what about desktop browsers - Windows, Macs, Linux? I am on Windows and using Chrome - and it did not prompted me for any actions. Maybe choices like Teams, OneNote, Word, email? Email triggered by "mail-to:" link would open the default email client - which could include the link and a subject.

Again, I did not want to distract you from your planned improvements and want just to share the idea to your idea box.

[enricoros]

Thanks for the idea. The Sharing mechanism is probing browser support, and usually on Chrome/Windows it should open Outlook or offer a couple of options (it does on my PC), while on Firefox it does not show up. This is the Web Share API.

Maybe I should disable Share on Desktop - better not have it than let down a user once they click.

[vadimkatsman]

Let me respond in two separate comments - as a geek first and as a user second.

I honestly did not expect it to work when I first tried it 3 days ago. Knowing a bit how this works on mobile devices - which requires a participating application be registered as a target - I was not aware about such participation mechanism for standard Windows applications. So, I was not surprised at all.

After you pointed to Web Share API, I checked, and it depends on a mirror Web Share Target API.

• It requires the target application be running and be registered as a target
• It could be done by any web site and becomes common for PWS - progressive web applications
• In Windows 10, native Windows apps are not participants but PWAs are - most apps from Windows App Store (I personally removed them all, but it is me) - BTW, that explains why applications from App Store were constantly running - to be a share target
• In Windows 11, they are pushing for more PWAs and added support for web sharing target in native OS applications - I am sure custom applications would take advantage of both approaches (support for API or becoming PWA)
• New Outlook is expected to be PWA

So, outside of the browser not supporting it outright, or your users host local versions without SSL, the rest of this feature depends on applications in the control of the user.

Now that I am aware what to look for, I will test if Teams is PWA and a participant of web share target API. I will test same with Evernote, I will even check if there is a not well publicized setting in my current Outlook to be the target as well.

I think you may consider the application itself to be not only the source but the target. Why - as you allow only one tab of the app? Think about sharing between Chrome and Edge on the same machine. Or two browsers in incognito mode. Or people that are using custom / customized browsers with extra layer of web security. And so on.

Hence, my second comment.

I would rather keep that feature enabled - if browser supports it (canShare) - but would add a hint that "Sharing feature depends on applications participating in sharing over the Web. Please check if participating Progressive Web Applications are currently running." - something along this line (would add a link to some useful non-technical resource about this desktop feature - I am sure MacOS has its own quirks), so the user will be aware what to expect, would not consider not popping up anything a bug, and would be proactive in making the feature useful.