Eric Burel

No currently ['guests'] will allow 'members' too as far as I understand? Because getGroups add them automatically

Ok I understand. I should take a look at the commit history when I have some spare time.

Yeah indeed it's Sacha's commit from 4 months ago ^^ Commit: a15874d3ad59a9d98d494045b4256d63224eb705 @SachaG this indeed ends up being a breaking change in existing app from 1.13 to 1.14

I've updated the proposals on the top post. I tend to like "Proposal 2", we keep the hierarchy (it really makes sense for CRUD operations, even if it makes guest-only...

I've played around with Redis in the past. I am not sure you will gain a lot in this scenario, as Redis is really just... an inmemory cache, but running...

Yeah that's totally right. I'll read the docs you listed to be more knowledgeable on this part, that's very interesting. I tend to trust the DB and use indexing in...

Not sure, i didnt experience the bug myself so it might be related to some other input

Currently `guest` actually means `anyone`. We should clarify the way to disallow a route for members but allow it for non connected number. Thanks for opening this discussion it's interesting.

Thinking about this, I think we are right that we should have thought groups a bit differently, with no ordering between "guests" and "members". We would have `["anyone", "guests", "members",...

The only case I can think about is for routing, you don't want connected people to access the sign in route, they should be redirected. We have a few routes...