Auth re-think

[stephenrs]

Is your feature request related to a problem? Please describe.
A quick summary of my experience with CL (with hopefully not too much whining)...

I got it initially set up smoothly and quickly working with my OAI Assistant, and was overjoyed at how close it got me to a final product out of the box. Pretty great docs...pretty solid-looking project...overall glad I chose it rather than other options I had considered.

Unfortunately though, that joy quickly turned to prolonged suffering as I am still struggling to make sense of and make the CL authentication system work for my (Web App) use case...when I don't even need CL to do auth in the first place...and I don't understand why it is forcing me to use an auth system that I don't need that is full of bugs and not fully thought through. Really frustrating.

So, for me, the distance between hello.py and the real world has been vast.

Please take all of this as simply honest feedback intended to be constructive and informative. I'm eternally grateful and respectful of the work so far that has produced CL, and I'm hoping for the best for the project as the future unfolds.

I'm not in your shoes, so I don’t know what the vision or the plans are for Chainlit/LiteralAI, so I’ll just offer my personal perspective and hope that maybe some of it aligns with your thinking.

Here are some of the problems I've encountered trying to use the Web App/header-auth approach:

• custom headers and the Authorization header are not passed through to header_auth_callback, so the only way to make use of the callback to create a user is to use (httponly) cookies or some other less secure approach to get the token.
• no provided way to tell CL that a user has logged out
• ‘token’ is stored in localStorage…bad idea, bad key name...this defeats the purpose of authenticating users because it circumvents more serious security mechanisms and efforts.
• when chainlit has been secured (via .env params), it is not necessary to pass an access_token to use copilot. copilot always opens
• if an auth header callback is defined for a copilot setup, it is ignored
• since copilot doesn't care about authentication and has no awareness of the logged in user, it is not possible to track the user in the persistence layer (eg, LiteralAI)
• ‘display_name’ always gets set to None on a cl.User object when it is extracted from an auth token…so what is the point of providing it? Wouldn't it be nice to be able to use it in a greeting in the UI, for example?
• the header auth callback function seems to be called an arbitrary number of times. I considered implementing a webhook so auth tokens could be fetched from the callback (based on session), but realized how dangerous and non-performant this might be given how unpredictable calls to the function are.

Some of these problems affect all users, not just header-auth users, but overall, the header-auth implementation just feels like a dangling afterthought.

Describe the solution you'd like
Although I might be blinded by the bias of my own use case, I don't understand why auth is part of CL at all - although I can understand the genesis of the desire to provide a "complete GPT business in a box" for people. So my perhaps extreme desire is that auth is removed completely. It gets in the way for developers and makes the CL project heavier and harder to maintain and grow than it needs to be. It should at the very least be optional. See my rationale below.

Describe alternatives you've considered
From my (perhaps biased) perspective, there are 2 fundamental problems related to the handling of auth in CL:

1. Confusion with persistence
The current implementation has blurred the lines between authentication and persistence, kinda treating them as if they are the same thing when they are actually 2 very separate and distinct things. This is an object/system modeling question.

Technically speaking, in order to take advantage of persistence-related features, all CL needs is a User. It doesn't have to be involved or responsible for authenticating that user. So, there should be hooks to allow developers to easily provide a User without having to interact with CL's auth system.

The "magic" of getting persistence-based features by implementing authentication seems like a neat idea at first, but it is difficult to reason about because they are different things. It's also not hard to imagine a use case that would want one but not the other of persistence vs authentication, and right now that is not possible because they have been lumped together. It's an unnecessary and limiting dependency.

2. Value proposition and product scope
As far as I can tell, the core value proposition of CL has two primary components:

• To provide a simple layer of abstraction between developers and LLM providers (and middleware like LangChain)
• To provide a customizable but ready-to-go UI

Authentication is not on that list. Identity providers like Auth0 are in the business of making it easy to secure any app, relieving app developers from working too hard for authentication/identity. So, an app like CL that attempts to do part of this job for them, IMHO, is reaching beyond the scope of its role in a larger system and overlapping in an awkward and seemingly unnecessary way.

The responsibility of identity/authentication more naturally falls to consumers of CL ("left as an exercise for the developer"). CL shouldn't be worried about authentication because it doesn't need it to fulfill its core value proposition. Auth is not a mission-critical feature for CL itself, but it has been implemented as if it is. This is about AI/GPT and building end-user applications, but I've personally spent more time struggling with CL's auth and reading CL's code than I have on improving the training of my model... and customizing the UI is extremely limited.

When the long list of open issues has gotten under control and production blockers (like #1263) have been handled, maybe adding authentication hooks would make more sense. From what I see here in github and on discord, combined with my own experience, getting CL production-ready is difficult or impossible, depending on the needs of a particular use case.

I guess maybe some people might want “an authenticated GPT in a black box with guardrails, exposed directly to the internet” solution, but I guess I’m not one of them. And, it seems to me that people like me who install python modules, rather than using one of the existing SaaS/hosted products with embeddable widgets, probably want more control than Chainlit currently provides with regard to customization. So I'd personally prefer to see the limited project resources going toward that, rather than a multi-tentacled authentication system.

This is particularly significant given that CL is circumventing/breaking any serious security setup by storing access tokens in localStorage as mentioned above. This also speaks to how much trust one should have in how seriously CL considers auth/security. I get the sense that the focus of the auth implementation in CL is primarily to make persistence work, not to provide security (#1127, #1101).

Based on what I've seen so far, I would also tend to expect that there will be an unending flow of bugs/issues related to the integration with auth/identity providers as they evolve and as the number of use cases expands. At the same time, LLM providers, related tools and use cases will also be evolving and expanding.

Does the project really have the resources to also chase the evolution of identity providers and related use cases in a rock-solid and secure way in the context of this reality? As far as I can tell, auth/security is not the project's area of expertise, core value, or the reason people choose CL, and it likely never will be, so just let somebody else (experts) do it...at least for now. It would be great to see the project’s focus be more on features, enhancements, and customization options....which are sooo much easier, fun, and value-generating to implement.

So, In my personal case, I need more control and less non-functional auth clutter than CL is giving me...and although I honestly don't have time to manage a fork of CL because I'm running an existing business, I've found myself without a better choice but to start coding with CL to get it to do what the docs say it does - although I haven't removed the auth yet (please provide hints if you have them). I've come this far and I don't want the time I've already spent to go to waste.

I genuinely hope this is helpful and not too blunt or whiney...and I also hope that you feel both my enthusiasm for the project as well as the pain it has been giving me :)

EDIT: it looks like I'm not the first one to view CL auth as a burden and/or production-blocking, see #1015, #756, #771.

[dokterbob]

Not blunt and definitely helpful. I agree on many points.

Specifically, I think that CL's USP is indeed to provide an easily extendable LLM UI which allows to get started quickly and can then built into production-grade user-facing applications.

That definitely means that auth, custom data layers and even, at the right point, implementing any sort of custom integrations is out of scope for us.

All we need to do is provide a clear API hooks to allow devs to do whatever the bleep they want with it.

Now, that you have written this extensive 'dissertation', and have obviously done extensive study... what do you think about teaming up with us to push forward some of these issues?

Good points to start IMHO would be:

1. In-depth feedback and/or suggestions for a roadmap on Replace custom (o)auth by well-supported libraries #1240
2. An issue suggesting a concrete roadmap to factor out data layers, so that they can be easily provided by the community in a loose-coupled way.

My personal goal, as one of the maintainers as well as an active user with a product expected to graduate into production soon(tm), is to get out a beta-grade v0.2 with a much more stable API in the coming 3 months or so.

[stephenrs]

@dokterbob Thanks for receiving my comments in the spirit they were intended, and I'd be happy and honored to team up with you guys. I really do think it's a great project with the potential to be the defacto standard in this arena.

Let's just make sure we establish the right expectations though because I'm pretty overstretched at the moment. So, I think I'd be more useful, particularly in the shorter term, for offering thoughts and feedback rather than code contributions beyond perhaps small (but seemingly important) things like #1263...and my availability could be intermittent. So, if this works for you, let's go for it.

I'll start by saying that I haven't familiarized myself much with the data layer implementation, but in principle I think it's a good idea to have it or something like it available as an option.

However, loose coupling/pluggable does sound like the right approach overall. Having modules that are specific for different DB types built into the core does seem to go out of scope. Maybe a generic interface and users/community can roll their own adapters...maybe the SQLAlchemy and other existing adapters could be broken out into separate repos, for example(?)

In general, I think observability (and data privacy/ownership) are essential parts of the equation. So, when I first started to think about this, I was happy and relieved to discover LiteralAI. I was also relieved that I wasn't forced to use it and that some thought had already been given to how to get data out of CL on your own. LAI has been an excellent way to get started though, even in its current early form.

My more macro perspective is that the world definitely needs something to fulfill the role that CL does, and OSS makes the most sense. The world also needs GPT observability, and a hosted solution like LiteralAI (with a DIY/OSS option) makes perfect sense.

So, if facilitating adoption of CL and growing its user base is intended to help fuel the LAI effort, this would also seem to make sense. However, I think continuing to have some built-in way to easily get data out of CL without LAI is important.

I'll mention that I've also thought a little about the potential of sending data to Segment.com (or similar), since I already use them as a pipeline for various types of metrics/monitoring. In my particular case, I'm pretty sure I don't want to build/manage a DB to get GPT observability. I might be far from alone.

So, an event-based approach might deserve some exploration (and might suggest that you're right to want to cut the data layer out)...but this might only cover the observability case, not data to support features like chat history...unless a DB was at the end of one of the outbound Segment pipes...hmm...

Can you be more specific about what you have in mind in the context of data/observability and a v0.2?

[nethi]

+1 @stephenrs Nicely summarized several key issues. I am facing some of the very set of issues you outlined. I am using Chainlit in an environment where Auth has arleady been done (with our own JWT token etc) before user goes to chainlit app. So, while using header-auth-callback works, but chainlit goes on to create its own JWT Token (with no options to control its lifetime etc) and expects in HTTP and WS interactions - I have an API gateway that sits in the front and it gets confused with this JWT token that it doesn't understand. I tried to workaround (and monkeypatch) certain chainlit Auth methods (such as authenticate_user etc), but not great luck so far.

Then, there is is the issue of switching users on my non-chainlit outer app but chainlit frontend is unaware with its local-storage persisted tokens and continues to think the logged in user is someone else.

Data layer also has lot of assumptions - we donot consistently pass details of users and request context.

It is such a great project and probably nothing else comes close its approach. I am using chainlit library(with a custom frontend derived from chainlit's frontend) to build a universal chat UI for no-code or low-code agents. But been running into several issues. I understand multiple agents being served by a single chainlit service mayn't have been the original design goal, but it is so close to achieve that. I think, I got to like 80% of the way with some hacks, but now finding real challenges with auth and data layer.

@dokterbob we were discussing in another thread about enhancing chainlit to be more extensible by exposing request context in all its callbacks. Will be great to move forward in this direction - this should ease up some other enhancements in the future and extensibility.

Currently, I am trying to deal with the workarounds in a fork but I am happy to contribute in the discussion and implementation in whatever the way community decides

[dokterbob]

I'll get more in depth on some of the points in the coming days.

For now:

1. We're still establishing specific goals for 0.2 but at the very least we will have a lot of code refactored and covered by unit tests (including data layers). Whether or not we'll be ready to complete pull the data layers out at this point I am not sure yet. If not, rest assured that this is high priority and will probably come in 0.3 (we might deprecate some stuff in 0.2 already).

2. Having request object available in chat_start/auth, please see: Make full Request object available in chat #1213 (comment)

3. @stephenrs Although I might get annoyed by it ;), I tremendously appreciate your critical view. In addition to discussion, would you perhaps be willing to play a role in reviewing mine and other's PR's?

[stephenrs]

Looking forward to more clarity on the goals for 0.2, and I'd also be interested in more clarity on how 0.2 fits into the bigger picture roadmap if possible. The larger vision generally tends to dictate ongoing priorities, but neither seems very clear at the moment, which makes it more difficult to envision where I might best fit in. But let me know if I'm missing something.

Also, thanks for taking my observations and critical thoughts in stride and not letting them annoy you too much :) I've started to view this project more like a startup than a typical open source project, so a higher level of scrutiny has tended to surface. I doubt if I'll be the last though :)

So, I'm also struggling with being a little annoyed at times because I think you would agree that the marketing claims on the website don't seem to line up with the code reality (and it seems that major changes may be coming soon). This kind of thing naturally opens the door to scrutiny if not criticism, and these seem like reasonable questions to raise. Hoping for the best in any case.

[dokterbob]

Luckily for me, I've just started using the product and I've never looked at the marketing. ;)

Realistically, what we can expect in coming releases:

1. Data layers fully decoupled, in a different repo managed directly by the community.
2. Much more test coverage, overall cleanup (less/no code in __init__.py).
3. Many smaller issues (e.g. types mismatch) issues addressed.
4. Work towards factoring out (o)auth stuff.

Particularly 1 and 4 should significantly reduce maintenance load, allowing us to focus more on the core of the product (LLM UI). At the moment 1 will have priority and is likely to land into 1.2. Starting 1.2 I also think we should be rigorous on semver.

Together with the other points it should allow us to foster more effective community collaboration.

[stephenrs]

Hehe, well, I'm not sure how lucky it is to find yourself working with people who so boldly misrepresent the truth on their website and refuse to provide transparency or answer questions about the bigger picture. But I genuinely hope it works out well for you.

Out of curiosity, are you one of the engineers they are hiring?

Thanks for the summary, but I think I'll just continue to monitor the project from the sidelines for now.

[nethi]

@dokterbob For the architecture changes you mentioned, do you plan to describe them ? Does chainlit has a notion of improvement proposal and discussion around it ?

[stephenrs]

@nethi Based on some of @dokterbob 's comments and the issues he has written, prioritized, and assigned, my guess is that they are going to pull this project apart because so much of it is out-of-scope and buggy - prototype quality. Needs a total re-think IMHO, as I've expressed on other issues. So, I would tend to expect that smoothly upgrading to future versions may be next to impossible because of continual and careless breaking changes as we've seen with the last 2 releases.

They are not prioritizing critical issues that have been requested by the community that are blocking users from producing production-grade products. And they are not prioritizing releasing a usable product with each iteration. They are prioritizing issues that address the fundamental flaws in the design of the system - which serve Chainlit's longer-term interests. In other words, the priority appears to be Chainlit the company, not the community.

So, @dokterbob I'd appreciate an answer to my question, and I think the community deserves to know. Since Chainlit is a VC-funded startup who is hiring a team (https://literalai.notion.site/Literal-AI-Chainlit-Careers-cec94330409c405993407f92ca5e99da), I think the community deserves to know who is being compensated to build their product for them and who is not. And, you seem to be working pretty hard for Dan, Willy, and their investors, so if you're not getting compensated, maybe you should be.

This is particularly relevant since I haven't seen any hiring announcements here on github, and because the guys running Chainlit have shown that they have a questionable relationship with honesty and the truth.

So, in all honesty, something about this project just doesn't smell right. This is a great opportunity for @willydouhard to clear things up as the leader of the technical effort because I'm very happy to be proven wrong.

I have nothing against anyone, and starting a new company is hard so I cheer and wish the best to anyone who is trying to do it. I'm also not saying there's anything wrong with what the Chainlit guys are trying to do. But if these guys are pretending that this is an OSS project to get free coding from the community for a well-funded commercial product, people should know about it so they can make accurately informed choices about how to spend their time.

There also needs to be some clarity regarding what Chainlit's role and responsibilities are as the primary commercial beneficiaries of any work that is performed for this project.

Looks like Chainlit might need that Developer Relations job position filled sooner rather than later :)

Hoping for the best.

[stephenrs]

Perhaps the silence here answers some important questions and helps provide some clarity for anyone who is engaging with this project.

[stephenrs]

Just to follow up with regard to the data layer and @dokterbob 's suggestion to remove it:

As I've gotten more up to speed on what's happening in this industry space, I've discovered that the problem of how to get RAG/LLM data out of your app, ready for visualization and analysis, has already been solved by several fairly mature options, and none of them requires coupling with a database.

So, it makes sense to cut data layers out of Chainlit, and it also appears to be quite easy to avoid LiteralAI.

[nethi]

Just to follow up with regard to the data layer and @dokterbob 's suggestion to remove it:

As I've gotten more up to speed on what's happening in this industry space, I've discovered that the problem of how to get RAG/LLM data out of your app, ready for visualization and analysis, has already been solved by several fairly mature options, and none of them requires coupling with a database.

So, it makes sense to cut data layers out of Chainlit, and it also appears to be quite easy to avoid LiteralAI.

Makes sense. However, Chainlit's data layer is mostly focussed on chat history, feedbacks etc - It doesn't deal with any domain data at this point though.

[stephenrs]

@nethi You're correct, but if you wanted to, you might be able to use the User->metadata attribute to persist domain-specific data, however, as I noted there are other options for observability.

Aside from the several direct competitors to LiteralAI that I won't mention, in my case I've been using DataDog for app/infrastructure monitoring for about 10 years and I love it. I recently noticed that they added a new feature this past June specifically for LLM observability, so I'll probably end up using that.

In any case, storing RAG/LLM data in a database via a data layer seems like a bigger lift and maintenance burden than is warranted for most use cases. I've realized that the existing observability solutions transparently integrate into LLM apps and present the data in dashboards without needing an intermediate database. And, I'm assuming I'll be able to handle things like feedback the same way I'm handling other metrics (but I might need to pull more code out of CL to get to the hooks).

[nihadtz]

I have done changes to the project and auth to support display_name, will try to make PR if i find the time.

But at least other people will be able to see what to change.

[dokterbob]

Linking this here: #1207 (comment)

[dokterbob]

Just to follow up with regard to the data layer and @dokterbob 's suggestion to remove it:

As I've gotten more up to speed on what's happening in this industry space, I've discovered that the problem of how to get RAG/LLM data out of your app, ready for visualization and analysis, has already been solved by several fairly mature options, and none of them requires coupling with a database.

So, it makes sense to cut data layers out of Chainlit, and it also appears to be quite easy to avoid LiteralAI.

We're gonna keep data layers as a core feature, just we're gonna leave everything but the LiteralAI backend in there. There's indeed a lot to say for separating persistence from various kinds of observability, although there's also a lot to say for having both in the same place.

Indeed, a lot of options have become available, each with their pro's and cons (for example, at my own company, we really like the depth of insight provider together with the playground capability of Literal).

[dokterbob]

Perhaps the silence here answers some important questions and helps provide some clarity for anyone who is engaging with this project.

The silence means we're shipping FWIW. This kind of tone comes across hostile and not very constructive, I'd like to kindly ask you to be more considerate in your conversations.

You're obviously highly competent and this project can greatly benefit from your contributions. But try and be kind, we're just humans. If you'd like more directly communication, I'm @mathijsfietst on Discord. Though, once again, time I put in debating I'm not coding, not reviewing your PR's and not solving issues.

My main priority is upping this project's state of maintenance, stability and security to (close to) my own perception of what production-grade implies. This takes time, but as you might notice looking at the changelog, we're making consistent steps in that direction.

Just, there's a lot of technical debt and unneeded complexity creating clutter that needs to be cleaned up in order to see the forest through the trees. Any help there: yes, please!

[dokterbob]

@nethi Based on some of @dokterbob 's comments and the issues he has written, prioritized, and assigned, my guess is that they are going to pull this project apart because so much of it is out-of-scope and buggy - prototype quality. Needs a total re-think IMHO, as I've expressed on other issues. So, I would tend to expect that smoothly upgrading to future versions may be next to impossible because of continual and careless breaking changes as we've seen with the last 2 releases.

Actually, no. The user-facing API's are 'stable enough for now', it's why I started rolling unit tests. I want to increase API stability going forward. Although, yes, the idea of starting from scratch and using chainlit's UX as a reference for agentic LLM chat has passed my mind. But that's not in scope nor in the interest of the contributor and user communities.

They are not prioritizing critical issues that have been requested by the community that are blocking users from producing production-grade products. And they are not prioritizing releasing a usable product with each iteration. They are prioritizing issues that address the fundamental flaws in the design of the system - which serve Chainlit's longer-term interests. In other words, the priority appears to be Chainlit the company, not the community.

"prioritizing issues that address the fundamental flaws in the design of the system"

This, rather than having a gazillion features, is in my eyes what is an absolute requirement of a production-grade system. Slashing away at complexity, exposing obvious and clear flaws -- which are now standing out and can be dealt with one-by-one.

Rome wasn't built in a day.

So, @dokterbob I'd appreciate an answer to my question, and I think the community deserves to know. Since Chainlit is a VC-funded startup who is hiring a team (https://literalai.notion.site/Literal-AI-Chainlit-Careers-cec94330409c405993407f92ca5e99da), I think the community deserves to know who is being compensated to build their product for them and who is not. And, you seem to be working pretty hard for Dan, Willy, and their investors, so if you're not getting compensated, maybe you should be.
I get paid to build on Chainlit 2 days a week. Willy retains overall control over the roadmap and strategy. Sometimes some of the Literal team make a collective effort to push things forward (like with the realtime audio), but they generally focus on the startup's core product (LiteralAI).

Long term, we aim to get Chainlit increasingly towards a community-driven effort. Short term, specifically, we are about to setup a community-maintained repo where contributors are free to implement whatever they want. My goal is to get Chainlit ready for this by ensuring there's clear API's, CI infra etc. to make this possible.

Due to our limited availability (I have 2 startups of my own), things are not moving as fast as they could. We are in fact looking out for active contributors who have the competence to join the core maintainers and help steer the project forward. This would be compensated for.

I have nothing against anyone, and starting a new company is hard so I cheer and wish the best to anyone who is trying to do it. I'm also not saying there's anything wrong with what the Chainlit guys are trying to do. But if these guys are pretending that this is an OSS project to get free coding from the community for a well-funded commercial product, people should know about it so they can make accurately informed choices about how to spend their time.

It's an OSS project that gives away a LOT of paid code work for free to the community. In return for some paying customers (for LiteralAI, many of whom are not even using Chainlit) and exposure for the core product. Willy has built this thing, gave it away and is even paying me to set a clear path towards a community-led or at least community-based FOSS project.

@stephenrs I am not sure how long you're in FOSS. Personally, I am doing Open Source for over 20 years and I think Chainlit/Literal's general approach is admirable, albeit that the needs of a 'young' project looking to gain traction are very different from a 'consolidating' project, aiming to retain professional users and contributors. I need the latter to happen, as much as other members of this community, as I'm eating dogfooding this thing.

[dokterbob]

@dokterbob For the architecture changes you mentioned, do you plan to describe them ? Does chainlit has a notion of improvement proposal and discussion around it ?

I just did. ;)

In addition, as I'm implementing specific parts, if and only if I have doubt, I will consult the community and at the least open up to feedback. With the limited time I've on my hands, I prefer to code (and/or review code) over discussing features.

[dokterbob]

+1 @stephenrs Nicely summarized several key issues. I am facing some of the very set of issues you outlined. I am using Chainlit in an environment where Auth has arleady been done (with our own JWT token etc) before user goes to chainlit app. So, while using header-auth-callback works, but chainlit goes on to create its own JWT Token (with no options to control its lifetime etc) and expects in HTTP and WS interactions - I have an API gateway that sits in the front and it gets confused with this JWT token that it doesn't understand. I tried to workaround (and monkeypatch) certain chainlit Auth methods (such as authenticate_user etc), but not great luck so far.

Then, there is is the issue of switching users on my non-chainlit outer app but chainlit frontend is unaware with its local-storage persisted tokens and continues to think the logged in user is someone else.

Data layer also has lot of assumptions - we donot consistently pass details of users and request context.

It is such a great project and probably nothing else comes close its approach. I am using chainlit library(with a custom frontend derived from chainlit's frontend) to build a universal chat UI for no-code or low-code agents. But been running into several issues. I understand multiple agents being served by a single chainlit service mayn't have been the original design goal, but it is so close to achieve that. I think, I got to like 80% of the way with some hacks, but now finding real challenges with auth and data layer.

@dokterbob we were discussing in another thread about enhancing chainlit to be more extensible by exposing request context in all its callbacks. Will be great to move forward in this direction - this should ease up some other enhancements in the future and extensibility.

Currently, I am trying to deal with the workarounds in a fork but I am happy to contribute in the discussion and implementation in whatever the way community decides

I see most of the problems you describe here and I agree with making things more consistent.

I appreciate the more concrete suggestions. If you can split them out into separate issues (or add to pre-existing issues), making concrete suggestions, that would be a huge help for us and the community at large.

There's already an issue to expose request context. If I remember well, I offered several options and a design decisions is needed. I'd love your opinion (pro's/con's) on the options. Once the decision is made, we can spec the feature and the actual PR should be simple enough (and O MY GOLLY, what a HUGE feature we'd have!).

Mind you, the remaining 20% is >80% of the work. So that's what were up against, that's why things are 'slow'.
When I first started I'd expected to be way further by now, but I keep running into things which I consider 'unacceptable', like having to switch off commit hooks time and again because I just can't wait 1m for every PR. Or allowing users to directly install from branches or forks, having unit tests on a project as active as this one etc.