Sharing documents and spaces

Get Help
1

Quick question: I have a couple of different topic areas I’d like to share with their respective stakeholders who are not fibery members or guests on my account.

In the past, when I ‘shared’ a space, that worked well. However, It seemed all shared spaces were visible to all people who have the link. Meaning, I couldn’t share one space to one private URL and a different space to a different private URL; effectively all published spaces were visible to all people who had the URL.

Is that still the case? How do other people in a similar situation handle this? I don’t want one group of stakeholders to be able to browse the shared documents and spaces that pertain to the other stakeholder groups(s).

2

Is there a reason why the stakeholders couldn’t just be guests (no cost)?
Is it because it is inconvenient to force them to create an account? Or because it’s a hassle to add all the relevant people via space sharing? Or because you want to share widely without caring/knowing who exactly needs to see the info?

1 Like
3

I have a few reasons. In general, there’s significant friction to get people to register as guests, which can be a barrier in many cases. If someone intends to work with me for a period of time, I could make the case that they should join as a guest, but even then if they are not formally part of the team or paid directly by the company (for example, entrepreneurship adviser or incubator staff), they lack incentive to register for yet another account at yet another service.

1 Like
4

If it were possible to share with specific people so that there was virtually no friction for them to become guest users, would that be acceptable?
Or do you actually need to allow access the space for users whose email you might not know (i.e. anonymous users)?

1 Like
5

Could you elaborate? It’s hard for me to answer without knowing what is meant by ‘virtually no friction’. For some, providing one’s email address as a sort of registration key required to access information is the friction, so I’m not clear on what your proposed low friction alternative looks like or how others might respond do it.

The current system of sharing is almost a substitute for a website, which I like. I think Notion encourages folks to use their sharing feature in that way. It’s best if it can function in this way. I’m trying to envision a scenario where I’d want a website to be only visible to some people, and how I’d handle that. I guess I could make a fake email account and then create a fake guest account in Fibery and then just provide the fake email address and Fibery password to my stakeholders so they don’t have to provide their own email addresses. Not such an ideal workaround.

6

So here’s how I could imagine a low friction sharing could work:
In the sharing settings for a space, there is an option called ‘invite someone into this space’ with a box where you can type in the email address of someone you want to share the space with. After you have typed it in, and clicked the button, an email is sent to that person, which contains a ‘magic link’ (this is a mechanism which allows the recipient to visit a website and automatically be logged in, without requiring them to provide a user name or password).
Once they click the link, they can look around, and do all the things that a logged in guest can do (and in the background, a guest account has in fact been created for them).

Typically, if they try to use the magic link after a certain time has elapsed, or re-use it, then they are not immediately allowed in, but can be invited to request a new ‘magic link’ via which they reconfirm their identity.

It’s how medium.com does logins, and doesn’t require creating a password or anything, but the user is uniquely identifiable when doing anything on the site.

If some visitors are regulars, once they’re in, they can be offered the option to create a password, so that they don’t need to use the magic link mechanism going forward.

Overall, this is much different from simply distributing a space share url via which any person can visit the site. Such a ‘sharing url’ allows anonymous access, which can be an advantage or a disadvantage.
Advantage: the url can be shared with colleagues so that anyone with the link can see what’s happening within the space
Disadvantage: anyone (good or bad) who knows the link can see what’s happening in the space, so it relies on security-through-obscurity to ensure that sensitive info does not leak out.

Anyway, if that advantage is important, then a sharing url may be the way to go, and perhaps Fibery should introduce a mechanism to limit public sharing on a per spaces basis - which is your original request I suppose.
But if you actually only want to share with specific people, simply providing Fibery their email addresses and letting it take care of granting them guest accounts with low friction (e.g. with magic links) might be preferable.

I hope this explains why I was asking

2 Likes
7

Thanks for explaining. I’ve disliked the magic link kind of approach when I’ve encountered it myself elsewhere. If someone is already consenting and is OK creating a user account with their email address, then a magic link might be helpful as it reduces the need to type it in manually. Even then, it has gotten confusing once I’ve tried to re-access the content a couple of weeks later. If the magic link is expired, then it leads to more hoops to jump through, sometimes with head scratching. Out of curiosity, is there a reason Fibery prefers that? For example, is the number of registered users (guests or otherwise) used as a metric for investors? Is there a hope that registering as a guest might make someone more likely to convert to a paid user?

I think the bigger form of friction is for those that just don’t want to create more accounts and registrations, which often lead to getting signed up for email spam, etc etc.

I do like the solution you hint at, such as Fibery allowing us to have listed and unlisted shared spaces. There could be a public url in the way it’s currently handled for all public spaces, and separate url’s for each unlisted space. Or something like that.

8

I will experiment with guest users for now, and see how it goes. I suppose I can try create my own categorized guest accounts and hand those emails and passwords out to people, too.

9

There is no preference for it at all. I was just using it as an example of a low friction sign-in method, in order to tease out whether or not you actually preferred anonymous access (and you don’t care if there is the risk of data leaking out) or whether limiting access to specific invited users is desirable (in which case user identification is required, but friction must be reduced).

I’m still not sure where you stand to be honest :man_shrugging:

(and neither is yet available, but feedback might help determine which to prioritise)

2 Likes
10

I definitely prefer offering anonymous access to separate shared spaces. I currently use Squarespace to manage a web domain, and for any given webpage, there’s a toggle for whether or not the page should be indexed by search engines. So an unlisted page that’s not searchable is relatively private. Yes, people could share the link externally, but that would be an OK risk. Where more security is needed, I could avoid sharing publicly and just require users to register a guest account.