Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: "Michael Ströder" <>
Subject: [Galene] Re: autolock always locks
Date: Thu, 14 Jan 2021 18:29:19 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 1/14/21 6:17 PM, Toke Høiland-Jørgensen wrote:
> Michael Ströder <> writes:
>> On 1/14/21 4:26 PM, Juliusz Chroboczek wrote:
>>>>>> Are non-ops automatically kicked out when the last op leaves (or when
>>>>>> the group is locked again with /lock)?
>>>>> No -- the assumption is that they were present at the meeting, so they're
>>>>> authorised to be here.
>>>> RFE: How about an autokick group option. ;-)
>>> Opinions from others?  Featuritis or useful feature?
>> Just to add some rationale:
>> I'm not so much concerned about GDPR issues because this can mostly be
>> dealt with at orga level. And believe me, I'm concerned about privacy in
>> general. Otherwise I wouldn't spend my spare time running my own video
>> conference server.
>> But compared to privacy issues I'm much more frightened of someone
>> abusing my unattended Galène installation for something really bad
>> which does real harm to human beings and triggers police investigation
>> etc. I was even considering time constraints in my reverse proxy or
>> similar to tighten it at least a bit.
>> So IMO an autokick option would not only be featuritis.
> So autokick would make sure to empty the room when the last op leaves,
> is that it?

Yes, but preserve current behaviour of autolock.

> My corporate video chat solution leaves that as an option for me when I
> leave the room (I can just leave, or I can check a box to kick everyone
> out when I do). Wouldn't that be more useful than a per-room setting?

That would be useful and comfortable for users.

But if the ops' connection fails and this question never appears I'd
prefer that everybody else is kicked out. Well, maybe kick out after 1+
or 2+ minutes of ops' inactivity / absence or similar to avoid kicking
the whole conference just because of temporary ops connection problem.

Thinking about this some more behaviour of autolock could also be like this.

Uuuh, I'm feeling bad for having too much ideas without being able to
submit pull requests...

Ciao, Michael.

  reply	other threads:[~2021-01-14 17:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14  9:19 [Galene] " Michael Ströder
2021-01-14 12:36 ` [Galene] " Juliusz Chroboczek
2021-01-14 12:38   ` Gabriel Kerneis
2021-01-14 12:55     ` Juliusz Chroboczek
2021-01-14 12:58       ` Michael Ströder
2021-01-14 15:26         ` Juliusz Chroboczek
2021-01-14 15:41           ` Michael Ströder
2021-01-14 17:17             ` Toke Høiland-Jørgensen
2021-01-14 17:29               ` Michael Ströder [this message]
2021-01-14 17:33             ` Juliusz Chroboczek
2021-01-14 17:40               ` Michael Ströder
2021-01-17 20:30                 ` Juliusz Chroboczek
2021-01-14 12:56     ` Michael Ströder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='[Galene] Re: autolock always locks' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox