feat: add is_active conversaiton - #212
Conversation
| Ok(convos) | ||
| } | ||
|
|
||
| /// Whether the conversation is loaded and usable. |
There was a problem hiding this comment.
[?] @jazzz I add this function to check wether we have a specific conversation in the mls client or not, basically what we need is a function to help the devs to determine if the current user can message(if they have that conversation, if they're still a member, or if they have the permission to send message to that conversation) maybe a better naming would be can_message, wdyt?
There was a problem hiding this comment.
I love where you head is at - Developer QOL is important.
I think the function makes sense, but I'd want to make sure that its clear to developers about when the function should be used. That would help with determining an appropriate name
The 3 current conditions are:
- ConversationExists with that Id
- Still a member
- Send Permissions
- The entry point for retrieving conversation_ids (
list_conversations) only returns valid ones. - Currently there is no ability to remove members from a conversation - but this will be needed in the future.
- This one is the most unique requirement as some conversations may be read-only (ie broadcasts)
If you really wanted to add this feature pre-emptively I would consider adding can_send(convo_id), can_retrieve(convo_id) filter functions that could be used directly with list_conversations().map(<Filter>)
There was a problem hiding this comment.
Definitely, great idea. Will add that in another PR and will use it here.
There was a problem hiding this comment.
If this is a painpoint we should check in with developers and get some quick feedback.
[Dust] Assuming we believe that in most cases developers want "sendable" conversations, my default approach would be to:
Change: list_conversations() -> list_all_conversations()
Add: list_sendable_conversations() which performs the mapping reducing work at the callsite.
But I'm not seeing what you are seeing. What direction would you go?
jazzz
left a comment
jazzz
left a comment
There was a problem hiding this comment.
Theres a pebble that we should sort of a future plan for, else not seeing any blockers.
Changes to client have wider impacts to developers, so lets make sure there is a plan for that.
| self.add_system_message(&format!("── Your Chats ({}) ──", sessions.len())); | ||
| for s in &sessions { | ||
| let active = self.state.active_chat.as_deref() == Some(&s.chat_id); | ||
| let read_only = !self.client.has_conversation(&s.chat_id); |
There was a problem hiding this comment.
[Pebble] As per https://github.com/logos-messaging/libchat/pull/212/changes#r3782651433 we need to be careful here on the public api.
has_conversation implies it returns true if "the conversation exists", however the implementation specifically is focused on whether a developer "can submit new content into the conversation".
These two concepts need to be kept seperate
| Ok(convos) | ||
| } | ||
|
|
||
| /// Whether the conversation is loaded and usable. |
There was a problem hiding this comment.
If this is a painpoint we should check in with developers and get some quick feedback.
[Dust] Assuming we believe that in most cases developers want "sendable" conversations, my default approach would be to:
Change: list_conversations() -> list_all_conversations()
Add: list_sendable_conversations() which performs the mapping reducing work at the callsite.
But I'm not seeing what you are seeing. What direction would you go?
2 participants
No description provided.