owaislone

Answer to almost all of your questions is that it entirely depends on the service what kind of auth implementation they offer. I personally have completely adopted passkeys and use them with every service that allows it.

I use ProtonPass and have made it the default password store on every device and browser. This way all passkeys get stored in proton and I can login from any other personal device with proton setup.

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

Isn't this basically the same a Framework Desktop which has been out for quite a while? Does it improve on it in any way?

https://frame.work/desktop

I've been considering it as well. I'm using 1.5TB in google one storage. mostly from photos/videos from the last decade from 4 family members.

Have you thought about backups and redundancy? I was thinking of hosting it on my homelab with backups on some cheap cloud storage but almost any cloud storage ends up costing somewhat similar to Google One so I've been a bit reluctant.

A good backup story is probably the only thing keeping me from switching.

My cousin just dumped 50GB of photos from his weddings in a Google Drive folder and shared with his contacts. I wanted to extract photos of my immediate family members from it and just save those. I setup immich on my macbook to do this but sadly I found the face recognition is nowhere near as good as Google Photos. It missed a lot of photos with tricky angles. Other than that, everything else looked quite solid to me.

Choosing 1 is totally fine but that doesn't mean it should not be possible to choose 2, right? Just because I don't need a feature doesn't mean I loudly complain when others ask for it.

I want to host an instance for me and my family. Right now we have a Google One instance shared by 5 people. Having e2e means my family members can rest assured that I or whoever I share admin rights with cannot look at their private photos. It's an important enough feature even without thinking about 3rd party bad actors.

Interesting. For me if I want to keep my lab stable, I have to ensure I pin all images and components to a specific version. I rarely but deliberately upgrade them (2-3 months). I feel putting things on auto-update is bound to break stuff and force you to spend time on it at the worst possible times.

Depends. If you backend is just one service, it is not a big deal but then you don't JWT at all. You just need a regular cookie/token.

If your backend is a set of 12 services where each needs to verify the authenticity of the request then it might start adding up. In that case using JWT _after_ the initial API gateway makes a lot of sense. The gateway hits the DB, authenticates the request, mints a JWT and injects it into downstream requests. Then each service on the request path just verifies the JWT.

Overall I don't think hitting the DB for auth is a big deal and that is why we don't need all the bells and whistles JWT brings. Just use bearer auth.

This. Totally defeats the purpose of having JWTs if you have to hit the DB or some service to validate the token every time.

They aren't insecure really. They're pretty secure by design but people are using them for things they were never designed for like web/mobile client auth.

JWTs are awesome but they are are being overused by people. People use them in web, on mobile and everywhere in between. Places where cookie or bearer token auth has already solved the problems. JWTs strength is that it can be verified independently without real-time coordination between services. So a service can issue a JWT with auth scopes to a user. The user can take the JWT to any other service and if that service trusts the signer, it'll allow the user access and also get basic user info from the token itself. The service doesn't need to make an API call to the issuing service or even know if/where it exists. That is where JWT is really powerful.

For web/mobile auth where same server issues the JWT and same server verifies it, it makes no sense. JWTs cannot be invalidated. If a user loses some permission or account gets disabled, JWT will still be valid until its expiration time. Servers must either make DB calls to verify the user is still active or be fine with deactivated users having access for a while after account is disabled. This completely defeats the purpose and bearer tokens work perfectly for this use case.

JWTs should _almost_ never be used in client side auth. Client should send regular cookies and bearer tokens. The auth server can internally generate a short lived JWT and inject it into requests before they get routed to various services internally so those services don't need to query DB every time to verify the user.

Make it as perform as well or close to Apple Silicon and give me free access to Linux dev environment and I will give this a shot.

I really is impressive. I wish publishers like EA and anti-cheat developers weren't so reluctant to support it. I hope Steam devices and SteamOS gain enough traction to force their hands.

Oh man, Python 2 > 3 was such a massive shift. Took almost half a decade if not more and yet it mainly changing superficial syntax stuff. They should have allowed ABIs to break and get these internal things done. Probably came up with a new, tighter API for integrating with other lower level languages so going forward Python internals can be changed more freely without breaking everything.

I had a Nokia N9 or was it N7 that ran the predecessor OS to Sailfish. It was so good back then. The UX left android and iOS in dust. Both ended up adopting a lot of patterns from it later. Loved that phone.

or perhaps as simple as saving xAI for himself as he prepares to offload rest of Twitter?

You have a service that talks to postgres, probably other services that talk to that service, a client that talks to these services through some gateway. When a user clicks a button, distributed tracing allows you to see the whole request right from the button click to API gateway, to every service it goes through to the DB.. and all the way back. So you can see exactly the path it took, where it slowed down or failed. DBs are usually seen as black boxes in such systems. We just see the DB call took 500ms. We don't know what happened inside though. This allows such distributed traces to also get visibility to the internals of the DB so you can tell the exact joins, index scans etc that took place by looking at your distributed trace. I don't know what level of visibility they've built but that's the general idea.

I'm sure you are aware but sharing anyway. Django 6.0 shipped an API called Django Tasks for background jobs so all Django code can implement portable, backend agnostic background jobs and swap backends on the fly but there are zero actual backends out there right now one can use in production. If you could add inbuilt Django Tasks support to Chancy or create a `django-chancy` package that bridged it, I think you'd see a lot of early adoption by Django projects.

Thanks. My two cents would be to not lock technical features behind a paywall. Lock "enterprise" features like encryption, FIPS, compliance reports, etc which make sense for a big corp. This would be far more palatable for someone small like my one-two person teams to adopt it and pay if we ever become big enough to care about enterprisey features.

Thanks for sharing Chancy. Looks really interesting. Outside of the API breaking, would you say this is safe enough to for production today?

Django 6's tasks framework is nice but so far it is only an API. It does not include an actual worker implementaiton. There is a django-tasks package which does a basic implementation but it is not prod ready. I tried it and it is very unreliable. Hopefully the community will come out with backends for it to plug celery, oban, rq etc.

Thank you

Interesting. Any docs that explain what/how they do this?

I'm just coming back to web/API development Python after 7-8 years working on distributed systems in Go. I just built a Django+Celery MVP given what I knew from 2017 but I see a lot of "hate" towards Celery online these days. What issues have you run into with Celery? Has it gotten less reliable? harder to work with?

I don't know how I feel about free open source version and then a commercial version that locks features. Something inside me prevents me from even trying such software. Logically I'd say I support the model because open source needs to be sustainable and we need good quality developer tools and software but when it comes to adoption, I find myself reaching for purely open source projects. I think it has to do with features locked behind a paywall. I think I'd be far more open to trying out products where the commercial version offered some enterprise level features like compliance reports, FIPS support, professional support etc but didn't lock features.

I mostly agree with you but I AM super productive with AI. I'm working on a side-project and have built in 2-3 months what my quite productive team of 3-4 people would take 4-6 months to build in 2016. And I'm not talking to generative slop but real production grade code that I have reviewed+approved or manually refactored before merging. Like you I'm not impressed by these toy projects but the productivity gain is very real. At least has been for me.

Cool. I used to install it on all my family and friends computer when I was a teenager but as I grew older and had less and less time, being the constant tech support guy for everyone I introduced to Linux got very hard so I stopped recommended/installing it. Which distro did you choose for your parents?

What is the ideal or realistic setup for a home lab to power big enough models running locally and service ~2-3 users at a time?

Very interesting but why would a browser report different coordinates depending on the monitor? I'd assume browser would treat the webpage as if it was the entire screen irrespective of which display it was on. Is there a reason for web APIs to have this information at all? Seems like a potential security/information/tracking risk.