Welcome to BHV Discussions!

[pradeeban]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[shivamyadavrgipt]

Myself Shivam Yadav 3rd year B.tech CSE from Institute of national importance I like the project i would love to build it.

[pradeeban]

@shivamyadavrgipt welcome and thank you for your interest!

[shivamyadavrgipt]

@pradeeban 1. what about the UI of Beehive will it be similar to the Beehive using react for frontend and flask for backend and clerk for authentication and authorization .
2. how does BHV will be different from Beehive if we use same structure and techstack to build it give some clarity.
3. I want also to participate in gsoc26 is it right way to do.

[pradeeban]

1. Definitely we should get rid of Clerk and all the other complex stuff. A local deployment of something such as a Kong API gateway could be an option. That way, you get the API key generated and maintained locally. Another one to consider is Dockerization. We reallly need to make it easier for users.
2. At this point, it is still vague in mind. @mdxabu has some better/clearer thoughts. My point is, right now, Beehive is bloated and not something that can be installed without a serious technical knowhow. That won't be a scalable situation.
3. Of course!

[shivamyadavrgipt]

@pradeeban sir, Here is my view. I think using Kong API there is issue of facing similar issue like clerk. As objective is to make it lightweigh.We can use:

1. Local Auth (simplest)

• Email/password signup/login
• JWT-based session management
• Roles (User/Admin)
• Google OAuth with minimal config
  This gives you:
• Simple API-based auth
• Easy admin/user separation
• Minimal configuration

2. we gonna use react vite for frontend part and UI will be similar to beehive .

[sk66641]

@pradeeban Yes, this looks good, a simplified file storage setup for images, along with a lightweight database like SQLite to store metadata.

[XxSURYANSHxX]

@pradeeban @mdxabu @sk66641, So can I move forward with the development part ?

[shivamyadavrgipt]

@XxSURYANSHxX I have been already working created a folder strucure completed the authentication and authorization and created simple UI with jinja (as we discussed previously). @pradeeban Should i create a PR now so everyone could keep contributing or first should complete the basic features so it should look similar to Beehive (as BHV is lighter version of Beehive) then create a PR ?

[XxSURYANSHxX]

@shivamyadavrgipt Sure once the basic structure has been integrated by your PR, we all can contribute to it.

[shivamyadavrgipt]

@pradeeban Yes, this looks good, a simplified file storage setup for images, along with a lightweight database like SQLite to store metadata.

@sk66641 sqlLite is good for structural data.Here, I think using mongoDB will be good as it provides flexibility to store multiple images for single user maybe we needed in future to track the progress of disease.

[XxSURYANSHxX]

Hello @pradeeban, @mdxabu, and everyone!

Just wanted to introduce myself. I'm Suryansh Maurya, a 2rd-year CS student who really enjoys building things with Python.

I found the BHV project and I've been reading through the README and this entire discussion thread. The goal of the project is fantastic, and I honestly love the conversation here about prioritizing simplicity and ease of installation.

The final decision to go with Flask + Jinja2 instead of a heavy front-end framework like React totally makes sense. It cuts out so much potential bloat and avoids the "serious technical knowhow" problem @pradeeban mentioned.

Building on that simple-first approach, I was thinking about what the rest of the stack could look like. What if we went with:

Database: SQLite? It’s just a single file, has zero setup, and is already built into Python. It seems perfect for keeping things lightweight and directly answers @sk66641’s question.

Authentication: Flask-Login. It’s a standard Flask extension that handles user sessions and roles (User/Admin) really cleanly, without needing any complex external services.

Deployment: And for that "single command" install goal, a simple Dockerfile and docker-compose.yml would be perfect.

This way, the entire system is just a self-contained Python app that anyone can get running with docker-compose up.

Like some of the others here, I'm very interested in contributing to this project and would love to be considered for GSoC 2026.

[mdxabu]

Hello @XxSURYANSHxX, thank you for your interest in this project. We would like to use MongoDB for it.

[naurjhanvi]

Hi everyone!
I'm Jhanvi, a sophomore engineering student majoring in AI.

I’ve been analyzing the "single command" requirement, and I completely agree with the Flask + SQLite approach discussed here. I have pushed a working prototype of this core architecture here: [https://github.com/naurjhanvi/BHV_Prototype]. To keep the installation simple, I avoided Docker for the initial setup.

Regarding the authentication discussion, I plan to use GitHub OAuth instead of the standard Flask-Login. Since the project requires us to create private repositories for users programmatically, we need the repo scope token. OAuth handles this automatically, whereas standard login would require users to manually manage PAT.

I am currently working on the OAuth integration. Let me know if you have any thoughts on the current file structure.

[mdxabu]

Hello @naurjhanvi, Thanks for showing interest in our project. We would like to use MongoDB for it. Users with github account can use the GitHub OAuth, but users can also log in with the simple login feature / Google OAuth, I think we want to have multiple login/sign up options! Basic was username and password.

[naurjhanvi]

Hello @naurjhanvi, Thanks for showing interest in our project. We would like to use MongoDB for it. Users with github account can use the GitHub OAuth, but users can also log in with the simple login feature / Google OAuth, I think we want to have multiple login/sign up options! Basic was username and password.

Thanks for the clarification @mdxabu .
I completely agree with the feedback given on previous PRs about saving the core implementation work for the GSoC coding period. I don't want to rush ahead and implement the full multi-auth logic right now.
However, since the current prototype that I built uses SQLite, I will make a minor configuration update to the repo just to swap the backend connection to MongoDB + Docker. This ensures that I have a proof-of-concept for the proposal.

[pradeeban]

@naurjhanvi That sounds like a solid plan. Feel free to submit pull requests with your prototype/Proof-of-concept implementations. But we are keeping the pull requests "on hold" (i.e., not merging) during the GSoC application period as we do not want to hinder the creative process of the applicants (and that as an empty repository, you have a large degree of creative freedom).

[Vedant936-ai]

Hello Everyone , myself Vedant , currently a sophomore at IIT Bombay one of the top most universities in the world . @pradeeban Sir I would like to know that BHV project is still ON ? As it seems that contributions were hardly made and that too months ago .
I see a potential in this project and would like to contribute to it solely as I found that University of Alaska Anchorage is doing great for the social development of Alaska . I have experience in Python , ML , FastAPI , MongoDB , Git , Json and basic Typescript and

[pradeeban]

@Vedant936-ai yes, the project is on. Just it is in its early stage at this point.

[Rithvik1709]

Hello @pradeeban , Myself Rithvik I have strong hands-on experience building Python-based healthcare and medical data systems. My previous project DocuMed, an AI-powered medical platform that handles image uploads, symptom narratives, secure storage, and analysis, closely matches BHV’s core workflow of storing patient-provided images and text. I have already implemented end-to-end pipelines involving Flask backends, databases, local file storage, and AI modules, which directly translates to BHV’s minimal architecture. I also have experience integrating APIs, automating workflows, and building clean, simple UIs suitable for clinics. With this background, I can efficiently develop BHV’s image-narrative management, optional emotion analysis, and GitHub-based storage with strong security and usability.

Looking forward to contribute for GSOC'26
Thanks

[Code-ashiq]

Hi everyone!
I'm Ashiq, a final year computer applications student with experience in Python, FastAPI, Django, MongoDB.

I'm interested in BHV mainly because of the minimal approach of the project and the single-command concept making the installation easier for people lacking technical expertise.

Looking forward to contribute and hopefully be part of GSoC 2026.

[amitpandeyyy01-max]

Hey everyone, I’m Amit, a CS student learning web dev and good with Python.
I’ve read through the whole BHV thread — really like how it focuses on keeping things simple and light with Flask + MongoDB instead of a heavy stack. The single-command setup idea makes a lot of sense for smaller clinics. I’d love to start contributing and prepare for gsoc26. What’s the best place to begin ?

[codebreaker32]

Hi @pradeeban
I noticed the requirement for the system to be runnable via a single command to avoid bloat. Do we prefer a server-side rendered approach (like Jinja2 templates with Flask/Django) to keep it monolithic, or should we be looking at containerizing a separate frontend/backend using Docker Compose to maintain that 'single command' ease of use?

[pradeeban]

@codebreaker32 Containerizing is a good option too. But we should keep the tech stack simple even without containerizing. This is exactly why we keep the pull requests on-hold without merging, as we do not want to simply repeat building another Beehive (although BHV is somewhat a Beehive-lite).

[ChaitanyaChute]

Hi @pradeeban, @mdxabu

I’ve built a small, separate prototype repository to validate BHVs
single-command, minimal stack assumptions using Flask + Jinja + MongoDB,
based on the direction discussed in this thread earlier.

I intentionally kept functionality minimal and avoided advanced features
such as full authentication, in order to focus on architectural clarity.

Repo: https://github.com/ChaitanyaChute/BHV-prototype

I’d really appreciate any feedback on the overall architectural direction
or areas that you feel need reconsideration.

[Ramzan-Khan-786]

Hi everyone!

I'm Ramzan Khan, a Second Year ,B.E Student with experience in Software Development using different tech Stacks like Python and JavaScript.

I'm interested in BHV because I have created similar type of project but with different configurations and it was for Distribution purpose .
I have gone through all the documentations ,discussens ,and threads of BHV project . As all the PRs are on HOLD for GSoC coding periods .
I have clarified some of my doubts with @mdxabu and started Working on my PR .I will raise PR soon .

Looking forward to working with you all,Thank you😊!

[pradeeban]

Hi @Ramzan-Khan-786,
Yes, we keep the PRs from GSoC applicants on hold for this project (and will merge eventually if needed). The rationale is the repository is empty and as we consider this to be a light-weight alternative to Beehive, we need to make sure it doesn't become another bloated or complex software like how Beehive currently is. Pls feel free to make your PR to demonstrate your prototype or ideas (although we will still mark those as on hold.)

[Ramzan-Khan-786]

I completely understood that keeping it Light-weight and simple is our main aim . I am working on the PR keeping BHV project as simple as possible. currently I am designing the complete workflow of the BHV project to keep it single run project.

[pradeeban]

That is awesome! Thanks.

[safiya2610]

Hey @pradeeban
I’m Safiya from IIIT Lucknow, currently pursuing a B.Tech in Computer Science and Artificial Intelligence. I'm open-source contributor for the past 2 years. Based on our earlier discussion about keeping BHV lightweight, I’ve started building a simple prototype using FastAPI + HTML/CSS (Jinja).
I’ve implemented basic signup/login with Google OAuth (no Clerk), and I’m currently adding image upload and delete functionality for art/photography use cases. I’m also exploring a simple, secure upload architecture and fuzzy logic for poorly tagged or undescribed images.

[yadavchiragg]

Hi @mdxabu @pradeeban,

I have 10 PRs submitted. Would you prefer I:
A) Wait for current PRs to be reviewed before submitting more
B) Continue contributing to new features
C) Focus on improving existing PRs based on feedback

I want to be helpful without overwhelming you with reviews!

[pradeeban]

@yadavchiragg feel free to work on more PRs. But as discussed elsewhere, we aren't merging them into the (currently empty) BHV repository. The PRs could be a learning experience for you and for you to highlight them in your GSoC proposal. Also remember that quality is more important than quantity. So, yes, best to improve on the features you already contributed too!

[yadavchiragg]

Thank you for the guidance, @pradeeban!

I'll focus on improving the quality of my existing contributions.

Would you prefer I:

• Create new PRs for improvements?
• Update existing PRs?
• Focus on specific features first?

Also, I'm starting my GSoC proposal draft. Are there specific project ideas or priority areas for GSoC 2025 that I should focus on?

Thanks for your time! 🙏

[pradeeban]

@yadavchiragg If it is for BHV, we are simply marking all the PRs as "On hold" as it is a new product with an empty repository. We want to make sure the design remains minimal (otherwise, we might as well simply have yet another Beehive.) Pls go ahead with your proposal and share once it is ready for review by email if you like to have early comments.

[yadavchiragg]

Thank you @pradeeban!
I understand the focus on keeping BHV minimal and distinct from Beehive. For my proposal, I'd like to focus on security improvements and performance optimization while maintaining the minimal design philosophy. I'm starting my proposal draft now and will share it for your early review. Are there specific areas or features you'd like me to prioritize for GSoC 2025?

[deveshanim3]

Hi @pradeeban, @mdxabu
I, Devesh Singh, a 2nd-year student in Computer Science, looked at the project, and it aligns well with my tech-stack and interests, so I want to contribute to this project. After going through the requirements of the project, it should be minimal and simple so non tech person can run it in a single command.

I am thinking of working in :

• Backend: FastAPI, used in a strictly minimal, monolithic, Flask-like manner.
• Database: MongoDB as the primary datastore, with simple, flat data models and minimal setup overhead.
• Frontend: Server-rendered templates (like Jinja2) with minimal JavaScript since we need minimal frontend.
• Auth: basic email and password with Google OAuth.
• Image Storage: Local filesystem as the default.

The overall goal is to keep BHV easy to install, understand, and maintain. Happy to adjust this direction based on feedback before proceeding.

[sarthak-foss]

Hi everyone! 👋

I’m Sarthak Khandelwal, an undergraduate Computer Science student with hands-on experience in Python (Flask/FastAPI), SQL databases, and building lightweight backend systems.

I’m particularly interested in contributing to BHV (Project Idea 2) as it strongly aligns with my experience in backend architecture design and minimal deployment-focused systems. The emphasis on privacy, simplicity, and a single-command deployable architecture resonates with how I prefer to build software — clean, modular, and scalable without unnecessary complexity.

I’ve been following the BHV discussions closely and am excited to start contributing while working toward a solid GSoC 2026 proposal around it. I’m looking forward to learning from the mentors and collaborating to build something meaningful and impactful.

[sarthak-foss]

Hi everyone👋,
After carefully analysing Beehive and the goals for BHV, I wanted to share the direction I am considering right now,
So my approach is:

1. Replacing the separate React frontend and Flask backend setup with a Single Python Application to reduce the deployment complexities.
2. Use a relational database, defaulting to SQLite for smaller clinic deployments and PostgreSQL for larger-scale or data-intensive use cases.
3. Implement email + password authentication as the default method, with optional Google OAuth or OTP support if needed.
4. Store images on the local filesystem and maintain a relational database index for metadata to keep the system lightweight and simplify backups.
5. Keep data federation and fuzzy analysis as optional modules so the core system remains focused on secure storage and access.

Currently, I am working on simplifying the backend-frontend separation as my first step towards improving deployability.

Any suggestion, feedback is highly appreciated to ensure my alignment with the Project's Vision.

If my approach seems appropriate, I'd be more than happy to share a detailed weekly execution-implementation plan.

Thank You 🙏

@pradeeban @mdxabu

[pradeeban]

At this point, there are surely several alternatives if we are developing something from scratch. I just remind to keep the architecture minimal and less complex (to avoid the mistakes made in Beehive).

[n-apawti]

Hi everyone,
My name is Nathaniel, and I am a third year Computer Science student (Data Track) at TU Delft, with a minor in Applied Econometrics. I'm highly interested in the BHV project for GSoC 2026!
I think I am a good candidate, because I built and deployed scalable microservices and database (vector) search systems during my previous internship. Furthermore, i built a Python-based NLP pipeline to extract and index metrics from unstructured documents, This experience directly translates to the color-emotion research module and the data extraction goals of BHV.

The project description mentions a goal of a "single command" installation. I am considering proposing a stack using FastAPI with SQLite (to avoid the need for a separate DB server) and potentially Streamlit (or jinja2) for the minimal design so the codebase will be in a single deployable python package.
Furthemore i would like to introduce a storage avstraction layer with the PyGithub libary to intercept image uploads and route them directly to private github repos.

Does this approach align with your vision for keeping the deployment lightweight for community clinics? @pradeeban @mdxabu

Im looking forward to contribute!

[pradeeban]

sounds good, @n-apawti

[mdxabu]

@n-apawti @sarthak-foss, Thanks for showing interest in our project!

[rluo-23]

Hi everyone, I'm Rui Luo, an MS CS student at Northeastern University with a background in Python backend development and an interest in healthcare applications.

I set up and ran Beehive locally to understand what BHV is moving away from. The core friction I observed: OAuth/email setup, system dependencies, and multiple running processes create a real barrier for deployers at clinics, exactly what BHV's "single command" goal addresses.

Beyond the deployment architecture, I've also been thinking about the research module. For the fuzzy color–emotion module — based on the IEEE paper referenced in the description, how do you envision the results being stored and surfaced in the UI? This will affect whether I scope it as an optional module behind a feature flag or something more tightly integrated.

My current direction: FastAPI backend, SQLite default (PostgreSQL upgrade path), local filesystem storage with optional GitHub private repo sync via PyGithub, local email/password auth as the zero-setup default with optional Google OAuth. I'd be happy to share a draft proposal for early feedback when you have a moment.

Thanks for your time!
@mdxabu @pradeeban

[mdxabu]

@rluo-23, Thanks for showing interest in our project!

Sure, Go Ahead.

Regards,
Mohamed Abdullah

[pradeeban]

Yes, valid observations, @rluo-23. Especially for an app that targets marginalized communities (and for an app that specifically aims to have just 20 known users per deployment), we are very bloated in Beehive. Beehive could have its own use cases (perhaps for a larger, managed, deployment). But for localized tribal health systems, it does not scale.

I agree with your direction. Please feel free to email the draft proposal when it is ready. Pls cc the mentors in a single email (rather than two separate emails).

[sk66641]

@pradeeban @mdxabu , I have implemented the initial components like authentication for signup/login and the image upload and storage pipeline,

but for the fuzzy color–emotion module mentioned in the project idea, should the analysis be performed locally when an image is uploaded, or should there be a architecture so the images can be exported to a separate research tool, keeping the core BHV lite?

or, should the analysis part be implemented locally within BHV initially in a modular way so that the research component can later be separated into an independent service if needed? Understanding this will help me structure the system architecture and scope appropriately from the perspective of the proposal.

Thank You.

[mdxabu]

Good progress 👍 I think for now it’s better to implement the fuzzy color–emotion analysis locally within BHV but in a modular way.