Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spell out that 'rooms' are not chatrooms #416

Open
ara4n opened this issue Jan 19, 2019 · 2 comments
Open

spell out that 'rooms' are not chatrooms #416

ara4n opened this issue Jan 19, 2019 · 2 comments
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@ara4n
Copy link
Member

ara4n commented Jan 19, 2019

at the least, we should clarify this. ideally we might rename rooms to be a more generic term, but the horse has probably bolted on this one. Plus we can't rename all the m.room.* events out there

@turt2live turt2live added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Jan 19, 2019
@alphapapa
Copy link

As we discussed in #matrix-spec, since "rooms" are so much more than "chat rooms," and are really a DAG of events, calling them "rooms" can be very confusing. The connotation brings, shall we say, baggage, that IMO makes it difficult for people new to Matrix (like me) to understand the mental model. It becomes more confusing as "rooms" are repurposed for features like presence, etc.

Thinking of my own meager client, and the "room"-related code I'd repurpose for such features, it creates "mental friction" for me. Personally, since "rooms" are really graphs of events, I would prefer if they were called "graphs," and then "rooms" would be graphs which served the purpose of a chat room and used a defined set of event types, etc.

Matthew raised the point that calling them "graphs," while technically accurate, might scare away developers who might think they need to understand graph theory to work with the API (c.f. the objections raised to event "mixins").

He also noted that it's been several years now, so it might be too late to make such a change.

However, since 1.0 has yet to be reached, it would seem to me like the time is ripe to make such a change, to try to get it "right" before the almighty 1.0. Since we're--hopefully--talking about a spec which should last decades, I think it behooves Matrix to fix ambiguities and confusing issues like this before going forward.

My 2 cents. Thanks.

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
@aschrijver
Copy link

I can well understand that "the horse probably bolted" but I have this same feedback as @alphapapa that somehow this "room" feels like a wrong abstraction, and that it conveys that the protocol is stretched from its original use cases to now have this concept gain much broader meaning. Just had a small fediverse exchange with @turt2live who pointed me to this issue. Guess it is fine if it remains "Room", but that it should be made very clear to devs to let go of the notion of "chatroom". To free their minds, as it were 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

4 participants