Some stuff I've left out, but which may be worth thinking about as the product gets more concrete or in a future update:

• Ability to follow/watch a room without actually joining it -- you'd get notifications, but wouldn't need CAN_JOIN. Some possible interaction with, e.g., T6183, although we could just use "Subscribe" as the underlying relationship in this case since there's no separate "subscribe" state for threads. Not clear if this will actually be important. Use case is, like, a "Security Announcements" room that we might want to let users follow and get notifications from, but not post to.
• Project-like "can leave" / "can unsubscribe" flag, to force everyone to be a member of "global announcements", etc? Use case is a "Company-Wide Mandatory Announcements" room.
• Exactly how invites work for rooms. As specified, we'll get reasonable behavior for a bunch of common cases ("Add participants..") cheaply, and that should give us a good sense of things, but we may want or need to refine this. Use cases might be things like automatically adding users who join certain projects to a room by default, or bulk-inviting users (although T4100 might help here too, by letting you invite members-of-project(X)).

Unclear if these are real use cases yet. I don't think they meaningfully impact any decisions we'd make now, though, even if we do eventually build them.

Does a Project Room inherit the image from the Project, or are these completely disconnected?

As specified, totally disconnected. It's just a room with "Visible to: Members of Project X", like any other object.

So we probably do want T7254 then

Outcome: People in Phacility or Wikimedia projects automatically have this Room in Conpherence.
Outcome: The Photos projects members automatically have this Room in Conpherence.

A note on these: they would currently add the current members of those projects to the room as participants, but not automatically add future members who later joined the projects. I think that's expected/reasonable/desirable, but if we really want projects to be thread members we need to do a lot of additional work.

Or, in particular, a clarification of this:

People in Phacility or Wikimedia projects automatically have this Room in Conpherence.

The actual outcome today, without additional backend work, is:

• At the time when you press the button, all members of the Phacility or Wikimedia projects are immediately added to the room as individual participants (which approximately means they will receive mail and notifications about events in the room).
• Now and in the future, the room appears in browse views for members of Phacility/Wikimedia at the time the browse view is loaded.
• So, for example, joining Wikimedia later allows you to find the room but does not automatically add you as a participant.

Shooting for the moon, if something is v0, v1, v2 "Rooms", we can prioritize as such.

I personally think the behavior as-implemented is correct/desirable. We could change this, but it's a lot of work and I think it's worse from a product perspective. For example, I think this is bad/undesirable:

Rooms support only projects (i assume?)

A use case which contradicts this is public rooms, like your "Social" room example.

Another use case might be a completely private room, like "Secret Pokemon Fan Club", where I only want me and one other guy to be able to add new members and change the title. I can do this with rooms, but not with threads.

Rooms that are All Users or Public are findable/searchable

This is true, but a more general phrasing would be "You can find and search rooms that you have permission to see, per normal policy controls, just like every other object in every other application."

Do Rooms get Moderators/Admins? Do for example we want to display differently in a Support channel

Yes, "Can Edit" controls this.

Is there a way to mass query policy, like given me all joinable rooms? Does that come for free? Maybe group by project joinable first, then all users, public.

Yes, that's free. It's the query we issue in every application when showing a list of tasks, revisions, etc.

Or "free", at least. Where would you group "joinable by specific users", "joinable by users not in project Y", "joinable by members of external LDAP group Q", "joinable when the moon is full", etc., though?

@chad - does that latest mock mean you've decided to get rid of custom titles for messages? I can take care of that in the next diff if so. One product thought of note if you're still on the fence is we don't currently de-duplicate on recipient so title may be relevant / helpful?

I prefer retaining titles for threads, a lot of mine are pretty meaningful. They're also meaningful when things convert up to email.

I think we could get better about the "[No Title]" stuff at some point (e.g., default to showing participants as a title in more cases) but I think they're basically good.

Okay, I'll take a stab at the [No Title] piece then at least.

Yeah, this is really the only part that feels bad to me:

If that just said "Conpherence > hach-que" by default, instead of "Conpherence > [No Title]", that would make get rid of the only rough edge that really rubs me the wrong way, at least personally.

Yeah I had a diff at some point removing [No Title] but it was a hacky mess. Basically, just show people unless they've set a title. I don't have a strong opinion on removing Title support from Messages.

My main concern is that Rooms / Messages don't seem differentiated enough. Maybe just removed policy icons from Messages and see how that feels? My @ stuff is likely crazy overkill.

FWIW, I was pretty skeptical of the icons before we had them but I kind of like them now. :o

maybe we need better icons then for messages? We're re-using the group of people.

I am unable to find a way to create or join new rooms, or edit existing ones. After I created my first room, it seems the UI to do it is simply gone. How can I access it?

Click "Search" in the left menu from within Conpherence, at the top.

I think this interaction isn't very obvious myself; maybe "Browse" would be clearer?

I also think we should consider rethinking letting users do things one way and then immediately taking that away from them. The empty state could instead say "Use 'Browse' to join or create rooms." in small text, which would teach users that those operations exist and how to access them. The current UI shows that the operations exist, but teaches users something that immediately stops working.

Click "Search" in the left menu from within Conpherence, at the top.

Ok, in the grey menu on the left side, where my room is listed and below it says "Messages" and where I see the list of users I have been writing to in private threads, there should be a "search" button? There is none. Screenshot (I cannot use drag&drop to upload files, thus I have to upload the image to an external server.)

On a sidenote:

• I think having a "Rooms" header above the list of rooms might make the UI a bit more intuitive.
• Then you could also add a "+" button next to it, which would create new rooms and messages.
• Conpherence seems to be the only application, where new objects are not created using "+ Create <XYZ>…" buttons in the upper right corner.

Do you not see this?

I think he's talking about the ApplicationSearch interface, not Conpherence.

Or maybe I'm wrong and he's behind HEAD?

It appears what you show in your screenshot is present, but hidden behind the "Phabricator" logo: Screenshot

# git rev-parse HEAD
89ae6851b3104eedeee84de3d03150d68e1b17ec

See T5095 , approximately.

Is there a specific reason you haven't either resolved or ignored that setup issue?

The issue is conduit.deprecated.user.addstatus, which is impossible to fix. I do not want to ignore it either, because I want to monitor the problem for several more days until I am sure that really nothing uses that call anymore.