Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Add "listed/unlisted" toggle for places. #90

Open
Aitolda opened this issue Jun 5, 2021 · 5 comments
Open

Feature Request: Add "listed/unlisted" toggle for places. #90

Aitolda opened this issue Jun 5, 2021 · 5 comments

Comments

@Aitolda
Copy link

Aitolda commented Jun 5, 2021

Sometimes you may want to have your place temporarily unlisted, but still need to be able to share the link. I imagine this could be somewhere in the "edit" options of places, and perhaps during the place creation phase as well.

@Misterblue
Copy link
Collaborator

A place has a "visibility" setting that can be "open", "friends", "connections", "group", or "private". At the moment, only "friends" and "connections" is implemented. If visibility is not specified, "open" is assumed. This visibility should effect which places a person can see.

@Aitolda
Copy link
Author

Aitolda commented Sep 29, 2021

To clarify, I currently I have a handful of place names I'm intending to use pointed at one domain. The way it currently works it's all or nothing. So if I have that domain up, all of those places appear as having a person in them but point to the same domain.

@Misterblue
Copy link
Collaborator

The attendance for a place is assumed to be attendance of the domain until there is a beacon updating the specific place information. The idea was a Place was just a location bookmark for a domain and, if the place was to identify a specific area of the domain, a beacon-like script would update that place's information with "current" info (the attendance for that sub-area, any updated images for the place, and any updated description).
I am not sure if a standard Place beacon script has been developed. It would need to hold the PlaceId and APIKey for updating the current place information and, whatever logic is needed to count the avatars in an area.
Some of this is explained in the Places doc: https://github.com/vircadia/Iamus/blob/master/docs/API-Places.md

@digisomni
Copy link
Member

Should "private" not achieve the intended effect of hiding it from the list?

@Misterblue
Copy link
Collaborator

Misterblue commented Sep 30, 2021

I'm thinking "private" would work. The issue is here because I don't think it's implemented yet.

That doesn't preclude a rethink of metaverse-server visible User and Place information. The implementation has just "visibility" which specifies the class of people who can see the entry. The original suggestion was for a more restrictive type that was more like Google doc's shared URL ("anyone with the URL can reference"). That would allow sharing of the Place link without making the Place public at all. Just a thought, but there could be a larger discussion about what use cases and features Vircadia should to implement for access to Accounts, Places, Domains, ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants