Sharing a file
Two ways to hand a file to someone - a public link, which is unlisted rather than private, and sharing with named coaches. Plus why share and delete work one file at a time.
A file in your library can leave it two ways: as a public link that anybody can open, or as a share with named people who have to sign in. They look similar in the dialog. They are not similar at all, and picking the wrong one is the mistake this page exists to prevent.
Share is available from a file’s three dot menu, from the file open in the viewer, from the document editor, and from the selection bar when exactly one file is selected. All four open the same dialog.
What the person you send it to sees
The link opens a page with the file on it: the image, the video with a player, or the document, under its name and a line saying who shared it. Nothing else about your account is on that page, and the person does not sign in.
A link that has been revoked, or that has passed its expiry date, says so plainly instead: This link is no longer available.
A public link is unlisted, not private
Anyone holding the link can open the file. They do not sign in, they do not need a Protocol account, and Protocol does not know who they are. The link is hard to guess, and that is the only thing protecting it. Forwarded in an email, pasted into a group chat, or left in a browser history on a shared computer, it keeps working for whoever finds it.
For a demo video of a squat, that is fine, and it is exactly why the feature exists.
For anything belonging to a client, it is not. The common way this goes wrong is progress photos. A coach wants to send a client their own before and after, reaches for Copy link because it is one click, and puts a photograph of that person on the open web. It stays there until somebody remembers to revoke it.
Use named sharing for anything that belongs to a client. If you do use a link for something client related, set an expiration date when you create it, and revoke it when the conversation it was for is over.
You can set or change the expiry at any time, and the line under the link tells you where it stands: either a date, or Does not expire. Revoke public link kills it immediately, and anyone who tries the old link after that lands on the “no longer available” page.
Sharing with named people
The second tab searches people by name or email and lets you pick as many as you like. Each person gets either Can view or Can edit, and there is a switch for whether they are emailed about it.
A shared file stays in your library. It appears for them under Shared with me, where they can open and read it but cannot reorganise it, because it is still yours. That is described in The content library.
Everyone you have already shared the file with is listed at the bottom of the dialog with their permission, and each one has a cross that takes their access away again.
Share works on one file at a time
There is no bulk share. Select fifteen files and the Share action is not offered; select one and it is. A share is a record about a single file, so an action that appeared to share fifteen would have to be fifteen separate shares behind the scenes, with fifteen separate links to keep track of and revoke.
To share a set of files, share them one at a time, or put what you want to hand over into a program or a message instead.
Deleting several files
Delete does work on a whole selection, but it is worth knowing how. There is no single operation that removes many files at once, so Protocol deletes them one after another and shows you where it has got to: the name of the file it is working on and a count, 2 of 4.
That count is not decoration. If a bulk delete stops partway, some files are gone and some are not, and the count is how you know which is which. If any file could not be deleted, Protocol names it. Nothing about a delete can be undone, so read the count before you close it, and if it stopped early, run it again on what is left rather than assuming the whole thing failed.
Back to: The content library