Open tonygentilcore opened 8 years ago
My feeling is we should punt on this until we have more clarity around the specs/designs for the next version of rechat (that both iOS and web will support, which we may already). Then we can determine what the requirements are in terms of capabilities not yet supported by Other.js and tackle those instead of tweaking what (I think) is a stop-gap.
Can you elaborate on how you expect rechat to change?
/cc @mtkurlowski
I'm not sure how rechat currently works on web. My understanding is rechat is triggered by a chat complete result associated with a MessageOptions
feature which takes a message and returns results presenting actions the identity is allowed to take on the specific message.
In my mind the steps would be:
MessageOptions
feature handles the event in Other.js and returns string results for the message ("edit", "delete", "rechat")Rechat
feature to return its own results (channels) and set a "message panel action"The requirements for the above are:
MessageOptions
featureMessageOptions
feature knows what results to provideAFAIK, 1-4 are not currently supported by Other.js and what I think we should be focusing on adding.
Totally agreed. You're describing #109. This issue is about a feature being able to see the messages in a channel which unlocks a variety of different functionality. To your suggestions about prioritization, that's in line w/ what's laid out here https://github.com/other-xyz/other.js/milestone/12. Let's keep this issue on topic please.
@tonygentilcore OK. In my mind, exposing channel messages would be available via a request to the events
endpoint. Is the goal of this issue to provide an additional mechanism which returns messages that have already been fetched by the embedder?
Via the
Chatternet
interface. This'll let rechat work as expected instead of the hack here: https://github.com/other-xyz/other.js/blob/master/builtins/rechat.other.js#L21