Update the room creation API spec to include new keys: 'preset' and 'initial_state'

[erikjohnston]

No description provided.

[ara4n]

What happened to the preset that auto-ops the person you invite (for 1:1 chats which are owned equally by both parties)?

[erikjohnston]

I believe we decided that we were just going to do private_chat and public_chat for now. It is easy to add another preset if you want?

[kegsay]

Both of these are shared? I thought one was joined?

[erikjohnston]

private_chat used to be joined, but that caused confusion and so is being changed back to shared in the next synapse release

[kegsay]

Ahh okay, not going insane then! :D

[kegsay]

LGTM modulo clarifications - I will use this information to make a YAML file for /createRoom once this is merged.

[ara4n]

Can you remember what the rationale was for ignoring auto-opping? Right now the preset is not doing anything that we couldn't do just by setting join rules - i thought autoopping was the main thig we wanted out of it...

[erikjohnston]

No idea

[ara4n]

okay - given the function (from memory) looks to be implemented in synapse but deliberately turned off, can you dredge back through the logs or commits or whatever to find out why? It seems wrong to add preset functionality to the spec if it doesn't buy us anything new, and suggests the presets we're defining may be wrong.

[erikjohnston]

It seems wrong to add preset functionality to the spec if it doesn't buy us anything new...

It never will, its simply there as a convenience. To get the "everyone has ops" functionality you would just need to set the power levels power levels appropriately in the "intiail_state" key.

If anything the presets are more about giving consistent suggestions for what "private" and "public" rooms should look like (by default).

Can you remember what the rationale was for ignoring auto-opping?

The only reason I can think of is that you wouldn't necessarily want to give initially invited people ops in a private chat, and it might be a bit surprising that initially invited users and subsequently invited users are treated differently by default.

[ara4n]

It never will, its simply there as a convenience. To get the "everyone has ops" functionality you would just need to set the power levels power levels appropriately in the "intiail_state" key.

Okay, but it's not just convenience (shortcuts for setting initial state) but trying to provide good defaults for clients to use. Whilst clients can set default power levels in initial_state we risk them doing so very inconsistently, breaking Matrix's UX.

If anything the presets are more about giving consistent suggestions for what "private" and "public" rooms should look like (by default).

Agreed - if you include "1:1" as one of the presets.

Can you remember what the rationale was for ignoring auto-opping?

The only reason I can think of is that you wouldn't necessarily want to give initially invited people ops in a private chat, and it might be a bit surprising that initially invited users and subsequently invited users are treated differently by default.

So the use cases are: a) create a private group chat" (eg for a team discussion) where by default you want only the creator to have ops.

However, there's also b) create a 1:1 chat, where as per spec-7 i thought we were all agreed that you want both parties to control the convo - eg rename it, change its photo, etc.

Can we add a 1:1 preset to support this behaviour?

[erikjohnston]

Can we add a 1:1 preset to support this behaviour?

Yup, what do you want to call it?

[erikjohnston]

(I don't particularly fancy calling it "one to one" if its not one to one specific and with all the discussion about exactly how we want to actually do one to one in the longer term.)

[leonerd]

If you're going to create an "invite-only" room, then why do you have to "op" (by which I presume "give a high value for power level") each user individually? Why not just set that the user default value is, say, 100? That achieves the effect that anyone in the room has full power of 100. Now creator, initial invitee(s) and any other subsequent ones are all treated equally.

[ara4n]

"private_chat_shared_power"

[ara4n]

leo: this is all that the preset does. it just does it via a preset or macro for convenience.

[kegsay]

I dislike the name private_chat_shared_power - we should be describing what the intention is rather than an attribute of the preset (shared power). I think this because we may want to modify these attributes as we add in more powerful config options, and then the name of the preset becomes outdated at best, misleading at worst.

The point of these presets from what I know is to provide "sensible defaults" depending on what you're trying to do. AFAIK we want each preset to map to a use case:

• Public group chats (e.g. #matrix:matrix.org) which we call public_chat.
• Private group chats (e.g. team discussions) which we call private_chat.
• Private messaging (aka 1:1)

I agree with @erikjohnston that calling it one_to_one or equivalent is misleading because the preset is not enforcing that in any way. When we do have the ability to enforce it, that would be a good preset to have. As a result, I feel it is premature to be adding in this preset until that feature is implemented.

If we really must have this preset now now now (which I feel is a mistake to rush) then what we're describing is a private group chat where everyone has ops. This may be desirable for close friends who you trust not to mess everything up. Something like open_private_chat, private_friend_chat or trusted_private_chat would be more suitable I think.

[ara4n]

trusted_private_chat wfm.

I continue to think it is a huge mistake to make rooms strictly 1:1 and stop people ever being invitable. If our history visibility semantics are eventually sorted out, we should always be able to protect the history of a room when folks chose to invite in a 3rd party.

On 1 Oct 2015, at 10:12, Kegsay notifications@github.com wrote:

I dislike the name private_chat_shared_power - we should be describing what the intention is rather than an attribute of the preset (shared power). I think this because we may want to modify these attributes as we add in more powerful config options, and then the name of the preset becomes outdated at best, misleading at worst.

The point of these presets from what I know is to provide "sensible defaults" depending on what you're trying to do. AFAIK we want each preset to map to a use case:

Public group chats (e.g. #matrix:matrix.org) which we call public_chat.
Private group chats (e.g. team discussions) which we call private_chat.
Private messaging (aka 1:1)
I agree with @erikjohnston that calling it one_to_one or equivalent is misleading because the preset is not enforcing that in any way. When we do have the ability to enforce it, that would be a good preset to have. As a result, I feel it is premature to be adding in this preset until that feature is implemented.

If we really must have this preset now now now (which I feel is a mistake to rush) then what we're describing is a private group chat where everyone has ops. This may be desirable for close friends who you trust not to mess everything up. Something like open_private_chat, private_friend_chat or trusted_private_chat would be more suitable I think.

—
Reply to this email directly or view it on GitHub.

[kegsay]

I also like trusted_private_chat fwiw.

I continue to think it is a huge mistake to make rooms strictly 1:1 and stop people ever being invitable. If our history visibility semantics are eventually sorted out, we should always be able to protect the history of a room when folks chose to invite in a 3rd party.

What is the aim of this? Alice and Bob have a PM going on. Bob invites Charlie who may or may not be able to see the history depending on m.room.history_visibility? If the visibility is "joined" then from Charlie's point of view it is equivalent to him joining a brand new group chat since he can't see history, at which point why isn't this another room?

[ara4n]

I continue to think it is a huge mistake to make rooms strictly 1:1 and stop people ever being invitable. If our history visibility semantics are eventually sorted out, we should always be able to protect the history of a room when folks chose to invite in a 3rd party.

What is the aim of this? Alice and Bob have a PM going on. Bob invites Charlie who may or may not be able to see the history depending on m.room.history_visibility? If the visibility is "joined" then from Charlie's point of view it is equivalent to him joining a brand new group chat since he can't see history.

I am assuming we have better opt-in history semantics as per spec-210; letting users say whether they are willing for their history to be viewable by others. If two people in a 1:1 both opt into sharing history with others, there should be nothing stopping them from inviting others into that room imo. We could possibly still create the room with an default invite threshold that needs to be reconfigured to allow this, but I hate the idea of arbitrarily crippling rooms to permenantly be 1:1.

—
Reply to this email directly or view it on GitHub.

[kegsay]

Okay, that works for me on the condition that we have proper opt-in semantics for history.

[ara4n]

yay! 💃

[kegsay]

This PR LGTM after we reword to trusted_private_chat

[erikjohnston]

done

[kegsay]

LGTM

[ara4n]

lgtm