alishobeiri

The way I was approaching it was from the maintainer perspective where I want to engage with the community of stargazers. My experience with that has been fairly good and folks are responsive.

I had a friend who used the original script to reach out to a repo similar to what he was hoping to build and actually got a lot of good feedback as well, so from the small sample size it has generally been positive.

To give a way to protect against potential abuse, I created a form on the homepage where anyone can be asked to be excluded from a StarHog list. Though I am open to hearing suggestions if you might have any as well.

Sorry that is my mistake, to clear it up: 1. Yes the API key here is the OpenAI key 2. The tool at the moment cannot be pointed to local models, though I am adding support for that. My focus right now is the following, in order of priority: - Self-hosting the proxy server (priority) - Adding support for local models

Ideally having the self-hosting would also allow people to switch things to use their own models (hosted) as well if need be.

Hahaha I was not aware of the Slack alternative too hahah point taken

Hahahah point taken, in all fairness, I only knew about Threads (the social media app) when I posted and so I thought it wouldn't overlap. I was worried the word `thread` might overlap in a parallelism sense though wasn't aware of the networking stack. Anyways I appreciate the feedback :)

Hahaha I take the point, I thought I was slick because I got the thread.dev domain and so didn't consider SEO as much. One of the alternate titles we considered was `Show HN: Thread.dev` instead of just `Show HN: Thread` to minimize overlap but last second opted against it. Anyways appreciate the feedback.

Definitely, it is something we are super focused on as it seems to be a use case that is important for folks. Opening up the proxy server and adding local LLM support is my main focus for today and will hopefully update on this comment when it is done :)

It's something we are considering, I think Hex provides a lot of features that aren't available in existing local notebooks (SQL, reactive cell execution) that we hope to integrate for sure. I think both Jupyter and VS Code are really strong players in the space so one of the concerns we have was around whether the feature set would be compelling enough to get people to switch. (Which is why we wanted to post to test the initial reaction :))

The reason we wanted to focus on running things locally is that we were both engineers at big companies in the past, and we didn't have access to tools like Hex but we could use local tools. Our initial thesis is to bring the best development experience local and see if there is an opportunity to build a business model around collaboration features.

I think that's another really good point, it was the first time we have open sourced a project or a library so I wasn't really sure how to best position it with the license. The reason I opted for AGPL was mainly because of the worry that someone bigger could come along and take what we've built and we'd kinda be stuck without an option.

If you'll humour me for a second, just for my own knowledge, I would love to learn a bit more about how you think about the license when deciding whether to use a tool like this or not?

Yeah I think point is very fair, the reason we host it on a proxy server was that we wanted to enable first time users to be able to use it without putting in an API key, the only way we could think of doing that without exposing the key was to host the tool on our own server. We looked to a tool like Cursor that users might be okay with that.

I the think the feedback is very fair that when an API key is present that all the calls should happen locally, and that is something I will take as an action item on us to improve.