Check room ID doesn't exist when creating a new room

[matrix-org]

Check room ID doesn't exist when creating a new room

[rreuvekamp]

Claiming

[rreuvekamp]

src/github.com/matrix-org/dendrite/clientapi/routing/createroom.go:94

// TODO (#267): Check room ID doesn't clash with an existing one, and we
// probably shouldn't be using pseudo-random strings, maybe GUIDs?

This is something we can discuss.
From my understanding, the upside of using UUIDs is that you get a certain guarantee they are generated such to not collide easily. They should be more random then what util.RandomString currenly does (using math/rand).

Namespaces in UUIDs are not something we're interested in, because room IDs will already have the server name as suffix.

To me it seems like UUIDs are therefore overkill for this.

I'm not sure if things will break with larger room IDs. It seems synapse currently uses 18 character room IDs. I guess it wouldn't break things because room IDs are normally stored in their full form (including server suffix), so their length is dynamic anyway, but I can't say for certain.

[erikjohnston]

Yeah, UUIDs seem overkill for this, I'd probably set it up to ask the room server if the room id is free. Though that would require us to reserve our use of that room id on the room server, so that two client API instances can't race between asking about the room id and persisting the new room.

[rreuvekamp]

Yeah, UUIDs seem overkill for this

Okay :)

Though that would require us to reserve our use of that room id on the room server

Or maybe the createroom of the roomserver's API should (optionally) just return an error if the room ID is already taken, therefore making the checking and registering one operation (from the clientapi's view). I'll take a look.

[erikjohnston]

I don't think there is a createRoom API on the room server, instead we just start shoving down events that create the room through the normal stream.

[erikjohnston]

I'd imagine the flow looks something like:

1. Reserve the roomID from the room server (either the room server returns a free roomID or we'd want to retry if the randomly generated roomID had already been taken)
2. Construct the events that create the room
3. Send the events down the stream to the room server

[rreuvekamp]

Ahh that explains it! So we need to know the room ID to use before the process of building and sending the events can start.

Working on it.

[rreuvekamp]

Was a bit busy last weeks, but I'm still working on it!

[Cnly]

Hello @rreuvekamp, are you still interested in and working on this issue?

[rreuvekamp]

Yes! I didn't realize I stop had it open, sorry.

I'll check to see if anything has changed in the meantime regarding those parts, and fix the issues that still need fixing.

I've got time on Sunday, so that will work out.

[kegsay]

I don't think we need this. #794 (comment)