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

Extend linear chat to discussions/threads? #55

Open
FynnBe opened this issue Apr 25, 2024 · 6 comments
Open

Extend linear chat to discussions/threads? #55

FynnBe opened this issue Apr 25, 2024 · 6 comments

Comments

@FynnBe
Copy link
Member

FynnBe commented Apr 25, 2024

I propose to allow discussions/threads for a model instead of a single chat per resource version.

Questions about a model for example may be resolved and thus certain 'parts of the chat' could be collapsed, etc...
To simplify things a bit we could have these discussions on the resource level instead 'per version'. Each (staged/published) version can become a discussion/thread.
Maybe one discussions.json could have the following layout:

[
    {
        "title": "staged/1",
        "status": "open",
        "messages": [
            {
                "author": "system",
                "message": "tests failed: [logs](https://example.com)",
                "timestamp": "..."
            },
            {
                "author": "Maintainer X",
                "message": "you shall not pass",
                "timestamp": "..."
            }
        ]
    }
]

What do you think @oeway ?

@FynnBe
Copy link
Member Author

FynnBe commented Apr 25, 2024

or we do this properly with existing chat software, e.g. matrix (could be integrated on website, e.g. https://github.com/osousa/livematrix, or https://cactus.chat/)

@FynnBe
Copy link
Member Author

FynnBe commented Apr 25, 2024

@oeway could https://cactus.chat/docs/server/self-host/ be integrated into a hypha service?

@oeway
Copy link
Contributor

oeway commented Apr 25, 2024

Hi @FynnBe,

It's always possible to use these, however, most of these involves heavy and complex databases, and does not integrate well with our existing services.

It will bring back to something similar to our previous solution which is also open source can be self hosted: https://github.com/utterance

We make the changes because to make it easier to integrate with our hypha login and our s3 file storage, and we don't really need much for the chat part, I would rather call it "comments" rather than chat.

Our current design makes the chat messages as the metadata for the models, and allows easy modification from CI, it will be simple and easy to maintain.

I do like the idea of integrating all the chat messages in one file, so the client can filter it out by "thread/resource version/etc.". However, the same can also work with separate files, and it's even better since we don't need to download everything but only the selected thread. I discussed this with @jmetz and we think it's better to stick with separate files for version, but the frontend can decide how to stitch them together.

@FynnBe
Copy link
Member Author

FynnBe commented Apr 25, 2024

how about one discussions.json with topics and a chat file for each topic?
would just disentagle topic from version (or allow for non version specific topics)
and we can have standard version specific chats (without even changing the files?)

The reason I bring this up is precicely the previous utterance solutions that leads to one long (mostly outdated) chat history that isn't easily hidden away

@oeway
Copy link
Contributor

oeway commented Apr 25, 2024

how about one discussions.json with topics and a chat file for each topic? would just disentagle topic from version (or allow for non version specific topics) and we can have standard version specific chats (without even changing the files?)

The reason I bring this up is precicely the previous utterance solutions that leads to one long (mostly outdated) chat history that isn't easily hidden away

For simplicity, I would rather go for a single thread, and if it's goes too long, we can implement pagination on the client side. And github issues/PR are also single thread, we have super long thread, e.g. our meeting minutes bioimage-io/bioimage.io#28

It's a matter of optimisation on the UI. And it's good to hide old messages anyway. It doesn't seem to worth to put a lot of effort to support an entire forum like grouping by topics, or adopt more sophisticated solution. I would rather move with something quickly forward, just works for our case.

@FynnBe
Copy link
Member Author

FynnBe commented Apr 25, 2024

github issues/PR are also single thread,

but you can create independent issues/PRs!

But yes we can leave this for future improvements 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants