accessible not working as expected?

[vsatmydynipnet]

I crated a room, set the permissions:

Default permissions: +read, -write, -upload, -accessible

1 Admin already is in the room. The non admin user joined via the browser room link list and is able to enter the room and see the messages appearing?

I assumed -accessible means - invite only - ?

[majestrate]

On Thu, 16 Feb 2023 07:14:43 -0800 vsatmydynipnet @.***> wrote:

I crated a room, set the permissions:

Default permissions: +read, -write, -upload, -accessible

1 Admin already is in the room. The non admin user joined via the browser room link list and is able to enter the room and see the messages appearing?

this sounds like the expected behavior

I assumed -accessible means - invite only - ?

yes

-- ~jeff

[vsatmydynipnet]

Sorry for being blind, but

invite only would mean for me some admin invites with "add friends" in the mobile or desktop app and the room is unaccessible otherwise..

but the invite only room is listed on the index page created by sogs if you go there with the browser and any user, also not invited ones, which knows the url of the index, maybe because they are already in other rooms, can see the room and join without any invite by scanning there or copying the room link?

[jagerman]

The permission model here is additive, not subtractive; in order for someone to be unable to join a room they need to have the read permission removed. But read itself implies access, and so granting read implicit grants access even if the access bit is not set. So what you want for a private room is either:

1) -read, -write, -upload, -access 2) -read, -write, -upload, +access

The difference between them is that case 1) prevents random users from seeing any info about the room at all, while case 2) allows them to access room info (such as its name and number of active members), but still not to join and read messages in the room.

If someone has +read permission (either because the general setting grants +read, or because they have specific permissions that grant +read) then access is implied (effectively this means +read, -access doesn't do anything and is effectively the same as +read, +access).

[vsatmydynipnet]

Thank you very much for that info!

[vsatmydynipnet]

Sorry to come back to this one again. But testet:

-read, -write, -upload, -access

then the room is not more shown on the index page for the browser. But joining by invitation does not work, nor with copying the link in the room (which would be expected to make it invite only) but also with invitation by the admin user in the room. Clicking on the invitation results in "unable to join community" too.

If i remove the permissions while already being inside the room as non privileged user i can not write and also not read messages typed by the admin user.

-read, -write, -upload, +access

I can join by clicking the invite link, but still not type a message, nor see the message typed by the admin user. And the room is shown again on the index page, which would make it accessible for everybody again, even unable to type or read.

For me curently only the "read-only" room works as expected. Is it possible that there is something wrong with the permission system?

[jagerman]

There are currently some limitations on the Session side in terms of being able to manipulate the permissions; in order to properly make an invite-only room, you'd have set to set it up as -rwua, then to invite someone, grant that individual user +r (or +rwu or whatever else you want them to have), then give them the room URL to join.

That middle part -- of being able to assign granular individual permissions -- isn't implemented yet in Session, which makes this setup difficult to use in practice.

One thing current Session can do is to assign moderators to a room, so if you're comfortable having a room full of admins you can make the room private, add moderators via the Session client, then have them join the room. (We use this setup for some internal team rooms on Session).

We do have better mod controls on the roadmap for Session to be addressed in upcoming months, so hopefully it won't be long until this situation gets more usable.

[jagerman]

Actually I quite like the idea of being able to generate an "invite token" that you can send to a user to join a room without having to know their session ID in advance; there could probably be some variations such as max number of uses, and expiry on the token, so that you could make an invite room that lets a user join and automatically get assigned configured room permissions. (This will still need Session-side support, but I'm going to open it as a new issue).

[vsatmydynipnet]

Thank you for your info.

• If I add moderators in Session messenger, not on CLI, they all are admins and would be allowed to remove other admins as I was reading. Means it would be required to add their moderator privileges on CLI?

• The token idea is pretty nice, especially with the max usage add-on, aso. But I do think, to make sure only the right ones joins, there should be so invite based on session id too. like creating some time based auto deleting invite record in the database and if the user joins, deleting the invite and adding +rwu to this user

[jagerman]

If I add moderators in Session messenger, not on CLI, they all are admins and would be allowed to remove other admins as I was reading. Means it would be required to add their moderator privileges on CLI?

Unfortunately, yes, that's also part of the same current Session limitations. It's really only useful as a model if you trust everyone you're adding into the room.

[jagerman]

But I do think, to make sure only the right ones joins, there should be so invite based on session id too. like creating some time based auto deleting invite record in the database and if the user joins, deleting the invite and adding +rwu to this user

For a specific user, you'd just grant them +rwu right away and send them the regular room URL to join; they wouldn't necessarily need a specific invite code.