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

Flexible privacy rules #2

Open
hpx7 opened this issue Oct 5, 2021 · 5 comments
Open

Flexible privacy rules #2

hpx7 opened this issue Oct 5, 2021 · 5 comments
Labels
good first issue Good for newcomers question Further information is requested

Comments

@hpx7
Copy link

hpx7 commented Oct 5, 2021

First of all, I wanted to say this library looks really cool! I think tracking state mutations and broadcasting deltas is a great way to model the data layer for games.

One question I had was how you think about privacy rules. I noticed you have a concept of "access tags" but I'm having difficulty imagining what kind of use cases this can support.

Some use cases I have in mind:

  • for each client, only send them data about the objects near them (within a certain radius)
  • allow for arbitrary rules that govern what data a client can see based on their characteristics (for example, in the game avalon, different characters have access to varying amounts of information based on their role)

Are these use cases that can be modeled using access tags?

I've been working on a framework myself, but the approach I took for privacy was to allow for an user-defined function which can filter a custom view for each user. The downside of the approach is that computing diffs/deltas become much harder, which is why I wanted to explore other ways of modeling privacy.

@udamir
Copy link
Owner

udamir commented Nov 6, 2021

Hi! Thank you for your interest to my library.
Current Tags concept can handle your use-cases:

  1. Set all private objects/properties as private
  2. Use player/role tags to make them visible for player

Check documentation to get more details regarding visibility management

@udamir udamir added good first issue Good for newcomers question Further information is requested labels Nov 6, 2021
@hpx7
Copy link
Author

hpx7 commented Nov 7, 2021

Thank you for your reply!

I've seen the documentation but it's still difficult for me to imagine how you would model something like avalon's visibility rules.

Here's how I do it with my framework: https://github.com/hpx7/rtag/blob/d93e0eac9a1e467cf200013ae3544ee008a8940d/examples/avalon/server/impl.ts#L169-L188

The interesting part is knownPlayers -- you have to show a different set of user names based on the player's role, which defines what information they have access to.

@udamir
Copy link
Owner

udamir commented Nov 8, 2021

The concept is simple and flexible: public objects/properties can be traced by all listeners, but private are available only for listeners with access tag.

Also checkout magx-examples project - for example chat room. In chat example every user have own tag. All messages are private by default and hidden for all users. There are two ways how to make message visible (user can send public and private messages):

  1. add to message public tag, which is shared among all users - message will be visible for all
  2. add user's private tags - message will visible for tag owners

Try to make some experiments with private objects/properties and tags and you will get it.

@hpx7
Copy link
Author

hpx7 commented Nov 8, 2021

I saw the chat example, I think I understand how that works:

  1. you add the user's privateTag to a private message: https://github.com/udamir/magx-examples/blob/b21fef523d824f380c9cd28a91f07acdc1f6597a/src/rooms/advanced/mosx-chat/state.ts#L77
  2. when a user joins, you subscribe to all messages with their privateTag: https://github.com/udamir/magx-examples/blob/b21fef523d824f380c9cd28a91f07acdc1f6597a/src/rooms/advanced/mosx-chat/index.ts#L23

The Avalon use case is more convoluted:

  1. first you look up your role: https://github.com/hpx7/rtag/blob/d93e0eac9a1e467cf200013ae3544ee008a8940d/examples/avalon/server/impl.ts#L170
  2. then based on your role, you learn which other roles you can see: https://github.com/hpx7/rtag/blob/d93e0eac9a1e467cf200013ae3544ee008a8940d/examples/avalon/server/impl.ts#L172
  3. then you filter the players to just those who have a role that is visible to you: https://github.com/hpx7/rtag/blob/d93e0eac9a1e467cf200013ae3544ee008a8940d/examples/avalon/server/impl.ts#L184

Basically it is much more dynamic that the chat example. If you're interested in collaborating, I can try porting Avalon to magx and we can figure out the modeling together?

@udamir
Copy link
Owner

udamir commented Nov 8, 2021

Great idea, try to port your game to magx, I'll try to help you.

As for your case, it also looks pretty simple to implement state filtering using tags.

  1. 'User' is a private object in a state ( map of Users )
  2. Object tags can be dynamically added / changed / removed.
  3. Each role can be a separate tag
  4. Map of users can be filtered using the required role tags, hiding the corresponding users without roles

I have already implemented several games based on mosx state, including very dynamic ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants