Proposition of Roll-Call Event

[celinecamacho]

Here is a description of the roll-call event associated messages. We will create the JSON-Schema once everyone agrees on the proposed messages.

Create Roll-Call

Create a roll-call event. The event can be started in open mode, in which case a start time is specified, or in future mode, where the start time is not specified. If it is in future mode, the organizer needs to open the roll-call by using the “Open Roll-Call” message.

• object: “roll_call”
• action: “create”
• name: String
• id: base64 string SHA256("roll_call"||lao_id||creation||name)
• creation: integer, [Timestamp]
• start: integer, [Timestamp] (optional)
• location: String
• roll_call_description: String (optional)
• scheduled_time: integer, [Timestamp] (optional)

Open Roll-Call

Open a roll-call event. The event can be opened multiple times, the start time corresponds to the new open time.

• object: “roll_call”
• action: “open” or "reopen"
• id: base64 string SHA256("roll_call"||lao_id||creation||name)
• start: integer, [Timestamp]

Close Roll-Call

Close a roll-call event. If the event was reopened, then it will need to be closed again. Because of this the event can be closed multiple times, and the end time and attendees are overwritten. If the event was reopened, the start time we specify when closing the event should be the time when the event was reopened, not the time when the event was opened the first time.

• object: “roll_call”
• action: “close”
• id: base64 string SHA256("roll_call"||lao_id||creation||name)
• start: integer, [Timestamp]
• end: integer, [Timestamp]
• attendees: array base64 string

@dedis/student20_pop @haoqianzhang @lhmerino @pierluca

[imaximumGit]

Create Roll-Call

Create a roll-call event. The event can be started in open mode, in which case a start time is specified, or in future mode, where the start time is not specified. If it is in future mode, the organizer needs to open the roll-call by using the “Open Roll-Call” message.

I think it will be good that a future roll-call has a start time or an announce time. This will allow the front-end to show the roll-call in the future events list at the correct place

[SFulpius]

It is a good idea.

[RaulinN]

Good initiative! I have a few suggestions/questions for you:

• should the location string in roll-call creation be optional like in the meetings?
• why can't we set a end time for the roll-call if we specify the start in the roll-call creation
• I do not understand what the following line means:

  The end time corresponds to the start time specified in a create/open message

• could we change the roll-call object into a roll_call object to stay coherent with the update_properties method?

[SFulpius]

should the location string in roll-call creation be optional like in the meetings?

Yes we can make it optional.

why can't we set a end time for the roll-call if we specify the start in the roll-call creation

A roll-call event works as follows: we start the event, scan the keys of all attendees, then finally close the event. The end field indicates when the roll-call ended. As we don't know in advance how long it will takes to scan all keys, we don't know when the event will end. Also note the start field is used only when creating the event in open mode. It cannot be in the future.

I do not understand what the following line means:

The end time corresponds to the start time specified in a create/open message

A roll-call can be reopened after it was closed, by example if the organizer forgot to scan the key of an attendee. What we want to say, is that if we reopen an event, the start time we specify when closing the event should be the time when the event was reopened, not the time when the event was opened the first time. We will improve the description, as it was not very clear.

could we change the roll-call object into a roll_call object to stay coherent with the update_properties method?

Yes, good idea. Also note that it is an informal description, and things like names of fields are likely to change in the final version.

[pierluca]

A few things to consider:

• Why would you re-open a roll-call as opposed to creating a new one? Re-opening implies that you're actually not doing a roll-call at one point in time. A new one allows to preserve the property that the roll call at a time T covers all the attendees at that time T.

• How would the keys be scanned? This is an important part of the process, arguably the tough one, and I don't see a description of it here. Any ideas? @lhmerino and @haoqianzhang might be able to help you out if you have a draft proposal, as they're our in-house PoP experts :)

• The id: base64 string SHA256(lao_id||creation||name) might overlap with other elements. I'm thinking we might want to add a flag in there to indicate the event type (meeting, roll-call, etc.) as two different event types could somewhat easily have the same id.

[SFulpius]

Why would you re-open a roll-call as opposed to creating a new one? Re-opening implies that you're actually not doing a roll-call at one point in time. A new one allows to preserve the property that the roll call at a time T covers all the attendees at that time T.

We decided to reopen a roll-call because it was described in the user interface specifications:

In the Closed state, the roll-call display shows the start time, recorded number of participants, and a “Re-open Roll Call” button in case the organizer accidentally closed the roll call (and confirmed it) or something happened in the real world (“Wait, you forgot these people!”) to justify re-opening a closed roll-call. For transparency, records of each re-opening and re-closing time get recorded indelibly in the underlying log that gets broadcast, witnessed, etc.

How would the keys be scanned? This is an important part of the process, arguably the tough one, and I don't see a description of it here. Any ideas? @lhmerino and @haoqianzhang might be able to help you out if you have a draft proposal, as they're our in-house PoP experts :)

I think we addressed this during today's meeting.

The id: base64 string SHA256(lao_id||creation||name) might overlap with other elements. I'm thinking we might want to add a flag in there to indicate the event type (meeting, roll-call, etc.) as two different event types could somewhat easily have the same id.

You're right. We will change it, and also change other events.

[celinecamacho]

• should the location string in roll-call creation be optional like in the meetings?

From what I understood, roll-calls are supposed to give the proof-of-personhood. In my opinion, the location shouldn't be optional because the roll-call is an in-person event.

[pierluca]

id: base64 string SHA256("roll_call"||lao_id||creation||name)

you might want to do something slightly different from this :) you should decide on a fixed-length for the flag that will be used for all the events ("roll_call", "meeting", etc.). If the "roll_call" part is variable length (i.e. "meeting" / "roll_call" / "poll" ), you run into a common problem with hashing of concatenated variable-length strings, that is hash("roll" || "_call123") == hash("roll_call" || "123")

The event can be closed multiple times, the end time and attendees are overwritten

Why do you want to allow multiple closings?

[SFulpius]

id: base64 string SHA256("roll_call"||lao_id||creation||name)

you might want to do something slightly different from this :) you should decide on a fixed-length for the flag that will be used for all the events ("roll_call", "meeting", etc.). If the "roll_call" part is variable length (i.e. "meeting" / "roll_call" / "poll" ), you run into a common problem with hashing of concatenated variable-length strings, that is hash("roll" || "_call123") == hash("roll_call" || "123")

You're right. I think for our usage using one byte to store the flag should be enough.

The event can be closed multiple times, the end time and attendees are overwritten

Why do you want to allow multiple closings?

In the case of a reopening (maybe we forgot to scan the key of an attendee, so we reopen 2 minutes later), we will close a second (or more) time the roll-call. I think it is not clear from our description, but we can only close the event more than once if it was reopened.

[RaulinN]

@SFulpius @celinecamacho It might be overkill for our case, but I can still propose a solution for your hashing problem:

What about that, instead of using one byte as you said in your previous message, we padded each of our different "event types"? For example, let's say our fixed length is 8, then the roll-call would stay as rollcall (because len("rollcall") == 8). The (hypothetical) event type "poll" could then become poll0000 if we use zeroes as padding character.

This resembles what @pierluca proposed

you should decide on a fixed-length for the flag that will be used for all the events

but slightly more flexible in the sense that we could have more consistent names. Let me explain: while the "poll" event could easily be transformed in a fixed 8-length string (for example eventPoll), the "meeting" event (7 letters) would be harder to transform while keeping a logical name... meeting_?, eMeeting? evt_Meet?, ...

I am not saying this is better, but I just wanted to have your input on this method. The advantage of this method is that we don't need to agree on a predetermined mapping from "event type" to a particular byte. On the other hand, it would probably introduce a (very slight) overhead when parsing/serializing event messages.

[SFulpius]

Thank you for your proposition. Looking at it quickly, it would work, but I don't think we should use it for two reasons:

• It is not extensible: what if we have an event which length is bigger than 8? Then we need to either augment the size of the flag, or to cut a part of the name.
• I think it is way too complicated for what we need. It it much simpler to just have a mapping from a event type to a byte than to have use a padding scheme. It will lead to less implementation errors.